It is scary how some obviously bad practices refuse to go away and developers jump through hoops to defend them and make them work rather than using simpler alternatives.
My pet peeve is the “chess rules” select box (you touched it, it needs to move):
This is the most evil permutation of this interface idea. A lesser evil version is part of a large form that will change the rest of the form or – if we venture back into more evil lairs – submits it to reflect these changes.
The arguments for this interface are not many:
It saves the user one step of pressing a submit button
The action is immediate
(Ok, these are actually the same argument, comment if you know some.)
The drawbacks of the solution are immense:
People that use a keyboard will submit the form or leave the page without having selected the right option.
People that are dependent on using a keyboard for web access will possibly know that you can press the Alt+Arrow Down keys simultaneously to expand the whole dropdown before selecting with arrow up and down and enter.
Most people won’t know this though and a lot of people use keyboards and tabbing from field to field to fill out forms.
Forms are a terrible annoyance of our times – nobody likes filling them in. Most of the time we won’t keep our eyes on the screen but actually look up information on papers, our credit card or read up the fine print that – of course – is not on the screen but only in the letter we got sent.
I have no clue how something like that works with switch access or voice recognition – probably not
It is scripting dependent – no JavaScript, no service
The latter is actually a reason for some companies for using this from time to time. Too many links on the same page are bad for SEO - Google considers your page not content but a sitemap and ranks it lower. That’s why some companies start offering the first two levels of navigation as links and the rest as a dropdown in this manner.
However, that still doesn’t make them a good solution, it just means that you offer far too many options to your users to begin with.
Here’s what people do to make this work: Aaron Cannon on the WebAim mailing list
A coworker and I recently devised a way to make a slightly more accessible version of the onchange dropdown navigation box. Basically, using javascript, we determine whether they are using their mouse or the keyboard to select each item in the list. If they used the mouse, it works as usual, immediately taking them to the selected page. If however the selection was made by the keyboard, we display a spinner and delay x number of seconds. If the user doesn’t make another selection within that time, they are taken to the page they selected. If they do, the clock is restarted.
I am not attacking Aaron here, he probably was asked to find a solution no matter what and did his best to find a technical way. The big scare in this for me is “determine whether they are using a mouse or keyboard”. My guess is they check for the event type, but assistive technology like voice recognition must simulate clicks without being a mouse. The other danger signal is the timer and the spinner – this complicates the interface even further (“Is this loading?”).
I simply don’t understand why we constantly try to make things work because this is what the design spec says or this is what we saw somewhere else. How about really testing it with users and see what happens then?
The last few months Chris Mills from Opera was busy gathering a lot of great web development experts around him (with a lot of pimping by yours truly) to assemble probably the most thorough and up-to-date web standards curriculum on the web: The Opera Web Standard Curriculum
Several dozen articles, all licensed with Creative Commons will be available to cover the tasks of web development: from understanding the principles of the web up to Ajax interaction. During the whole course the main focus is on usability, accessibility and writing maintainable code. We deliberately left out browser hacks and backward facing solutions and build on the ideas of progressive enhancement and unobtrusive JavaScript.
I wished this would’ve been out when I started, it’d have saved me a lot of time learning bad practices and un-learning them (which is always a painful process).
Two weeks ago I went to East London to give a “brown bag” presentation at the office of the Guardian. In a very crowded room around 30 developers sat and listened to me raving about best practices in web development and what the YUI already solved for you.
It is very cool to see your name on an old-school media site and the way they wrote up what the talk is about makes me realize that journalism will never be replaced by blogging and twitter.
Ben Collins-Sussman, Subversion godfather and one of the men behind Google Code wrote an interesting article about Programmer insecurity in which he realizes that the whole concept about “Release early, release often” is not as common as we think it is.
And yet over and over, I’m gathering stories that point to the fact that programmers do not want to write code out in the open. Programmers don’t want their peers to see mistakes or failures. They want to work privately, in a cave, then spring “perfect” code on their community, as if no mistakes had ever been made. I don’t think it’s hubris so much as fear of embarrassment. Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.
Yes it is, and overcoming the barrier to allow people to point out your mistakes to you for fixing is quite a hard step for a lot of people.
One main reason is that the job market doesn’t necessarily help us in getting there: bad managers still promote developers in terms of what they can produce in a certain amount of time or how much they know themselves. Clever managers encourage knowledge sharing and make sustainability of your code a necessity for promotion. If you can deliver good code and you can make yourself replaceable by people reporting to you, that is good for the company and the product. It also means that you can have a holiday once in a while. However, far too often this way of progressing is seen as weakness or “losing touch” or “becoming a manager and not a coder” by your programming peers. Coalfaces we ain’t, so let’s stop with this.
Back to opening up your code early and often and invite feedback all the time. I do appreciate that some people don’t want to do that. It is not about releasing “perfect code” but it actually is about protecting your idea or principles.
Say you wanted to create a JavaScript library that only does one thing right: patching browser bugs in DOM and CSS support and allowing developers to really use the W3C recommended methods instead of branching for browsers. Releasing this library would more than likely result in a flood of requests to “add animation – everybody needs that!”, “make it like jQuery – just smaller” and similar requests. Developers are amazingly gifted in listening to the “feature creature” (think of Jabba’s little evil cackling mate in Star Wars) on their shoulder instead of keeping what they deliver down to the bare necessities. Feedback like that early in the process is very distracting and also disheartening. It is not about how much you pack in – it is about fulfilling the task you set out to fulfil.