Is a browser-based User Interface the right solution?

In this post, I discuss a recent article by Benoit Schillings, CTO of OpenWave, about using the browser as a unifying paradigm for mobile phone user interface. I explain why I think this approach is a dead end.

There was a very interesting article written by Benoit Schillings, the CTO of OpenWave, about the user interface issue on mobile phones. Schillings is a veteran of the software industry, having previously worked for Be, Inc and before that for Belgian software vendor Mainstay. OpenWave is a leading supplier of software applications for mobile phones and has played a significant role in the emergence of the WAP when the company was still called Unwired Planet.

Schillings highlights the growing importance of the UI in today’s mobile markets, for manufacturers as well as mobile operators. Growing requirements and technical complexity makes manufacturers’ life more difficult, while at the same time content providers are looking for ever more sophisticated features. However, he remarks that the two traditional tools used so far to create user interaction, the WAP browser and direct C programming have limitation. Clearly, only a limited of features can be offered through WAP services, namely information-rich services. As for C programming, it is used only for heavyweight development efforts and removes any flexibility.

So, which solution? For Schillings, Web-application environments offer an attractive alternative to embedded or native applications. His suggestion is to base UI development on a Web browser, and extend the browser with scripting, much like what exists on the Web. According to him, “As an industry, we are rapidly moving beyond the browser as a stand-alone application and toward a model in which the browser acts as an engine for dynamic content, applications and flexible customization.”

Is that true? Can indeed the browser be an effective base for the UI of the phone? I believe not, and I’d like to explain why.

Let’s start by saying that a browser can certainly be used to create a phone UI. It is technically possible. As I discussed in an earlier post, it is also possible to write a UI in Flash, but not effectively. The question is the same for the browser-based approach: “is it effective?”.

Let’s imagine we want to build a UI with a browser. There are things that a markup language can represent effectively in the UI such as the screens layouts, buttons, links, and information display. The remaining 80%, however, would be too complex to be described by a markup language. This would include all the links with the underlying API of the phone, all the graphic elements, screen transitions, etc. In short, all the UI that needs a procedural formalization would have to be done through either C libraries or script. And this is precisely what Schillings suggests: using scripting to complement the markup approach.

So here is what our solution would look like: a combination of markup language, multiple scripts and libraries, all combined in one single environment. But when actually implementing a UI, one would find that the markup language would probably not represent more than 20% in terms of work Why so little? Because the particularity of a mobile phone, unlike the PC, is that it is a highly integrated device where the graphic constraints are very high (see a previous post here). For instance, while a bitmap can have a relative position on a PC screen, bitmaps have always an absolute and precise position on a mobile phone. As for user interaction, there would be a need for heavy scripting indeed to match the sophistication of today’s, not to mention tomorrow’s phones.

Question: if markup language browsing is used for only a limited part of the UI, and if the browser’s logic, which justifies its usage, is de facto not used, what use is the browser? Why take the pain of redesigning the whole UI around the browser if its use amounts to that of a graphic library?

That is not all. Having three different paradigms within one single environment makes the platform a nightmare to maintain. That is something Webmasters have known for a long time, but here again, the specific constraints of the mobile handset makes it even more of an issue. In addition, scripting is resource hungry, which is a further problem, while the integration of three heterogeneous environments leads to performance problems.

A browser-centric approach is supposed to be simpler than using C, but that doesn’t seem convincing. Indeed, browsing is suited to user-initiated events, but not adapted to other events, such as those generated by the platform or the outside world. But “non user generated” events form an important part of all the events.

In fact, this approach has already been attempted by UI specialist Digital Airways two years ago. Digital Airways, interestingly enough, was initially a vendor a Java WAP browser. So when working on a new UI solution with manufacturers, they of course first came up with a browser-based model. They even had a white paper explaining why a browser-based architecture was the right approach.
While the fact that their solution was Java-based helped reduce the heterogeneity problems, they quickly hit the wall in terms of technical architecture. It was relatively easy to create nice prototypes, but moving on to the industrial phase showed that complexity quickly went beyond control. An actual implementation of a manufacturer’s UI was an unstable collection of scripts that could not avoid side effects. Simple modifications in the specs often implied changes deep into the coding. As the model was extended to become more effective, the browser was less and less used. After a long debriefing process with the manufacturer, Digital Airways threw everything in the garbage, and started from scratch with a UI engine based on an abstract UI model.

This experience is useful. It shows that while on paper, everything is possible (even cycling from New-York to San Francisco), one should be careful not to extend a conceptual model beyond its area of relevance and effectiveness. The more you do so, the more the cost goes up. At one point, the incremental cost becomes greater than the incremental benefit. The area of relevance of the browser is the interaction with the user for data-based services. That’s already a lot, but beyond that, and in particular for user interface, a different, and specific solution, must be used. Digital Airways’ UI engine is one, UIOne by Qualcomm in the BREW environment is another one.

OK so that makes me think I should do a post on who does what in the UI space and compare the various approaches.
Benoit Schillings' article is here, but you need a pay subscription to read it.