Having this much choice makes it easy for us to pick and choose, which is where things go wrong. In most cases, we measure the quality of a solution by its convenience to us. Our main reasons for picking one solution over another are:
- Does it do what I need it to do?
- Does it look cool?
- Does it sound easy to use?
- Would I want to use it?
- Does it use the framework I’m committed to?
The things you should really look for are different, though:
- How stable is the solution?
Is a good alternative available if this one doesn’t work?
- How easy is it to customize?
- How usable and accessible is it?
Are users who don’t have a mouse or are on a mobile browser blocked?
- Do you understand what’s going on?
Would you be able to fix a problem and explain it to others?
- Is it a contained solution?
Will other scripts be able to interfere with it, or would it contaminate the document?
- How dedicated is the developer?
Will the solution be maintained in the future?
- What is supported, and how can you extend functionality?
A new browser and client request is always around the corner?
In this article, we’ll show some ways to find out more about these issues. First of all, though, understanding what it means to develop for the Web is important.
It’s Not About You Link
Most of the reasons why we choose a particular solution right away are very much about us, and this is where we tread on thin ice. We don’t consume what we put on the Web; rather, people we don’t know do, and we can’t make assumptions about their ability, set-up, technical understanding or taste. We won’t make our product a success; we only build it, and thus we are the worst testers of it possible.
I’ve been developing for the Web professionally for over 10 years now, working on everything from personal blogs to multi-language enterprise CMS solutions to complex Web applications, and I’ve learnt one thing on the journey: never build for yourself or the client. Instead, build for the people who will use the product and the poor person who has to take over the project when you leave.
Much as we have to act now to minimize our massive carbon footprint, we need to leave a cleaner Web behind. To keep the Web a thriving market and sustainable work environment, we have to change the way we work in it and leave behind unmaintainable, bloated and semi-workable, albeit pretty, solutions. We have to make it easier for people to use Web applications and save other developers from wasting hours trying to understand what we did when they are asked to change or extend it at a later stage.
To this end, I’ve put together a seven-step test to apply to any out-of-the-box widget you find. All of the recommendations have a rationale, so please ponder it before dismissing the arguments as “elitist” or “not really suitable to our environment.”
Let’s not forget that even when something is free, its developer will try to sell it to you for the fame, and many a solution is defended tooth and nail on mailing lists instead of being changed or updated. The reason is that, as developers we are always on the move. Maintaining and extending an old solution is not as sexy as creating a cool new one. This leads to ruins that once enjoyed love when they were state of the art but now rust away on the Internet.
To kick the tires of any out-of-the box solution, I mostly use one tool: the Firefox Web developer toolbar. It is available on the Firefox Add-On website1 and gives you an easy way to test what’s happening in your widget of choice.
2. How To Change The Look, Feel And Content? Link
3. How Usable And Semantic Is The Final Product? Link
A lot of widget creators are very happy to announce that their products are “Web-standards compliant” and accessible because of it. While Web-standards compliance is important, it does not indicate the quality or usefulness of the product. One cannot really validate semantics with an automated tool. For example, the following examples are both valid HTML:
<div class="menu"> <div class="section"> <span class="label">Animals</span> <div class="subsection"> <div class="item">Giraffe</div> <div class="item">Donkey</div> <div class="item">Cheetah</div> <div class="item">Hippo</div> </div> </div> <div class="section"> <span class="label">Stones</span> <div class="subsection"> <div class="item">Diamond</div> <div class="item">Ruby</div> <div class="item">Onyx</div> </div> </div> </div>
<ul class="menu"> <li><button>Animals</button> <ul> <li><a href="giraffe.html">Giraffe</a></li> <li><a href="donkey.html">Donkey</a></li> <li><a href="cheetah.html">Cheetah</a></li> <li><a href="hippo.html">Hippo</a></li> </ul> </li> <li><button>Stones</button> <ul> <li><a href="diamond.html">Diamond</a></li> <li><a href="ruby.html">Ruby</a></li> <li><a href="onyx.html">Onyx</a></li> </ul> </li> </ul>
To do this, right-click anywhere in the document and select Web Developer → View Source → View Generated Source:
Usability and accessibility (accessibility being, in essence, merely a more comprehensive understanding of usability) are harder to test. But one very good test is to check how keyboard-accessible a widget it. Keyboard-only users are on the rise, and widgets that work only with mouse-over events would not usable on a touchscreen mobile, for instance. Many widgets provide basic keyboard access (e.g. using the Tab key to jump from one link to another, and the Enter key to activate each), but this is not proper accessibility.
A menu, for example, should not be navigated by tabbing through each of the items because this would require far too many keystrokes. Instead, the user should be able to tab to the main menu bar and from there use the cursor keys to navigate.
A modal pop-up (commonly called a lightbox) should be able to be closed with a keyboard by hitting the Escape key or by tabbing to the “Close” button. If it is a multi-item lightbox, you should also be able to navigate the items with the cursor keys.
The W3C’s WAI websites4 have some great examples of how widgets should react to keyboard use, and Todd Kloots of Yahoo does a great job of explaining the techniques behind good keyboard usability5 (also as a video and using YUI3 and focusing on WAI-ARIA). Patrick Lauke of Opera also wrote a great article on the subject6 and gave a presentation7 at last year’s Future of Web Design. If you are a Mac user, make sure to turn on keyboard access8 before declaring a widget faulty.
People also need to be able to resize the text in their browser. So test the widgets at several text sizes. Using Internet Explorer 6 for this is important because it is the main culprit in font-resizing issues. Newer browsers do a much better job of zooming the entire interface, but you cannot expect end users to know how to use them.
4. Do You Understand What’s Going On? Link
If you’ve read the Harry Potter books (or even seen the movies), you know that you shouldn’t trust magic without knowing what is going on. A book that responds to your writing is as suspicious as a widget that does something so amazing that you have no clue how it happened.
Good widgets have technical documentation for that kind of thing, and some even fire off custom events that tell you when something is happening. That way, you can debug the tool by waiting for these events and analyzing the current state of play. It also allows you to extend functionality, which we’ll come back to in step #7.
5. Does It Play Well With Others? Link
The places where scripts can clash are in variable and function names and events. If your widget does not protect its variables and function names or if it applies event functionality to elements without checking that other scripts are doing the same, you’ll have a problem.
Say you have an element with the ID
menu, and you have one script that turns its HTML content into a drop-down menu and another that enhances the different links by showing a beautiful roll-over message. If neither of these scripts append to the existing functionality and just apply it, you’ll have either a beautiful roll-over or a menu, depending on which script is applied last.
6. How Dedicated Is The Maintainer? Link
When choosing a widget, you want to be very sure that the maintainer is dedicated to keeping it up to date and to fixing the script for future browsers and environments. This is rarely the case, and a lot of software is released with an “as is” statement, absolving the creator of any liability for problems it may cause now or in the future.
Software, especially the kind that is executed in the browser and for Web consumption, has to constantly evolve. Things that were once state of the art might be clumsy now. Some software turned out to perform poorly or be outright security holes.
Whenever people claim that we have a great baseline environment on the Web for screen space and processing power, something comes along that debunks it. Right now, testing on dual or quad-core processors with resolutions starting at 1280 might be normal for us designers, but given the sales figures of smartphones and netbooks, planning for audiences other than these high-end ones might be a good idea.
For developers, maintenance is the most boring task. When we release awesome widgets to the world, we don’t want to think about that phase of software delivery. Granted, most widgets are released as open source, but sadly, not many developers fix or improve on other people’s work; building and releasing something almost identical but slightly modified is much more fun.
As the user of someone else’s widget, you don’t want this to fly back in your face, so you need to see just how dedicated the developer is. A few questions to ask are:
- Is there a simple way to report bugs?
- Is there trail of improvements and bug fixes?
- Is there a history of comments and changes to the widget based on that feedback?
- Has the widget been used in real scenarios, large projects or implementations similar to yours? What were the experiences of those who used it?
- Does the solution have a community (i.e. are there a few people on mailing lists or in forums helping each other out, rather than overloading the original developer)?
If the developer has no big personal stake in the widget or there is no group of developers or commercial users, then there is a high chance that you will see few or no fixes or improvements in future, and you will be responsible for supporting the next browser version that behaves badly.
7. Is There A Testing Plan, And Is Upgrading And Extending Easy? Link
One last thing to consider is what will happen in future. Claims that the widget will “work in every environment” are bogus because that cannot be done. The great power of the Web is that software solutions can adapt to the environment they are being used in. If you use Netscape 4, you should see a few images; if you use the newest Webkit browser, you should see a fancy image carousel with animation and fading; that sort of thing.
A good widget will have a proven test report covering which browsers and environments it has been tested in and what the known issues are. There will always be issues, and claiming otherwise is arrogant or ignorant.
Upgrading your widget should be easy and painless, and there should be some versioning in place, with new versions being backwards-compatible.
Extending the widget should be easy. We spoke earlier about not being limited to a particular number of items or a certain look and feel. But if you really use a widget, you will find you have to override certain functionality and react to various changes. Good widgets either have an API (a programming interface to extend it) or fire custom events for you to listen to. Custom events are “interesting moments” in a user’s interaction with the widget. For example, a button will tell the script when you have activated it, and if you write the widget a certain way, you can tell the world (or in this case, other scripts) when something happens to it. You can notify that a container has been opened, that data has returned from the Web or that a menu was too large to be displayed to the right and had to be moved to the left.
This allows you to monitor what is going on (like for debugging purposes) and extend functionality. The demo page for the AutoComplete control11, for example, displays in a logging console on the right what happens “under the hood” when you use the auto-complete field.
Custom events are a great way to extend a widget while keeping the core code easy to upgrade.
One Final Word On Size Link
One last thing to mention: some widget developers use a certain argument to advocate for their solution but which is totally irrelevant to your decision, and that is size.
And if you get your kicks from this sort of thing, try the demo scene in which Farbrausch proved with The Product13 in 2000 that you can fit a seven-minute animation with music and synthesized voices into 64 KB.
- 1 https://addons.mozilla.org/en-US/firefox/addon/60
- 4 http://www.w3.org/TR/wai-aria-practices/#kbd_generalnav
- 5 http://www.yuiblog.com/blog/2009/02/23/managing-focus/
- 6 http://24ways.org/2009/dont-lose-your-focus
- 7 http://www.splintered.co.uk/news/112/
- 8 http://www.456bereastreet.com/archive/200906/enabling_keyboard_navigation_in_mac_os_x_web_browsers/
- 9 http://www.jslint.com/
- 10 http://developer.yahoo.com/yui/docs/YAHOO.widget.AutoComplete.html#events
- 11 http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_xhr_log.html
- 12 http://developer.yahoo.com/yui/examples/autocomplete/ac_flickr_xml.html
- 13 http://www.pouet.net/prod.php?which=1221
Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf New York, on June 14–15, with smart design patterns and front-end techniques.