Find The Right JavaScript Solution With A 7-Step Test

Advertisement

As Web developers and designers, we are spoilt for choice right now. To build a complex Web application or even just spice up a website with some highly interactive interface element, we have hundreds of pre-built solutions to choose from. Every library comes with widgets and solutions, and every developer tries to make a name for him or herself by releasing a funky JavaScript solution to a certain interface problem. We can pick from dozens of menus, image carousels, tabs, form validators and “lightboxes.”

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?
    Do you need to be a JavaScript expert to modify the widget?
  • 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

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.

Introducing The 7-Step Test For JavaScript Widgets

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.

Okay, here goes: seven things to test when deciding on a JavaScript solution.

1. What Happens If JavaScript Is Turned Off?

The first test I do with any widget is turn off JavaScript… not after the document has loaded but before. Turning off JavaScript with the Web developer toolbar is very easy. Simply select “Disable All JavaScript” from the “Disable” menu and reload the page:
Disable JavaScript with the web developer toolbar

The rationale is that there are a lot of reasons why JavaScript may not be used: company proxies or personal firewalls could filter it out, other scripts could create errors and mess with yours, or the system in use could simply not have JavaScript enabled. Think of mobile environments, for example.

You don’t need full functionality when JavaScript is not available, just a working interface that doesn’t overload users and interactive elements that work. If a button does nothing when users activate it, those users will stop trusting you; after all, you haven’t kept your promises.

Overloading is another issue. A lot of widgets use CSS and JavaScript to squeeze a lot of content into a very small space: think tabbed content elements and image carousels. What should be their fallback? If you turn off JavaScript and have 50 pictures where you planned for 2, then that would be a good user experience. A better fallback would be a server-side solution for the same functionality or to show the first 2 and then offer a link to a gallery page with the remaining pictures.

Sometimes the JavaScript for a particular widget is actually very good but the demo websites have been done badly. Hiding elements with CSS and then revealing them with JavaScript, for example, is very common. But if JavaScript is turned off, the solution will break. Good demos and solutions use JavaScript to add a class to the body of the document and make all of the CSS dependent on that class.

The trick that any good JavaScript widget should do is to make any functionality depend on JavaScript by using JavaScript; that way, you never have any functionality that won’t work. This technique is called “unobtrusive JavaScript,” and I have written a course on it2 and set a few rules for it3 a while back.

2. How To Change The Look, Feel And Content?

A widget whose look and feel are hard-coded is a pain to maintain. You cannot expect future designers to know how to change a certain color by hunting through your JavaScript files. This is how we end up with bloated CSS files, because people add random IDs and classes to enhance the specificity of their CSS selectors.

Good widgets have their look and feel contained in a CSS file and give you handles (i.e. dynamically applied classes) to apply your own styling. If you find yourself having to change JavaScript to change the look and feel, alarm bells should go off in your head.

This gets worse if you have content such as text labels in the JavaScript or if only a fixed number of elements can be displayed (as in the case of navigation menus). Labels and number of elements are what change the most in any Web product. For starters, you will probably roll out your product across different markets and will have to translate the buttons and menus.

Good gadgets have configuration objects4 that allow you to change the number of elements and define the text labels without having to change the main JavaScript. The reason for this is that the functional part of the widget should be separated from the maintainer. If the widget has a security or performance problem, you should be able to replace it without losing your configuration and localization work. Otherwise people would be very likely to keep insecure code on the Web, which is one of the reasons why our inboxes are full of spam.

3. How Usable And Semantic Is The Final Product?

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>

The second example works without JavaScript and uses much less HTML. It also requires much less CSS for styling because you would simply take advantage of the cascade.

Furthermore, the HTML on which the widget is based is only half the story. What the JavaScript generates also needs to be valid, usable and accessible, and you can check this when you check the generated source in the Web developer toolbar.

To do this, right-click anywhere in the document and select Web Developer → View Source → View Generated Source:
View Generated Source in Web Developer Toolbar

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 websites5 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 usability6 (also as a video7 and using YUI38 and focusing on WAI-ARIA9). Patrick Lauke of Opera also wrote a great article on the subject10 and gave a presentation11 at last year’s Future of Web Design. If you are a Mac user, make sure to turn on keyboard access12 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?

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.

Remember, if the doo-dad stops working, you will be asked to fix it or explain what went wrong. Therefore, it is important to at least know the basics of what JavaScript spell was cast to transform a list of images into an all-singing, all-dancing carousel.

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?

The biggest problem with any JavaScript on the Web right now is that its security model gives every script on the page the same rights. This means that one bad script can mess up the user’s whole experience because it may override parts of another script.

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.

The good news is that for widgets that are based on libraries, this “event clash” is very unlikely because libraries work around that out of the box. You can test for the problem of function and variable names that can be overwritten by other scripts. JSLint13 is a tool and website where you can check JavaScript for syntactical problems such as unprotected variables. It is a very strict tool, though, and not all of its warnings are actually deal-breakers. But testing with JSLint is the hallmark of a professional Web developer. You do want your code to play well with others.

6. How Dedicated Is The Maintainer?

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?

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.

Widgets built with the Yahoo User Interface library, for example, come with a lot of custom events14:

List of events fired by a widget
This allows you to monitor what is going on (like for debugging purposes) and extend functionality. The demo page for the AutoComplete control15, for example, displays in a logging console on the right what happens “under the hood” when you use the auto-complete field.

Debugging tool showing custom events being fired
By subscribing to these events in JavaScript, overriding the original functionality for something new is pretty easy; in this case, we have an auto-complete that returns photos and allows you to collect them16.

Overriding events allows you to extend functionality
Custom events are a great way to extend a widget while keeping the core code easy to upgrade.

One Final Word On Size

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.

Advertising-speak like “A drop-down menu in 20 lines of JavaScript” or “A full featured lightbox in under 2 KB” is fun and good for the developer’s ego, but in reality it is no measure of the quality of the solution. While you should avoid JavaScript solutions that are massive (let’s say 100 KB), code that has been written to be very generic and easy to extend will always be bigger than code that has been written to serve a single purpose. Any widget whose size is proudly trumpeted and is meant to be used by people who are not as good at developing as the initial owner will get bigger over time anyway. Developers like to play the numbers game, but maintainable code is different than extreme number-crunching.

And if you get your kicks from this sort of thing, try the demo scene in which Farbrausch proved with The Product17 in 2000 that you can fit a seven-minute animation with music and synthesized voices into 64 KB.

(al)

Footnotes

  1. 1 https://addons.mozilla.org/en-US/firefox/addon/60
  2. 2 http://onlinetools.org/articles/unobtrusivejavascript/
  3. 3 http://icant.co.uk/articles/seven-rules-of-unobtrusive-javascript/
  4. 4 http://dev.opera.com/articles/view/json-configuration-for-javascript/
  5. 5 http://www.w3.org/TR/wai-aria-practices/#kbd_generalnav
  6. 6 http://www.yuiblog.com/blog/2009/02/23/managing-focus/
  7. 7 http://developer.yahoo.com/yui/theater/video.php?v=kloots-a11y
  8. 8 http://developer.yahoo.com/yui/theater/video.php?v=kloots-yuiconf2009-a11y
  9. 9 http://ericmiraglia.com/blog/?p=132
  10. 10 http://24ways.org/2009/dont-lose-your-focus
  11. 11 http://www.splintered.co.uk/news/112/
  12. 12 http://www.456bereastreet.com/archive/200906/enabling_keyboard_navigation_in_mac_os_x_web_browsers/
  13. 13 http://www.jslint.com/
  14. 14 http://developer.yahoo.com/yui/docs/YAHOO.widget.AutoComplete.html#events
  15. 15 http://developer.yahoo.com/yui/examples/autocomplete/ac_basic_xhr_log.html
  16. 16 http://developer.yahoo.com/yui/examples/autocomplete/ac_flickr_xml.html
  17. 17 http://www.pouet.net/prod.php?which=1221

↑ Back to topShare on Twitter

An international Developer Evangelist working for Mozilla in the lovely town of London, England.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Interesting little article to bookmark for future use!

  2. 2

    Thanks for the tips. There are excellent tips to choose your plugins by. Thanks for the tip on size to. I’m probably putting to much emphasis on that right now.

  3. 3

    So jQuery it is then?! ;-D

    Great post as always.

  4. 4

    Very interesting article Christian and thx for theJSLinkt-Link! By the way, my prefered JavaScript-Framework is jQuery, because it is the dominating JavaScript-Framework for me an other user too.

  5. 5

    Definitely looks like some useful info.. the only thing I’m worried about is finding out whether those standards hold true in any given solution. It can be pretty difficult to tell, especially as a javascript newbie

  6. 6

    I’ve saved & retweeted. Useful article

  7. 7

    Something happend with your style sheet though I’m gonna check my firewall to make sure it’s not me. nice article though.

  8. 8

    Granted, it’s usually becuase the partner/parent company/org is totally ignorant of how software on the web is done these days, but

  9. 9

    I’d like to add one more item to the list: Does it have an Open Source license that is compatible with my (or my client’s) company or organization’s legal guidelines? Do they require a commercial license for all their public-facing products?

    Or a different scenario… Your client company is OK with the licensing, but their business partner(s) or their future parent company IS NOT. It’s important to find out since you wouldn’t want to have to rip/excise out an entire framework that is interwoven into your web site or web application because you didn’t do your homework. Granted, it’s usually becuase the partner/parent organization is totally ignorant of how software on the web is done these days, but it’s still no laughing matter. I’ve been involved in or close to a few projects that met this very demise, and most of us don’t have deep enough pockets to go head-to-head against corporate lawyers.

    So remember to read the fine print (or rather, THE ALL CAPS PRINT).

    HTH.

  10. 10

    Not a particularly relevant or realistic article.

    Over the years I’ve found several things to be true that, fortunately or unfortunately, extend beyond the theory that this author proposes.

    First, you ARE designing for yourself, the client, AND the audience. I take great pride in my work and would never do something I wasn’t completely engaged and happy with. A smart designer and developer is only going to take jobs that compliment his skills, talent, and desires and, therefore, is going to be designing for himself. The client is paying for the job and already knows his business needs better than you. His wishes are NEVER to be ignored. Finally, the audience is part of the equation – an important part – but, only a part. They’re needs should be considered in parallel with everything else. This is what separates the “good” designers from the “great” ones – being able to merge everyone’s needs into a final, beautiful product.

    I’m certain I could point out other glaring examples of faulty thinking in this article (what average user on an average browser actually turns JS off? Are average designers that inept that they Google a coding solution without help? Don’t developers comment their code specifically to help others understand and expecting them to modify it?)

    I particularly find this comment rather hypocritical:
    “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. ”

    I suppose blogging for free while trying to sell an opinion (and preemptively defending it) isn’t the same thing.

    David Kaplan

  11. 11

    I’d be suspicious about the results of a research like that. Twitter polls are very easy to be tainted as you already talk to people you know and use the things you do. A good bot scraping the web and analysing the nature of the sites using library x would be a better data set.

  12. 12

    I’ve always wondered that – why are terms and conditions always in ALL CAPS?

  13. 13

    The term you are looking for is YMMV. Glaringly, at that.

  14. 14

    jQuery is nice, but I’ve been developing a lot with Ext JS lately. It’s got a lot of standard features out of the box at a pretty lightweight footprint.

    I got a little too tired of searching and sifting through widgets for some of the other JS libraries. It seemed like they were just reinventing the wheel with standard functionality like carousels or form field validations.

    Much better in my opinion to standardize on a single platform with a lot of room for customization.

  15. 15

    Owen Curtis-Quick

    January 21, 2010 4:20 pm

    Christian you old sea dog! I could not agree with you more. I’ve recently finished making a website and hit the same issues whilst choosing a Lightbox to display images. I tried out all the popular ones and choose one based on how well the code was organised. But then I went down the route of wanting to change bits of the behaviour and skin it differently. At first it was happy times, but the more I changed things the more it turned into a nightmare.

    The mark up it spat out was unnecessarily verbose and not semantic, divs for buttons etc. Interaction wise, it wouldn’t cycle back to the beginning after the last image, this is rubbish bad because in my case the user doesn’t have to start viewing the first image. This is all fairly straight forward to fix. So what you ask got my goat? Well it was the css, so much of the styling was being set in the code, instead of being inherited from the css, it made moving the title bar from the bottom to the top ridiculously painful.

    Eventually I cut my loses and made my own. I can now make behavioural changes very quickly and skinning is now a joy. It uses css3 for shadows instead of the the crazy method of using a grid of pngs.

    So in light of this, at the end of your list titled “The things you should really look for are different, though:” I would add “Would it be easier just to make my own? – If you want to make a lot of changes then it will probably save you time and your soul”.

  16. 16

    That’s a great article!

  17. 17

    There is no right JavaScript solution… :) Good article.!

  18. 18

    Katerina Skotalova

    January 22, 2010 4:02 am

    You just convinced me that I should still care about users without javascript! Actually… thanks! Great article.

  19. 19

    I disable javascript by default for every new site I visit — with NoScript plug-in — and don’t like, when press on UI element, which I excpect to work without js, but it don’t, because designer decided to add fancy jquery effect, not caring of fallback version (even thought it’s not hard).

    At least, there should be warning, that «this» function will not work without javascript, or it should be hidden.

  20. 20

    Great post!

    Thanks

  21. 21

    Solid article, especially regarding customisation. There are indeed a large number of libraries and widgets out there, but very few allow total customisation of its look.

  22. 22

    thx for this kind of helpful posts …

  23. 23

    as usual always helpful in providing an article
    thanks :)

  24. 24

    I’m certain I could point out other glaring examples of faulty thinking in this article

    Really? I’m not so sure as you didn’t manage to make a single compelling argument to back up your opening statement in all that ramble.

↑ Back to top