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.

Cheap Is New Cell-Phone Mantra

A very interesting article from Wired about a new trend in the mobile phone market, towards simpler, cheaper phones. As part of this trend, the GSM association has launched its Emerging Markets Initiative. The idea is that in the developing world, millions of potential customers could be reached with a cheap cell phone, a reserve of untapped growth for the handset market. But this is not only for developing countries. This parallels another trend, similar but different, towards more targeted phones examplified by the Vodafone Simply VS1, (by French manufacturer Sagem) which I have mentioned already.
The Wired article can be found here.

European mobile phones manufacturers: Sendo, one more to go!

It seems like it's hunting season and that the European mobile phones manufacturers are not doing well. Sadly, cash-starved UK-based Sendo was put into receivership on June 29th. Sendo must have been talking around for a while, because Motorola quickly announced it was buying most of the assets of Sendo. This if great, given the quality of the products and the technology.
In a previous post, we mentioned that three manufacturers have recently left Europe: Siemens, who sold its mobile phone assets to BenQ, Alcatel, who sold its shares in the joint-venture it had created with chinese manufacturer TCL just a year before, and Mitsubishi, who closed its research center in France, a year after closing its factory there, laying off 1,000 people. All this in less than six months, with Sendo closing the march. What a semester!
Needless to say, this will have an impact on the rest of the industry, and particularly for the European suppliers to these manufacturers. There is the real prospect now of a disappearance of a once-vibrant industry.

Why is a phone UI so different from a PC application (part 2) ?

In part 1, I discussed why a mobile phone set of applications is radically different from that of a PC, and why it matters. In this second part, I discuss more specifically about the difference in terms of user interface of the applications.

In a PC application, the user can find all the possible actions in a single screen. This is possible and efficient because the user’s actions are executed by clicking on a position of the screen (ie. through a widget) with a pointing device. Additional screens are often used to specify some rarely modified parameters. When an action needs more than one screen, wizard-type screens are used in a one-dimensional navigation way (ie. back/forward navigation). The installation of a new hardware is typical of such a succession of screens.

This means that when an action needs to be defined (ie. information must be entered in several fields, boxes must be checked, items must be selected within lists,...) it's up to the user to decide in which order to enter this information, and he can always see/check all of it at once. There is no pre-programmed navigation.

Furthermore, a PC application is rarely interrupted by unexpected events coming from the platform itself. Of course, on a laptop, a battery alert may be displayed by the underlying system but it will not really interrupt the user, who will just have to acknowledge that by clicking on a button in a window that is clearly not part of the current application.

Last but not least, a PC user has usually been trained to use his computer and he is using it in a dedicated place such as an office....

Things are very different with a mobile phone. First of all, the screen is small and there is usually no pointing device (ie. no mouse nor touch screen). This means that when a component needs to get more than a single information from the user, it must do so by chaining several screens. But in order to ensure a consistent experience, each screen must be specially designed to stay intuitive. As many of these screens are part of the overall application, a screen may often be used in several different contexts: it must be generic, but properly so; otherwise, the user gets lost... For instance, a screen designed to select an entry from the phonebook is used at least in the phonebook, the call manager and the text message composer. Building a generic screen that maintains consistency while guarantying that the action expected from the user is never ambiguous is a real challenge.

So an action is very often split across several screens, each of them being used in several contexts to perform distinct actions.

A mobile phone must also handle unexpected, disruptive events in real time. For instance a phone call may occur at any moment when the user is in the middle of a succession of screens to perform a complex task. During this call, a second call may also occur, and in a well-designed device, the user must be able to directly insert the details of the second caller in his phone book ! In the meantime, the SIM toolkit may issue a request, or a text message may arrive...

If we consider that any of these events must be handled with the proper priority level, and that many qualifications requirements (GSM, STK...) must also be respected, the hierarchy tree of all these screens may get very complex. Much more so than any PC application regarding the ease of use and the cinematic of the actions.

And all this must be kept simple for my mother in law to use !

There are other points making the development of mobile phones' applications complex. One of them for instance is when the handset is sold by operators, which is often the case. In that case, the operator is considered by its customer to be ultimately responsible for the quality of the complete offer, from the handset hardware to the network coverage. Any weakness in this chain is considered a service breakdown. So the applications embedded in the handset must be "carrier grade" and need to minimize calls to the operator’s customer care service. So manufacturers need to design applications with two customers in mind: the operator and the end-customer itself. An additional factor of complexity, and not a small one.