Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for May, 2007.

Archive for May, 2007

Seven Reasons for Code Bloat – My presentation for the WSG London Meetup

Wednesday, May 23rd, 2007

Here are the slides from my talk at the Webstandards Group meetup earlier. A massive Thanks to Stuart Colville for organizing the event, Steve Faulkner for his presentation on screen readers and accessibility and everyone who attended and bought me drinks afterwards. version:

How to make your web applications accessible – the human way

Sunday, May 20th, 2007

One of my biggest annoyances when talking about accessibility and web development is the argument of some developers that what they develop are web applications and not web sites which is why they don’t need to care about accessibility. The arrogance of that statement aside it also does not make any sense whatsoever. If anything, web applications should be even more accessible than web sites. A blind or a keyboard user not being able to learn about the new sports range of a certain brand is less problematic than the same user not being able to do a money transfer or apply for council benefits.

Web Applications are not better than web sites – they are different.

I have suffered for years trying to fill in overly complicated timesheet and room billing systems, and frankly I didn’t see anything to be proud of and consider yourself above the rules of normal web development. If anything, the logic that the system will be used in a closed environment with fixed parameters lead to many solutions that age terribly bad. Most of the time this happens because of time constraints or limitations of the systems used to create these applications. It is stunning how companies get stingy when it comes to spending another 2 weeks on development but don’t mind their employees wasting 30 minutes each time they enter their timesheets instead of 2. Maybe some accountant department should do an audit what makes more sense financially.

The voice of reason

The solution to accessible web applications came to me when I gave a talk at the Braillenet conference in Paris and someone in the audience was asking why Yahoo! doesn’t store the information that a user has a screen reader in his profile.

The main difference between a web application and a web site is that you need to sign up for it, and this is where we can get all the information we need to create an accessible web site – by asking the user if they use assistive technology.

Example of a simple signup form and an advanced one showing different accessibility options

Alastair Campbell proposes a full-fledged profile covering lots of disability options and settings which might be a bit too much to ask, but it is going in the right direction. Instead of trying to find out programatically (for example via Flashaid) if a user has assistive technology we just flat out ask them for it, store this information and change the interface accordingly.

If your framework or development tools does not plan for these situations then this is no excuse, but a chance to contact the developers of these and ask for these options. After all, professional web developers got rid of the idea of WYSIWYG long time ago as well and asked developers to turn the “paint your web site” tools into development IDEs.

A matter of discretion

One of the biggest issues with disability is that not everybody wants to be known to be disabled. therefore the information harvested this way should not be on the profile but only used behind the scenes in your application.

Web Developer and Professional (Part 2 of 2)

Saturday, May 19th, 2007

In the first part of this I wrote about three aspects of a professional web developer: not to overrate your knowledge, for it is fixed in time, making sure you share what you know and never ever consider yourself indispensable.

It is not only what but also how you deliver

In terms of delivery of work you can show your professionalism first and foremost by delivering on time and budget (which happens not very often, but it keeps the people happy who spend money on us). This can mean that you cannot deliver the all-singing all-dancing solution you have in your head or spend 2 hours pondering what the best semantic markup for a certain bit of content is. However, it is no excuse for delivering bad quality. Bad quality means shortcuts or stopgap solutions that don’t make sense (as they will never be replaced with the real thing) or simply code that only you understand. The main quality criteria of code in a development team is that it does the job, that it does it in a clean manner and that anyone in the team can maintain it. Best practices are what it says on the tin: best practices. You can only make them a standard by sharing the idea with other developers, verify it as a good one and implement it in bulk. We all have different ideas what is best, and if we all implement it on the sly we don’t end up with a standard, but with lots of good ideas that all together don’t paint a consistent image.

Web developers are middlemen – be one

As a web developer we have to communicate in all directions – much like project managers do.

  • We need to talk to engineering to connect our templates with the right backend logic.
  • We need to talk to the deployment and configuration departments to get access to servers, systems and software installed.
  • We need to talk to project management to exchange time estimates and get allocations and
  • we need to talk to the design team to make sure that what needs to be delivered is technically feasible.

That’s a lot of points of contact, which is why larger companies have lead web developers who take on the bulk of this so that other developers have time to deliver the work that has to done.
What it also means is that you should be aware that all of these people around you know and like their job – the oft mentioned incompetent idiot is not as common as you think. The same way we expect people to trust our judgment when it comes to what makes sense on the web we should show respect and trust PMs to know about delivery schedules and material gathering and designers to know what works for end users and is engaging. The smoother your interplay with all the other people involved in a project is the less stressful your job will be.

Let’s enjoy our freedoms – not take them for granted

It is amazing how quickly people forget the perks we have as web developers.

Free personal Internet use

The amount of time we spent uploading photos to flickr, commenting on blogs, twittering, sending personal email or reading our RSS subscriptions is not as easy to get out of other jobs. Don’t get me wrong, I’d personally never work for an employer that does not grant me internet access, but technically they don’t need to – you could work on internal projects and servers.

Use of company assets

From a legal point of view, everything personal we write or create using software or hardware belonging to our employers also belongs to that company as we used company assets to create it (can someone back that up with a legal example in the comments?). And now be honest: how often have you fixed something on a personal web site or blog in the office as the connection is faster than the one at home?

Casual Clothes

All the companies I worked in so far as a web developer had no smart dress code (to me, wearing a tie sitting in front of a heat-emitting box is everything but smart anyways) which also means we don’t have to buy clothes for work but can wear whatever we do in our free time instead. This is a lot of money saved when you also consider dry-cleaning, pressing of shirts and other stuff we wouldn’t be able to do ourselves as we are too busy on top of the initial buying of suits, ties and uncomfortable shoes.

Licensed Software

If your employer is a good one you’d also not have to worry about software you need to use. As a freelancer, you’d need to buy your applications (CS3 anyone) and upgrade whenever a client cannot deliver raw material in a format you can use. Sure, you could use pirated copies, but don’t forget that a lot of software does keep your name and computer identity hidden in the binary files it creates. Furthermore, using non-licensed software makes you a hypocrite – after all you don’t want people to re-sell what you have done as theirs and for their own profit either.

All of these are something to consider when you compare what we earn to stock brokers, investment bankers or other, higher-paid jobs.

Have I got tabs for you!

Thursday, May 17th, 2007

One of the guys I keep dragging into the limelight of the web (the last time with an A List Apart article on font resize monitoring) is my colleague Lawrence Carvalho. This time he has an amazingly versatile tab interface based on the YUI on offer.

a draggable and closeable tab in action

There are many tabs solutions out there, including my DOMtab but Lawrence’s beat mine hands-down:

  • Based on design patterns described in the YUI Design Pattern library (Drop invitation, Spotlight, Fadeout)
  • URL Fragment aware (ah I have that, too) – highlights targeted patterns in the URL
  • Uses Event Delegation
  • Allows for deletion of tabs and re-ordering of tabs – including dragging a tab from one tab group to another!

Check out the example page to see the different implemenations.

Working in the valley for the next 2-3 weeks

Wednesday, May 16th, 2007

I will fly to San Francisco on Monday to work in Santa Clara and stay in Sunnyvale for the next 2-3 weeks. So far my stops beside working are:

  • Go to Stanford and give a talk on web development (invitation by John Foliot)
  • Visit the Flock offices to talk shop and pick up schwag.

Anything else I should be doing while I am there? I got a rental car and a cheap hotel room :)