The Evolution of Web UI Components
Several months after the official release of Microsoft’s ASP.NET AJAX, I am still waiting to be amazed by slick web components from Redmond that make it possible to create rich, interactive user interfaces without third-party component suites. From the looks of it, my wait is not going to end anytime soon. With all the attention Microsoft is showering on Silverlight, it is now obvious that the component aspect of its AJAX solution has been and will continue to be a step-child. The message is clear — if you want to make your apps more responsive with fewer postbacks, use AJAX; if you want to create graphically rich user interfaces without spending a lot of time, use Silverlight; if you want to create graphically rich user interfaces that are also usable, keep looking.
Seriously, what is the ASP.NET team thinking? Is the crap officially named ASP.NET AJAX Control Toolkit the best Microsoft can do? With a handful of exceptions, these components are a joke. They are ugly, clunky and lack consistency in their usability. What is the deal? Are there no designers or usability engineers in the company that can help the ASP.NET team fix this garbage?
In all fairness, I should not single out Microsoft. This problem occurs more or less across the board. Every major AJAX framework is so heavily focused on the technology, that usability and elegance are after-thoughts. DOJO and YUI have the exact same problem at varying levels. Excellent frameworks…mediocre components.
If you want slick components, you have only one choice — break out the wallet and check in with Telerik, ComponentArt or Infragistics, or write them yourself.
Crappy components are just one small aspect of the problem as I see it. There is a much, much bigger problem — each of these free (and commercial) frameworks is guilty of delivering a solution that puts the responsibility on developers to work out the appearance and overall user experience of an app that makes use of its components. Let me repeat that…the responsibility for appearance and user experience is placed on DEVELOPERS.
Take those alluringly elegant components from Telerik and ComponentArt, put them into the hands of your average ASP.NET developer, and what do you have — disaster. Why? Because there is nothing that makes it easy for a developer to:
- Determine in which situations it is appropriate to use a certain component
- Make multiple components work together so the user experience is fluid
- Style components so they have a consistent appearance, different from the shipping default
- Interchange or mix in the same app, components from different vendors without going insane
It seems to me that components are not the solution, they are the problem. Ever since Visual Basic 1.0 gave developers the means to easily drag all manner of UI widgets onto a canvas, we have been stuck with this problem of horrible user interfaces. And no one has fixed it. Now, don’t be telling me about Silverlight or Flex or RIA. They all are stuck in the same evolutionary rut. All they are doing is swapping out the what and the where; the how remains unchanged.
There are enough desktop and web applications out now where it should be possible for us to evolve past UI components and isolate and identify UI patterns that can then be used to create “UI Pattern Panels” that snap together to form a complete application.
How would these be different from components? Well, for one, they would represent a complete solution. Let’s take a common situation — tree on the left, data grid on the right, some action icons on the top, some action buttons on the bottom. I have just described some 90% of apps that allow management of any kind of hierarchical data. Instead of a developer wiring all this together with individual components, this should be a “Tree-Grid Data Panel.” Instead of having a zillion places where a developer can customize the styles, colors, fonts etc. there should be one for the panel. That’s it. You can’t muck with individual pieces. This might be painful at first, but once you get used to not mucking with the individual pieces, it leaves you with more time to focus on more important things and create a better solution. Does this sound familiar? You bet…it’s “convention over configuration.”
To its credit, the YUI! team has taken a small step in this direction with its Design Pattern Library. This is not nearly enough. TIBCO, which has arguably the most elegant and powerful UI suite of all, the TIBCO General Interface is heading in the generally correct direction with a SOA emphasis on UI components.
Who will put UI’s on Rails? What do you think about component-centric versus pattern-centric approaches to user interfaces?
