The problem is not Ajax – or frames, or Flash… The problem is the Web itself. It has evolved from the hypertext model (the original design, which had the page as the main unit – see the beginning of Nielsen’s article) into the application platform model. The paradigm had changed – but the tools remained mostly the same, and that’s the source of most of the usability problems, which Nielsen attributes to Ajax.
The tools, which we are using to work with the web are obsolete and outdated, because they still tend to work with the pages. But most of the page attributes have little to no sense in the context of an application:
- URLs don’t work for applications, because the application either simply cannot restore its state to the one “specified” by URL, or it can – but the URL becomes such a monstrosity, that we now have specialized on-line services which can replace unwholesome long URLs with a short alias. The same goes for bookmarks.
- “Back” button, that bane of web application designers, also has no place in the application world. (And “Forward”, and “Reload” too).
- Search engines cannot work with applications correctly.
So, the right – and the only – way to go is not to try and force the new paradigm into the Procrustes’ bed of old tools and metaphors, but to adapt the tools for the new world.
Here is what, in my opinion, should be done:
1. There should be a way for the client to tell old-fashioned web site from the application. Of course this will be a responsibility of the site designer to mark it correctly – but the server should somehow tell the browser (maybe with a new header?): “You are entering an application – switch to the app mode”.
2. URLs as we know them should be replaced by a more generic object, which can hold more data in a better format. This object – let’s call it a “neolink”- should be used to tell the browser where to go, and provide enough data for the application so it can restore the required state (if possible). Under the hood a neolink may be just an XML file. The bookmark managers will hold neolinks instead of URLs; neolink may be sent in the mail as well. The URLs will be used only to address old web segments and to point browsers to the applications’ entry points.
3. Browser buttons should be customizable, and should interact with the application. The easiest way – the button should just call a JavaScript handler.
4. A special protocol should be designed defining the interaction between an application and a search engine. Maybe the application can provide special pages for search engines, which will hold the new information and links, or provide a “search engine” login.
If – or, rather, when – these changes will happen, the usability problems described by Jacob Nielsen will simply disappear. Of course, some new problems will arise – but we will know about them only from Jacob Nielsen’s future articles.
No comments:
Post a Comment