Skip to main content

On Computers, God, the Universe and UI

Posted by evanx on August 4, 2008 at 3:57 PM PDT

We gonna consider the definition and evolution of computer UI. But first, what is a computer? It's a number crunching machine that interfaces to a human being, innit. Actually, "data crud'ing" is probably a better depiction than "number crunching" in the world of business information systems.

fractals250.jpg
An Irrelevant Aside on Irrevence and Metaphysics

But let's back up a bit! Computers are created by man, for man. We're told that God created the world, and God created man, who created computers. But who created this "God," this incredible leverager of physics, creator of nature, lover of life, guider of conscience?

Many scientists believe there is no God. They have an unshakeable faith in the laws of physics, which they desperately strive to understand fully and properly, without approximation or simplification. One might say they believe in God without realising it - depending on what God is, which we don't know, but whose DNA might be glimpsed in the undiscovered unified theory of the universe?

But what has this got to do with computers? Well, maybe God is an AI - an unbelievably massive computer, existing on a scale too small and at the same time too large, too intrisic and too extraneous for us to fathom? Maybe our Big Bang and our Universe was created by an AI from another universe in other dimensions, who went into "God-mode"? Yeeaah baby!


The Evolution of UI

Let's consider the evolution of the computer UI...
UI 0.0 - Punch cards and big buttons to press eg. "Execute Program,"
and flashing lights.

UI 0.1 - Character-based terminals with a "submit" button (see also Web 1.0)

UI 0.2 - Character-based terminals with key-typed events

UI 0.3 - Rich Graphical Client/Server Applications (see also RIA)

UI 1.0 - Web 1.0 - HTML forms with a "submit" button

UI 2.0 - Web 2.0 - AJAX

UI 3.0 - Rich Internet Applications - Laszlo, Flex, JavaFX - consuming web services

The UI of the Internet is the Web, whose simple "hypertext" exposed and exploded the Internet into humanity's information network.

But arguably it temporarily regressed programming from a rich homogeneous client/server architecture to a clunky client-side built with HTML/CSS plus Javascript?!

We know that applets didn't succeed initiallly as expected. Now Sun is breathing new life into applets with JavaFX and the Java6 update10 plugin, rather than concede to Flex et al, and we hope that client-side Java will enjoy a resurgence of sorts, as a competitive RIA platform?


UI Defined

So what's the UI vibe? I mean, what's the problem and what solutions we got? Firstly, let's separate the UI into logical MVC components, and label them the UI-view (visual), UI-controller (logic), and UI-model (data).

spring250.jpg
The problem with UI programming is that we gotta construct a UI-view, and respond to UI events in the UI-controller. Web applications might use DHTML to construct the UI-view, while Swing and some other toolkits, including Web ones like Wicket and Echo, assemble a component tree.

The UI-view is clearly a visual thing, and so i (as in me myself and i) think it should be built using a visual WYSIWYG tool ie. a UI builder!? Whether it's an HTML UI, Flex or Swing GUI, it doesn't matter! Use Netbeans, FlexBuilder or whatever to create the visual aspects of the UI - problem solved, silver bullet loaded, safety on!

Now that we have a UI-view, we gotta process its UI events ie. code our UI-controller. We'll use Javascript (or Java courtesy of GWT), or an AJAX Javascript client library. Completing the picture, the UI-model is a server-side bean, or an EJB exposed via webservices.

While it might get slightly tricky writing custom Javascript code which has to be tested across multiple browsers, this is not an issue if we are using a nifty AJAX library, GWT, Flex, Laszlo or some such thing.

On the Swing side of the coin, we create listeners and SwingWorkers and what-not in our UI-controller. Also we wanna bind our components to UI-model beans, with validation 'cos users occassionally bash the wrong keys, heh heh!


Web programming vs Swing

So is "web programming" easier than Swing RIA programming? Who knows!? Firstly "web programming" is a very broad term, 'cos there's a mountain of available options, eg. GWT, Wicket, and also JSF/Seam which seems to be an emerging standard of sorts for JEE?

design250.jpg
Firstly assuming that the UI-view is always constructed using a UI builder, then we don't have to write any code for the UI-view, just drag and drop. So there's no difference in coding difficulty between various approaches for the UI-view 'cos there is no coding! (Having said that, UI builder's may not be available yet for some toolkits?)

Secondly let's assume that in the web approach, we use frameworks to automate and simplify everything as far as possible, eg. using AOP, convention-over-configuration, annotations, injection, binding and validation, eg. JEE/EJB3/Seam.

Given the above, i would say that Swing programming is more tedious than Web programming!? 'Cos Swing is quite low-level stuff - we gotta create listeners, register them, create workers, runners, and what-not. We have fine-grained control over the GUI, but we pay handsomely for that, D'oh! We aint got no convention-over-configuration, and we aint got no AOP.


Swing's pain points

So what are the pain points of stock-standard Java/Swing GUI programming, as opposed to other languages on the JVM with Swing bindings and builders and what-not? And can we anesthetise that pain?

Surely one option is something like the JavaSwingBuilder, where we define the Swing UI using markup, and our framework constructs the GUI, and conveniently wires up our event handlers and what-not. But what if we wish to use the Netbeans' GUI builder to design our UI-views?!

Arguably a problem is the "low-level" plumbing and boilerplate, for events, background vs EDT threads, and beans eg. firing property changed events.

So can't we eliminate boilerplate code from Swing as far as possible, using annotations, AOP, convention-over-configuration, eg. for beans binding, events and tasks? Then how would Java/Swing RIA programming stack up against Flex, JSF/Seam, etcetera? As my aging aunt says, "Who knows!?" ;)

Resources

https://code.google.com/p/vellum/ - where i will collate these articles and their code.

Related Topics >>

Comments

One of the things under appreciated about web 1.0 interfaces and generally lost in web 2.0 interfaces and RIA is the whole concept of referencing application state with a URL - it's incredibly useful to link/bookmark/hit the back button to arbitrary program/UI state both from the user perspective and the developer perspective - think about it - each screen has explicit ( links ) state transitions within it - each screen is almost independent - mashups are possible etc. I actually write a lot, and I mean a lot, of Swing based networked applications - used behind a firewall for a particular company like a lot of them are - and one thing that is really much more difficult to implement than it should be is the idea of one application launching another into some state - trivial with a web 1.0 type app - tricky with Java. How do you start the relevant app and pass the data? If the app is already running how do locate the instance versus starting another one? It's easy to control a web app from java, but not the otherway around - a nice url? How do you architect the apps so it's easy to jump to a certain point? ( Android app design patterns are interesting here - because of their need to deal with low memory then need to force an architecture that allows restarting with state ) Now you can have your apps running their own local servers and have a "try to connect - if not launch type" approach, but then you need to manage ports etc - you have both firewall and port clash problems - you end up needing a meta server to store dynamic info. I suspect their might be a webstart partly based approach but never really investigated - particular how you might pass context/state. Applets also may be a partial approach - you could generate web pages on the fly with certain applet parameters - but that doesn't solve the talking to existing running apps from a different web page. Also I've avoided applets like the plague for the last 10 years as the stability was frankly rubbish ( browser instability *plus* plugin instability ) - I may try update 10 when it's actually released ( and now the company has moved off Macs - are you listening Steve? ) The approach we take is to have all the apps running in the same VM - however this does necessitate some classloader trickery - context class loaders and third party libs that use them are a pain, UIManager is a pain - cross class loader data passing is a pain. So to sum that ramble up - how do you have rich client applications more mashable/compositional so that it improves user experience, developer maintainability and the ability to build integrated systems ( from a user, rather than backend ) perspective.

I'll paraphrase a friend of mine: Rich Web Applications are on the cusp of restoring the richness and usability of interfaces that we all exepected nothing less than 15 years ago in desktop applications, but built on top of an abused, shakier abstraction than ever before.

Have you considered commercial products for building UIs (like UI components libraries)? Perhaps it is "hard" building Swing UIs with "free" tools (open source) only...