[What makes up the mobile user experience and what are the mechanics behind it? Research Director Andreas Constantinou introduces several important concepts behind the mechanics of the user experience; the user journey, core vs downloadable apps and the future of power apps]
The user experience (UX) has been probably the most talked-about topic in the mobile industry, mostly because we all know that the UX suffers and we all have suggestions of how it can be improved, especially in the post-iPhone era. The (graphical) user interface has been the aspect of the UX which has garnered most attention historically, and countless software vendors have demonstrated solutions to improve the UI, from better text engines to gesture-based widget navigation.
However, few have actually suggested what the UI really is or how it works. What are its mechanics, or what makes the UI tick?. Here I ‘ll attempt to do just that.
User interface = user-facing applications A fundamental fact is that the user interface is made of a series of software applications; the idle screen, the menu app, the inbox, the camera app, the browser, the music player, a games or other downloaded application, etc. The ‘user journey’ is comprised of navigating in and out of different applications all of which collectively make up our perception of the phone’s UI. The handset OEM integrates the applications horizontally into each other, so that the end result is a seamless flow that hides the application boundaries. The following diagram is a graphical illustration of the user journey in the form of a circle, with selected core apps shown as an example.
The diagram illustrates several important properties of the user journey across the UI: – The idle screen forms the beginning and end of each usage ‘trip’ – The idle screen, dialer, menu and sms/inbox applications take up the lion’s share of the user journey. We ‘ve used arc lengths to illustrate the percentage of time each application is active, but it is by no means exact; in fact it is oversimplified in purpose. There are few published studies into the topic of application usage as a proportion of the user journey, with a notable one being Nokia’s 360 programme (see this presentation for example). – The arc length is proportional to the commercial importance of each application; the more an application is used, the more is the ‘usage surface’ and the commercial value of the inventory which it exposes. Among other things, this explains why Google opted for an operating system (Android) and not a browser for mobile phones, since the browser only makes up circa 5% or less of the user journey (see our earlier analysis).
Core vs Downloadable applications Another important notion in the mechanics of the user interface is the distinction between core (embedded) and downloadable apps. By core apps we refer to the set of applications which: a) form the vast majority of the user journey and b) are pre-loaded or embedded into the handset ROM at the point of manufacture.
Core applications are typically the idle screen, dialer, main menu, settings menu, browser, inbox, calendar, contacts, camera and multimedia player. Downloadable applications are all apps which can be downloaded post-sales, i.e. by the user. There are fundamental differences between core and downloadable apps, which impact the developer audience, commercial relationships, technical integration, accessibility and overal commercial importance of these applications. The next table summarises the fundamental differences between core and downloadable applications.Core applicationsDownloadable applications95% of user journey5% of user journeyIdle screen, dialer, inbox, calendar, contacts, ..Games, utilities, news, business, lifestyle apps,..Embedded at pre-load phaseDownloaded at post-sales phaseInterconnected horizontallyIndependent / not connectedOpen to 2nd parties (OEMs and partners)Open to all 3rd party developersNative appsNative, but also Flash, Java, Python, etc appsDeeply integrated into device APIsLightly integrated into deviceAccessed via 0-2 clicksAccessed through menus, i.e. several clicks
There is a lot that can be said about the above attributes, and each one is an article in its own merit. For example, widget-based navigation allows downloadable app usage to take up much more than 5% of the user journey; the limited accessibility of downloadable apps on mass-market phones is what justifies the tiny share of the user journey. Another notable point is that technically all operating systems enforce tight technical boundaries between core and downloadable apps, while Android and WebOS are the new OS generation that is breaking down these technical boundaries. Commercially though, no OEM or operator has yet allowed users to replace core apps with downloadable ones, due to the implied increase in support requirements and related liabilities.
Overall, the difference between pre-load and post-sales installation of applications has huge ramifications in terms of technical and commercial route to market and barriers to entry; for example, any one can write an addressbook application on S60, but only the OEM can make this the default addressbook application, or offer access to otherwise ‘hidden’ APIs for integrating the app horizontally into the other core apps.
Blurring boundaries and the future of power apps One of the most interesting developments in the mobile handset industry is how the pre-load and post-load boundaries are starting to disappear. For example mobile software management solutions are allowing modular installation and updating of core apps during the post-load phase (see our earlier research report on mobile software management); platforms like BREW MP, Java (on S60), and S60 are featuring modular updating and/or dynamic module loading; Android and WebOS are offering a simplified application environment for core apps open to all 3rd parties; Core apps are increasingly integrated with the network and internet cloud, as is the case with H3G’s INQ1 mobile phone which integrates Facebook, MSN and contacts into the idle screen.
Moving forward we see the development of four ‘power apps’ which will deeply integrate into the service cloud, and will also take up an increasing share of the user journey: – the idle screen app: idle screen apps are being productised by handset OEMs (see Nokia’s S60 and S40 latest Home screen product) and consolidate an ever increasing amount of local device info (e.g. contacts) as well as service alerts, status messages and advertising inventory. – the Phonebook 2.0 app; the addressbook will evolve into offering a people-centric view of the world, with Facebook, MSN, MySpace, Twitter, etc connectivity, but also contact-centric actions (select contact, then click to SMS, call, locate,invite, etc) – see for example Voxmobile’s pioneering work in this field. – the Calendar 2.0 app; the calendar should evolve into offering a timeline view of your schedule, as well as a history of photos, texts, emails sent (ala Nokia Lifeblog), probably combined with events happening in your area, notices of which contacts happen to be in the same city (via Dopplr or Tripit), weather updates, etc. – the Location 2.0 app;. currently location apps are map-based, in other words they offer a 2D map-view of the world around you, with related attractions or utlities which are nearby. We can argue that the location apps of the future will have maps as just one of the many views; event-based views are another interesting concept, which would show you what’s happening around you, alert you to promotions, who’s nearby etc.
Ultimately, tomorrow’s mobile applications will offer zillions of alternative mashups of information in the device, network and web; but I would argue that the phonebook, calendar and location apps will form long arcs or cardinal points within the user journey, simply because this is how we humans are used to conceptualise the physical world; by the people, time and space around us.
Comments welcome as always.
– Andreas twitter: @andreascon