---

GUI, the final frontier. All the bits flowing through the network, all the lines of code running through the processor, all the DSPs and the codecs, all the man-years, and what the user will see is just a GUI. And they never let programmers touch the GUI, now do they? That’s the designer’s job, and while a few designers dabble in programming to some degree, user interfaces designed by full-time programmers tend to stand out for being, how shall I put it, “practical”.

Practical UI vs. Pretty UI

So programmers stick to their console windows, their favorite GUI toolkit language, and they realize that once a designer comes along, he will wave his magic stick and create the magical GUI experience. The one that the programmers will slam because it’s not practical enough. This is, of course, because they give bad requirements (if at all).

Where Interface and Protocol Meet

Many efforts have been made to combine protocols with interfaces. In the world of SaaS and cloud computing, this makes a lot of sense. I’ll focus, therefore, on GUI accessed through the network. The application should be accessible from a remote client, but we want buttons to be responsive and the display windows to refresh in real time. We want to use it from different operating systems and hardware, but we don’t want to invest the development effort. A very good FAQ sums it up nicely (including comparisons to AJAX, HTML, Flash, Java, etc.) and links to many of the solutions available today, like RIA, Adobe AIR, WHATWG, XUP. There are more, I’m sure. One thing in common with them all is that they are doing it the wrong way.

The main idea of most remote GUI protocols, nay, with most multi-platform GUI toolkits, is the assumption that all users must see the same GUI on all platforms. That may have been true when nearly all users were teen to adult, used a PC, had about the same screen resolution, used the same input devices and used a limited set of applications. Today we have handhelds and home entertainment centers; we have multi-touch screens and wiimotes, we have nine year olds and ninety year olds using the same applications, and they cannot possibly have the same needs. A good trend today is to use HTML and have different CSS files for different types of devices. This is done today specifically for mobile devices (and iPhone in particular), with the tiny problem of having to redo the design part of the page all over again for each device out there.

I’m not even talking about the edge cases: I bought a laptop a few years back with an insane screen resolution, especially for its screen size. Now, LCD screens only look good in their native resolution, and I hate squinting, so I just set the DPI to a higher number so that windows will increase the font and icon sizes appropriately. Do you realize how few application developers consider this possibility? I have non-resizable windows with the text just sliding off the window’s edge. I have buttons that are rendered outside their window. I swear. A lot.

 
Messed up mouse properties window (not resizable)

What I’d like to See

I want a GUI protocol that will not tell the client how to render the GUI, but instead will tell it what resources the GUI needs. Some ideas:

• If it contains a menu, tell it what’s on the menu.
• It could indicate the application needs some message box resource, a video output resource or a rendering window.
• It could detail buttons with optional text and an icon (perhaps a vector representation of it, so it could be easily resized), entry boxes, check buttons, etc.
• The elements could be listed according to association, so that elements relating to the same issues will be grouped together.
• Furthermore, such elements could be prioritized: elements marked as vital will have to be rendered, and then the rest can be rendered according to some importance and usefulness factors.
• Perhaps a “skill” factor can also be added to hide or expose advanced options.

What will be left for the client is the actual appearance of the GUI, which can be classic or 3D, space-economic or greedy, hardwood or liquid-metal. As a bonus, if all the applications running use the GUI protocol, the user’s desktop (or TV, or mobile device, or whatever) will look stunning. It will be like a theme, only more than skin deep. It will also balance the load differently between GUI designers and interface creators: the protocol will become a very detailed requirements document, detailing every option by importance and accessibility, and it would be the job of the client designers to take these requirements and provide a suitable GUI. A suitable GUI, in this context, is a GUI that fits the device’s capabilities and user’s preferences: simple and compact for handheld devices, large for hi-res systems. Mobile device manufacturers can provide a client that would render web applications as if they were part of the phone, while HTCs can let the user choose a theme and theme variants for each application. A utopia? Maybe, but as the user variance increases, so would the necessity for such a solution.