David Emery Online

Ideas

19 July 2005

About a month ago I wrote about what ideas desktop applications could take from the new breed of web apps; recently I’ve been thinking about the reverse: What ideas can web apps take from traditional desktop applications?

With recent advances in web technology, most notably AJAX but also with Xhtml and CSS, making web pages more dynamic has become a whole load easier and hence opened up a path to more user friendly, more powerful and more useful web sites. However, we’re not quite there yet; it’s going to take a bit of transition for both the developers and the users before we settle down on a new breed of sites. Also, most sites will not radically change – most of the sites out there at the moment work pretty well as it is; the current web technology is quite good at providing information-rich web sites (that’s what it was designed for), it’s interactive sites that will see the most change.

Hopefully we will see some standardisation in interface conventions, or at least some form of best practises guidelines. On the mac we have a great document called the Apple Human Interface Guidelines, which outlines pretty much exactly how you’re supposed to design the interface of a mac app. Having this document is one of the reasons that the mac has had it’s traditional “ease of use”; most mac apps work in the same way, using the same menus for common functions, having standard margins between controls and using different control elements (such as buttons, tab groups and Inspector palettes) in a consistent fashion. This means that during the initial learning phase when a user first uses an application, they don’t have to learn the aspects which are common to all programs, only the elements unique to the app. Of course, recently Apple have taken to ignoring their own guidelines (or rewriting it to fit after the fact), which leads other developers to do the same, which is a great shame.

What would be really great if there was some form of standardisation of web UI conventions too, so the user doesn’t have to figure out how each and every web app works. For example, when an web app is loading data, it’s going to need to show some form of progress indicator; or when you’re switching between different panes of information you going to need some form of tab control; or when you have a “Submit” and “Cancel” buttons on a form, which way round should you have them? There are, or course, a million other issues like this that each and every web app has to deal with, and currently about a million different hand-rolled solutions to each.

One possible solution, which I think would be really quite cool, would be to add more complicated controls into the Xhtml standard – we’ve got buttons and text fields, how about tab controls and progress indicators? We would also benefit from standard groups of controls, like being able to place a “standard” Submit/Cancel button group. Being built into the browser, as opposed to being constructed out of normal Xhtml + CSS these would have the advantage of being OS specific, so on a Mac browser a tabbed pane would be the normal mac tab pane, which looks like a multipart button whereas on a PC it would look like the more traditional tab view.

Of course, changing the Xhtml specs is quite hard; also, what I’m suggesting probably goes against the sort of thing the w3 committee go in for (which is fair enough really, I think the simpler the specs are, the less problems caused). An alternative, then, is some form of standard controls library. This would need to be flexible, easy to use and highly compatible. It wouldn’t have the OS integration benefit that the other solution has, but it would still have the benefit of achieving some consistency across sites. Also, the easier the controls are to implement by the developer, the more benefits they can convey; if the controls can just be slotted in and all use the same margins and guidelines and are really easy to use, then the lazy/time-poor developer will use them (and they’re the ones most in need of help).

One of the main reasons modern mac apps in general have consistent interfaces is that it’s all done for the developer automatically; when you make a new mac app using cocoa in Xcode you get presented with a skeleton app which has all the menus hooked up already and with a blank window waiting for you to add content. When you get to creating the UI, you use a wonderful program called Interface Builder, which allows you to visually layout out your interface using drag and drop, and when you move interface elements around they automatically snap to the recommended guidelines for margins and padding. With a lot of the hard work done already, if you want to do something odd interface-wise you really have to work at it, which is always a bit of a give-away that your doing something wrong.

So, to couple with a set of comprehensive user interface guidelines and a library of user interface widgets (whether they’re browser built in or a separate library) what we need is a really simple development environment that makes it hard to do things wrong. One of the recent trends in the web world is to develop web apps using a framework called Ruby on Rails , which does a lot of the low level programming for the developer, leaving them to focus on the interesting stuff. The framework actually has quite a similar philosophy to Cocoa, both enforcing good object orientation practices and both being quite high level, doing a lot for the programmer (so they can’t screw it up).

What we need, then, is an Interface Developer equivalent for Ruby on Rails. Now, this hypothetical app should actually work with any coding language, whether it’s php or ruby or whatever, but tight integration with RoR would just further aid the idea of keeping the coder away from the underlying aspects (so they don’t mess it up).

Cross platform as well, of course. Actually, why not a web app?