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.

The sad state of the mobile User interface

In a very interesting article called "Make way for the iconic icon", Sofia Svanteson, from Ocean Observations, regrets that the user interface hasn't made much progress in a long time.
I can only agree with her. I am the unfortunate owner of a Nokia 6670, which to me is the perfect example of everything a phone should not be in terms of usability. I used to be a great Nokia fan in the late eighties. Back then, Nokia was such an incredible design. But the UI has never been Nokia's forte. Now it's gotten worse. It's not only, as Sofia points out, that Nokia's designers seem to have skipped their classes, but it's also, as I discussed in a previous post, the fundamental mistake of thinking that a mobile phone is a small computer, and that you can pile up functions and icons without damage. That's plain wrong, and as usual in constrained environment, design matters. That's something SonyEricsson seems to have understood, but the way is still long.

Why is a phone MMI so different from a PC application (part 1) ?

In this post, I discuss why a mobile phone set of applications is radically different from that of a PC, and why it matters.

In the early age of the PC, text-based applications were using many different paradigms. Consider the following constraints:

• As there was no pointing device, every action was managed by moving a focus on active elements
• As there was no window, complex actions were splitted over several screens
• As there was no concurrent applications, it was not possible to call an external application to "use a service"
• As the service layer of the underlying platform was not integrated to the Operating System, the developers of a new application had re-invent and re-code everyting each time it was needed.

In this context, even small applications needed large developments, and large applications had the opportunity to be very well integrated as everything was by definition "customized" for them.
But as the PC was a multi-application platform, the user also had to re-learn everything each time he was switching from one application to the other.

Hence the repeated attempt by some vendors to create integrated programs. Remember the "integrated suites" like Ashton Tate's "Framework" ? They failed because by the time they were introduced, their drawback (a limited version of every function) became more important than their benefit (integration) as the platform became ever more powerful. One of the reasons why Microsoft became strong in applications is that, in the great debate over multitasking in the early 80s, they bet on the modularization against integration. On the PC, that made sense.

A mobile phone is very similar these early PCs regarding the hardware:

• There is (usually) no pointing device
• Screen's size are reduced
• Computing power is limited

but the evolution of the software development is different.

First of all, a mobile phone is NOT supposed to be a multi-application platform. I don't mean here that a mobile phone must have only one feature, but that the applications that it offers are not supposed to change. Of course, so-called "smart phones" are able to load new applications, but we also know that their usability is significantly lower than integrated phones. By definition, being able to add new applications means that the level of integration of individual features is much lower... What we get is a collection of inconsistent applications and reduced performance (look at the time it takes to launch a new application on a Series60) due to the modular approach chosen. In my view, the modular approach is not relevant to the mobile phone and it is a mistake to try to replicate the PC model on such a small device.

In other word, allowing the user to add new applications on his mobile phone means modularizing and opening the platform. But modularization is -by definition- always achieved by reducing the level of integration of core features...

Do you remember the first Palm devices ? The reason why they were so easy to use, and why they became so successful, was precisely the fact that the features (Diary, Phonebook,...) were all integrated in a single application !

And reducing the integration means reducing the usability for its basic functions, why very often become buried in some submenu. IMHO, this is enough to cut an estimated 80% from the mobile phones market.

From here, we can conclude that to improve ARPU, a telco needs to make the features it tries to sell easier to use. And the more it wishes to push a new feature, the deeper it needs to
integrate it in the device... and thus the less "versatile" the platform should get. For the time to come, performance and usability will remain the key to success, and that means integration, not modularization.

In a post to come, I will discuss how this integration impacts the ease of use of the applications, making them so different from their PC cousins.

Vodafone Simply rethinks the mobile phone

I've already mentioned the Vodafone Simply phones (VS1 and VS2) because I thought that they could indicate a new strategy by Vodafone. This is also what Ovum's analyst John Delany thinks. he writes "Vodafone Simply is the most important example to date of a trend which, we have long argued, will be one of the main influences on the shape of the European mobile industry over the next few years."
Read John's comment here.