The Impending "Implementation Independent" Interface
What is a Widget?
When I say â€œWidgetâ€, what kinds of things come to mind? If asked you to name a few widgets that you know of, what would you say? A button, perhaps? A scroll bar? Maybe tabs, check boxes, of course, and radio buttons, spinners, sliders and more? On and on I am sure you can come up with examples of widgets... But if you look careful at your answer, and you compared to the answer of a heavy client-side engineer, or at least to his code, you might see some interesting discrepancies...
You see, the average user or developer is probably not very likely to respond with â€œJButtonâ€, or â€œGTKPanelâ€ or QTComboBox, or any other â€œconcreteâ€ implementation of the widget... that would be silly... and yet, a client side developer's codebase will be filled with nothing BUT those concrete interfaces... It may seem to be a small detail, and yet...
And yet I never see a developer bypassing JDBC to talk to directly to the methods on a particular driver (They use the Connection and the ResultSet... not the HSQLDBConnectionImpl or the Postgres81ResultSet), nor do I see a Servlet developer specifically casting to Tomcat's particular implementation of an HTTPServletRequest. In every other area of Java developerment we have nice interfaces and APIs to shield us from underlying implementations, to ensure that our database code works the same, for the most part, no matter which DB we use...
So why is the UI always given special treatment? Why do we work at the implementation level and not with the abstractions of the widgets? In a nutshell, why can't the JButton implementation of Swing also be used to manipulate an AJAX widget on a web page, or a JOptionPane present itself as a "Are you sure? [Y/n]" on the command line?
A widget, as most people seem to feel, is defined by it's behavior, and by the abstract visual elements that are exposed to the user, not by the final runtime implementation. UI designers don't think in terms of â€œput a Cocoa drop box here and a KDE password entry field thereâ€... that just doesn't make sense. They think in terms of the abstractions. They think they want a password field, but what kind that turns out to be in implementation is meaningless, as long as it look like it should on a particular platform.
A widget is not just the sum total of a single implementation, it's the UI element in the abstract... the manipulatable interface component as it exists as pure thought; as seen by the mind's eye. The UI itself is the same. It is not defined by the quirks and behaviors of an OS, but by the way it behaves, by how buttons are laid out, what buttons do to the internal state of the business logic when you press them.
So the question that should come to the mind of any Java developer who spends a great deal of time on pure client-side applications, especially one who is familiar with the the design process of most web-based UIs, should be: Why do we develop our client UIs at such a low level? Is it required or just the result of legacy development? Is there something fundamentally different about the client-side GUI that requires it to be so different?
GWT: Accidental Inspiration.
While it's cool to be able to develop AJAX applications so easily, what I really took away from that, what really got my attention, was the concept of using the same underlying code-base to develop two completely, fundamentally different interfaces...
Unfortunately, however, what I thought I saw was just an illusion (it does not seem to compile to Swing in hosted mode... it just compiled to a set of Java classes that drive Mozilla though native bindings). But even though it isn't exactly what I imagined it was, an idea was already stuck in my head. What Google had done here, although I don't think they quite realized it, is to stand right on the edge of a new UI paradigm that could revolutionize interface design if it were to catch on.
III: A new paradigm borrowed from the past.
Implementation Independent Interfaces (III), that â€œnew paradigm" I refer to isn't actually new in the sense that no one has thought of it before... The concept has been around for at least, perhaps, 30 years... It's just that it seems that no one has ever really created it before, in a lasting way. The concept goes like this:
As mentioned above, UI Widgets are best manipulated by designers in their abstract forms. Implementation Independent. The UI designed for Mac should look and function, except for some small look and feel differences, (and maybe some other small philosphical differences in terms of "recomended interface guidelines"), in roughly the same way as the desings for Linux and Windows. More to the point the design for the web-based version, or even the ncurses version, should not require a signifigant rewrite of any part of the business logic of the application.
To this end, the core of making III a preactical reality is first simply finding or creating a neutral widget-based language. This should be something that will be able to express widget placement (exact x,y placement or using some kind of â€œlayout managerâ€ style declaration for dynamic placement), widget states (size, enabled/disabled/invisible/etc), the relationships between widgets (containers, parents, children, focus management), and some ability to manage the event mechanics (generates event X when clicked, event Y when a key is pressed, etc).
Finally it should have some facility for graceful degradation (i.e. defining â€œacceptableâ€ degradation states, what to do when java script is turned off, or exact positioning is not possible, or when the x,y coordinates are meaningless (such as for the text-only UI), or when feature X, Y or Z is not available, or supported in a strange way by a particular UI implementation, or in the case of cell-phone web browsers, in similar but limited ways). This facility should not be overly complex, however, and it should only concern widget placement and behavior (the idea being, this language should always be as abstract as possible, even when dealing with specific UI implementation quirks). And that is just about all this language should be able to do.
To make it completely functional, perhaps there should also be some framework or commonly accepted system for building new types of widgets as well, and some other bits and pieces here and there (sorting out "recomended ui guidelines" differences, ), but in general this is enough already for the vast majority of â€œsimpleâ€ GUI based application (mail/news readers, IM clients, database UIs, bit torrent clients, simple charting, etc).
Bringing the wild and wooly client side developers into the flock.
The reason why I really like this concept, beyond simply the novelty of being able to make web GUI and an Swing GUI in one simple shot, is that it removes the special treatment from the GUI, and creates a true â€œviewâ€ in the MVC universe. If MVC is all it's cracked up to be, swapping UI implementations *should* be as easy as using a different command line flag.
Now, of course this is not going to solve every problem for every person, especially not at first, in it's infancy, but it would solve, for the vast majority of GUI applications, the one serious problem that exists for most GUI developers today: the inability to unit test.
This structure would allow for incredibly easy testing at many levels in GUI application development. In fact even at the level of individual widget behavior. The only place that should still be out of reach to the unit test would be the actual rendering operation on the visual device.
Imagine, in the same way that you could compile your UI into a KDE-based implementation, say with the â€“ui=qt flag, there could be a â€œtestâ€ implementation of the UI available as well (â€“ui=test). The result would be nothing but non-visual event processing objects, with the same basic internal behavior of a visual component, additionally with some easy way to manipulate and check states on them, yet which exists completely at the code level and never attempts to draw to a graphics object.
Finally the GUI cowboys can be brought in from the open range. They can trade thier debugger for a pocketful of test cases and let the railroad of automated testing bring thier applications to market far quicker than driving the herd on horseback. How nice it will be, spending nights asleep in a real bed, instead of with with your hand on your six-shooter, your face on the keyboard and the war-whoops of QA engineers as they dance around you and chant about the constant delays and whack-a-mole bugs...
In terms of testing, maintainability and quality, a proper wall between the functional and the visible components of a GUI framework will transform the bloodsport of Swing development into the relative shuffleboard match of XP-style web development. With any lock it will align client-side developers philisohpically and mentally with the rest of the engineering team, making tasks like implementing sustainable rates of development and agile methods something you can implement across all levels of the company.
So where do we go from here?
We are already headed in the direction of implementation independent UIs (just watch how HTML gets more and more complicated every year), but so far we haven't have any successful push to develop the concept in any directed, focused way. It all is being grown up somehwat organically, from what I can see, and will continue to do so unless someone steps up and takes charge.
Mozilla's XUL and Microsoft's XAML will bring us one step closer still... but at best they are complex to use (all XML-based â€œprogramming languagesâ€ are going to be difficult by default... and when XML and Microsoft collaborate on anything the result tends to be, well, a tad verbose), and they don't really give you the power of a language like Java, requiring a great deal of work to do anything computationally complex, and worse, require using languages and other tools that don't properly support OO principles and methedologies to the level that is needed to bring the most value.
Additionally, there is a long hard struggle that will need to take place by people more patient and probably a lot smarter than myself to develop a proper UI modeling language that is abstract enough to capture the majority of cases, yet is also extensible for special cases, all the while being easy to use and maintain without the little XML nightmares of schemas and namespaces. Even after that was complete, there would still have to be an effort to implement the language compiled to handle each of the various GUI toolkits, taking into account the incompatibilies, the bugs, the fundamental design issues and the other gotchas that each toolkit will invariably have.
But, despite the caveats and problems, I feel that it is not going to be impossible, and it is not going to be too much longer before this paradigm shift becomes the new state of the art in GUI development.Collecting a list of the various similar toolkits I have seen while reading other's blogs on this. If you can find any more, please let me know. I'm curious how wide spread this is.