Design patterns and javascript libraries
Written at 00:05, on Wednesday 9 May 2007. Tags: c-md javascript webdesign .
A large part of the discourse on web development today is focused on design patterns and interface components. But what are they exactly, how are they useful and how can they change the way we work? More importantly, what are their limitations, the scope of their application?
Design patterns are sort of an evolution of the style guide, which we are familiar with from graphic design. But while the style guide documents and prescribes the use of graphic design for communicating a certain brand, design patterns abract common problems in interaction design. A common examply is undo functionality.
There are lots of design patterns available today. The Yahoo! Design Pattern Library focuses on creating small components which can be used as building blocks for creating your own web application. A similar library for interaction design is provided by Jenifer Tidwells’ Designing Interfaces. Martijn Welie’s design patterns is broader in scope and describes also complete web site patterns. A nice collection of good pattern examples can be found in this screenshot collection
Design patterns are only one part of the story though. In order to efficiently and quickly use them, a lot of Javascript libraries have been developed that provide customizable pattern-based components. The Yahoo! User Interface Library provides lots of components that are made according to the results of their extensive pattern research. Other Javascript libraries, such as Prototype and Scriptaculous, jQuery and Mootools often provide similar functionality but they’re often based on developer needs, and mostly focus on easily adding Ajax support and animation effects. Despite this, they are excellent starting points for design pattern components since they are easier to use and offer a stable base which takes care of browser bugs. Most libraries can be extended with plugins, thus allowing you to fully leverage their advantages.
Together, design patterns and Javascript libraries are becoming the new building blocks for creating rich internet applications (RIA’s). And unlike Flash, it’s possible to make them completely accessible, which means that they can be used by people with disabilities, but also by search engines and mobile devices. The possibilities of these RIA components and design patterns on the web are now starting to emerge. But these are just foundational building blocks. What’s next step in this evolution of the development chain? And how can we leverage these design patterns now that the Web is starting to become available on mobile devices and game appliances? Should we adapt them, or come up with new patterns for other browsing devices? What consequences will multi-touch interfaces have for this work? Lots of interesting stuff to think about…
Comments closed (3 total) | Permalink
I think (or, rather, hope) that in the future people won’t just mindlessly use design patterns and javascript libraries, but also think about how to get them to degrade gracefully. Right now there’s a lot of hype surrounding AJAX and RESTful interfaces, for example, but nobody seems to care one bit about the fact that this means you need to start paying even more attention to keeping the site accessible. As if it isn’t hard enough already!
If you use AJAX to make your interface richer, the temptation is too great to just “forget” about people with Javascript disabled, or with user agents which don’t render the updated content as you would expect (screenreaders have some trouble with handling updated content in some cases). Thankfully, Rails makes the client-side part of AJAX really easy by assuming you’re going to do a regular POST in the HTML. It adds some javascript that rewrites the form so it will submit using XmlHttpRequest. This means it will only assume AJAX if Javascript is enabled. Unfortunately, you must add some extra effort to keep it working server-side because you can’t just unconditionally push a pure javascript response to the client. I noticed that often when under stress and with deadlines drawing near, adding code to handle normal POST request in actions just gets dismissed as “something we’ll add later”. We all know that won’t happen :)
The RESTful business is a lot worse in Rails. As far as I can gather from the documentation, it only works at all if you have Javascript in your browser! All this bad, nasty hackery to get HTTP verbs working properly in browsers (which are, after all, probably the main target of all user agents!) really defeats the purpose: You’re trying to make something more elegant (for some small value of elegant), but in doing so you implement an even uglier system than you started out with.
On the other hand, design patterns like ORM (though rather poorly implemented in Rails) are very useful in getting quick results. You build a database table and you instantly get a model class that can query and update that table. It makes your code a lot DRYer and less error-prone, too. Other favorite design patterns of mine include the enum with function pointer table combination, writing a DSLs to make your expressions shorter or more natural and behaviour-based unobtrusive javascript which has, besides obvious client-side benefits, the advantage of reducing code if done properly. I’m talking about code design patterns here, but this of course applies to interface design patterns too. They free you from thinking about how to get mundane stuff working so you can focus on the big picture (or the funky project-specific details).
So, in short, I agree that design patterns can be a great productivity boost, but you should use them with a bit of sense.
By the way, I just noticed that your site tags the ‘screen.css’ as ‘alternate’ on other pages than the front page, making the design disappear on the comments page.
Excellent comment, and you point out a glaring omission from my article. I have to add that my experience with patterns is mostly from an interface designer perspective, not from backend programming. Starting with semantically coded (X)HTML and CSS, it’s getting a lot easier to unobtrusively add behaviour with these Javascript libraries. I especially like jQuery, which is a lot easier to grasp for designers. Like you point out, slapping together a collection of design patterns won’t make a great web site or application, but I do think they can immensly enhance our workflow, and enable us to focus on more abstract problems instead of dealing with quirky browser behaviour.
(And yes, there does seem to be something wrong with the logic behind my alternate stylesheets, I’ll look into it as soon as time permits. Thanks!)