Tag: UI

How Apple Got it All Wrong

Sluggishly reacting applications, latency in almost everything you do, crashes, blank screens, long lag to pick up networks, buggy settings. Do you remember any of this? Sounds like some old-fashioned feature phone that was somewhat overloaded by its ambitious maker, doesn’t it? But, alas, no, it is not. This is the user experience with a one-year-old iPhone 3G, 16GB since 24 June 2010. Do you recognise the date? Then luck will have it that you have experienced the same: the grandly titled “iOS4” update that was being pushed down your throat (or rather iTunes) to your iPhone 3G.

Apple has been hailed for poking everyone else making handsets in the eye when it came out with the iPhone: here is a newbie that got it all right and venerable industry leaders found themselves with cartons full of ostrich egg on their faces: here was someone who got it all right: combining great build quality, maybe only OK-ish specs and unsurpassed UI with a vertically integrated publishing and distribution system that made for a leap in usage of mobile devices. It was a bad slap for the Nokias etc of this world and a revelation for millions of users (even if they were not Apple fanboys).

Software and hardware need to blend well

And then it came back to bite them! I am not a techie but iOS4 on the iPhone 3G feels like someone put a little too much luggage onto too frail a porter: the things creaks and aches at every corner. Gone are the days where one could switch from one app to another in seconds, where the iPhone – in good Apple style – did what you wanted it to do without much ado but breathtaking efficiency and speed. Now, it is clunky and, well, very old-fashioned. It could of course all have been avoided: just don’t push iOS4 to the iPhone 3G (or older models). No one would have cried, you should think: if the hardware cannot handle it, it cannot handle it. Users understand such things one should think. Keep iOS4 to the iPhone 4 (even the numbers match, doh!).

Allowing iOS4 to be pushed to the iPhone 3G was one horrendous mistake!

So is this the latest marketing trick of Apple? Go and spend another £600 to buy a new one, you say? This would be utter and incredible cynicism on a scale that would put Apple right on top of the current bad-boy scale! After all, I am not talking about an old, well-worn something-or-other device; I am talking about something that was only a year ago (which is short in terms of device replacement even in the mobile space) for a considerable amount of money!

However, I think that is not it. My suspicion is rather more frightening. It very much feels like Apple starting to overextend itself and learn how complex and fragile it is to deal in the mobile space. Pushing iOS4 to devices that obviously (not only under some special and hard to find circumstances) cannot cope with it is just shoddy. Every game or app developer in the market for more than 2 years would have caught this in QA. Does Apple not have QA? Or not anymore? Or at least not enough? It might happen to you when you try too much too quickly. Apple’s passion (or paranoia?) that drives it to try and do everything itself appears to haunt it now: I mean, QA is really simple. You don’t need cohorts of phDs in elementary physics to do this. It doesn’t take you 3 years to build it up. And – last but not least – Apple appeared to being very much on top of this in the past. So what happened?

A great showcase on the importance of User Experience

I have been throwing this into the faces of Nokia lovers who never fail to point out how technically superior Nokia’s hardware is: users do not give a toss about hardware specs. They care for the overall user experience. The unhappy marriage of the 3G with iOS4 shows what this does when it goes wrong: all the fun of using an iPhone is gone. What good is it when my phone lets me down every 10 minutes? What fun if my e-mail doesn’t open for 20 seconds? How exciting if applications appear to be frozen only to open just seconds after I pressed the home button (that will kill them just in time after I saw that it did, at the end, react)? Utter frustration. Rotten user experience. Complete fail.

Apple shows us, hence, accidentally how important the overall user experience is, and this may well be my final example on this: a simple (well, maybe not so simple) piece of software turns the most coveted consumer device of the day into a somewhat lame brick! However, it also shows how incredibly important it is to match the hardware (and network environment) to what the overall product (here: iOS4) promises to deliver (non-Apple case in hand would be video-calling on the Nokia N70 back in 2005: there was just no way this would work in practice; the experience was just too horrendous).

So, dear Apple, back to the drawing board. And if I may make a humble suggestion: just push the last pre-iOS4 version back to the older devices tomorrow! First thing! Promise! Please!

To all the others: this is a great opportunity! Catch up! Double your efforts! But don’t forget that the coolest frigging hardware (12 MP cameras anyone) is useless if the UX is not matching it either!

Web v Mobile Web v Apps. Or Not?

Back in summer last year (when there was a whole lot less rain), I looked at comparing the mobile web to mobile apps. There is quite a discussion raging on which it will be. The Church of Jobs raving on about their uncountable number of app downloads on the one hand, and the brave warriors of ubiquity on a technical level on the other.

Asking the right Questions

I would posit that there are three distinct issues to be discussed:

1.    What is the web?

2.    What is the mobile web and is it distinct to the web?

3.    What about the content and its context (irrespective of platform)?

Every attempt to an answer should really start from the point of the user (who, I am aware of that, more and more becomes a creator at the same time) because, without them, there is not much of a (commercial) point to it.

Now, distinct to what old lore may have, users do not tend to care for technology much. They care for what technology allows them to do (or not to do). I therefore think the first question to be asked is: can the web do things better than an app (or, indeed, vice versa)? When you then start looking at what is being done (and what users may want to do if and when technology allows them to in a convenient and accessible way), you will come to a couple of easy conclusions.

The web in itself is just one huge content repository,

… which is – currently – being accessed predominantly by browsers. Some questions on this:

  • Has this always be that way? No. Pre-web, there were libraries with clever people in them that could help you find what you needed. With enough time, you would eventually get close(r) to the truth.
  • Does this always have to be that way? No. Text input via keyboards is not an “intuitive” way of communicating (the old folks here may remember the finger that hovered like a hawk above the keys of an Olympia). May touch control be a game changer? Later more on this…

Prior to Google, people search through catalogues, and they thought that this was an awesome improvement over having to run to libraries and stuff in order to find things. Along come the Google fairies that deliver the same more easily and quickly, and everyone now feels that catalogues are a little quirky and very old-fashioned indeed.

This is to illustrate that the packaging and connection into discovery mechanisms are more important to the usability of the content than its actual delivery. Ease of access matters as, otherwise, there is, well, none.

The mobile web is the web, the web and nothing but the web.

It only so happens it is being accessed from a device with a smaller form factor (that is, until H&M starts shipping those iPad anoraks with monstrously big pockets next autumn). Increasingly, browsers available for mobile devices render web content originally formatted (not created!) for larger devices for the smaller screens. This does not, however, mean that they are the best way to deliver content to a small device.

One big thing speaking in favour of a unified web platform (including on mobile devices) to deploy content is, of course, volume and unit costs: all other things equal, the cost of deploying via a unified web platform is significantly lower than on others (no need to build custom solutions for every man and his dog and unit costs drop to virtually zero very quickly. This is arguably the key argument in favour of the web but I would suggest that it will only work if you can deliver at least as well as other routes of deploying that content offer to.

The usefulness of content is, per se, independent from the device.

In other words, device constraints have, per se, nothing to do with content being accessed, used, consumed, processed. By way of example, who would have thought that people would read a book on the go in the early 90s? Doesn’t seem to be a big thing anymore today, does it? And why not? Because we got used to solutions that make this convenient.

It is a question of packaging and approach that will determine how well (or poorly) access and usage of content on any device works. If you call it an app or a widget or whatever else does not matter. Most people just do not care. They look at how easy it is to retrieve the latest weather forecast. If an app does that more quickly and comfortably, they’ll use that. If a widget does the same thing, they’ll choose what they like more. And if you can deliver the same thing as easily, as comfortably, as quickly and as discoverable on the web, they might just do that.

Not everything is delivered best on the web

Now, the web is big, it is very big indeed but it is unlikely – despite of what Apple tells us – that there will be an app for every web page. Then again, does there need to be? No. Why not? Because not every web page will be accessed from mobile devices or, rather, will not need to be accessed from mobile devices in numbers large enough to be of commercial relevance.

Hah, I hear you say, he is taking a short cut here: the above implies that, if there is a need to access content from a web page, an app is the better solution. And, yes, you are right. But I will come to this later.

Sometimes, the web does not even work well through a browser. Google Earth is one of these: it is a desktop application because of functionality constraints over the web. It is connected, mind you.

Not everything is best delivered through an app

The equation works around the other way, too. There are things I will normally access through a browser, simply because it would be too onerous to have a single app for all web pages I access. Moreover, there are indeed web pages (this blog included) that use nifty code (don’t ask me; it’s run through WP plug-ins) to render content in a more useful way for smaller devices. Would you care much for a “Volker on Mobile app”? Probably not. Because I only update this blog a couple of times a week, and it probably does not generate enough value-add to merit the (presumably) superior functionality you could deliver with an app.

Some things don’t work on Mobile, or do they?

Did you ever use Google Earth via its iPhone app? If not, let me tell you that is a pretty poor experience compared to the wow-feeling all of us will have felt the first time we played around with it on their desktop app. Why? Because it just doesn’t translate properly. Imagine watching Independence Day on the iPod Touch: you’d get cute little spaceships but not really the awe-inspiring size Emmerich had in mind when shooting it.

Both of these lack of one thing mobile can never deliver, namely the big screen. They are, in their current packaging, unsuitable. This may not however apply to subsets of the content and/or information embedded in them. Google Earth may provide useful data that, if re-packaged, delivers a powerful and good user experience on a mobile device, too.

Functionality and Usability are King and Queen

Almost all considerations result from and in questions of functionality and usability. On devices with larger form factors and constant high-bandwidth connections, a lot of rich content can be appropriately delivered via a web browser. The same cannot (yet) be said of mobile devices. Even with 3G, performance of rich media can often be shoddy. Poor user experience = frustration = low or no usage.

With 4G on its way, this may change considerably. With down-speeds North of 10 Mbps to your mobile device, there is a lot of rich content that you can get to your device in no time (or, rather, real time). That would be functionality solved then.

In the short and medium term, I see, however, two other constraints, and these are a) usability from a device perspective and b) usability from a user perspective.

Currently, a device running constantly on a high-speed data connection sucks battery life. With an iPhone already running on something like 30 minutes when in full use (OK, I exaggerate, and, yes, I do know that Nokias do better – but then, they are not as usable [anymore]), this is a non-starter. People will not do it. Once this is solved (and this is a question of when, not of if), this goes away, and that will be a huge constraint removed.

The other obstacle is usability from a user perspective. What does an app actually do? It pre-packages content. And because it (or some of it) is already in there, you don’t have to download it again. It also allows you to build in specific input mechanisms that optimise use for the mobile device (and how this impacts uptake, the iPhone has shown!).

Touch as a game changer?

Touch control is very much on the fore. And it makes perfect sense: that stylus just seems to dangle on the end of one (OK, normally two) of your limbs, it’s always on, it’s always with you (quite literally at arm’s reach) and you learn how to control it from pretty early on in life. Heck, it’s even been used to get us onto this earth in the first place (or so some people believe).

Touch control then also does away with a few constraints in particular on mobile screens (where mouse control, touchpads, etc are not normally readily available nor as useful as they are on a desktop). So once HTML5 is widely deployed (which – I am told – makes the UI life within web pages a whole lot easier), the usability thing might just go the way of the mobile web.

Touch control (and other nifty things; check here for another Apple patent on finger-based input using the camera) then propels the usability forward (or back? the first maps were arguably drawn with fingers in the sand…), and this will be quite helpful – in particular also on the smaller device.

Until then, build apps that incorporate controls that make the user’s life easy (or at least easier). If you call them apps, widgets or whatever else you can come up with, doesn’t really matter…

So, Google: App Store or Web? Or Both?

Last week, there was the Mobilebeat conference on, and – amongst many other things – a lot of guys felt they had to air their opinions on the future of mobile apps or, errh, no apps. They spoke so elaborately about it that even the revered FT (albeit in its blog section) and the BBC felt compelled to run stories. Amongst others, the CEO of “indie” app store Get Jar and Google’s wonderful Vic Gundotra, VP Engineering and also equipped with this most valleyed of all Silicon Valley job titles, i.e. “Evangelist” (I would really like one like this, too!), in his case for developers spoke about where they saw information and entertainment on mobile phones going in the future and how the ecosystem would look like.

Now, let’s get serious.

What was Said?

First, GetJar‘s CEO sees the market for mobile applications becoming – get this – as big as the Internet (woah!). He then said also that it would peak at about 10m apps (in total?) by 2020. Hmm. GetJar then went on to warn that the number of developers would drop “drastically” and that only about 10% would be able to survive. The others would take their skills elsewhere. So where then? To the web? (This is of course interesting also because GetJar will deliver Sony Ericsson’s App Store…).

It is here where Google comes in. Gundotra said that, according to Google (and who would question them), the web had won. Even (!) Google was struggling with the device fragmentation in mobile and many, many applications could be delivered through “incredibly powerful” browsers as well. He even borrowed Steve Jobs for his argument, pointing out that the Apple CEO had announced that the iPhone was “Built for the Web” upon its launch.

There were others who contributed: Nokia’s Head of Services reminded everyone that Nokia was there to help with its Qt (Cutie, geddit?) cross-platform application network . The Symbian Foundation’s Executive Director, Lee Williams queried the need for more app stores and called, instead, for more than “just a bucket of apps”, which should look like an aisle with the very stuff that specific consumer is interested in and which (s)he could wander down at leisure.

They all however concluded that it [scil. the mobile web] was not there yet. Hm again… Let’s try to disentangle this all:

The Needle in the Haystack

Upon the launch of the app store and the wondrous stories of the iShoot developer Ethan Nicholas who coded in his bedroom after work only to resign from his day job weeks later because he made more money than he had ever thought. A lot of developers read that and, since it is the wet dream of every games developer (earn cash with an honest game without the “suits” fiddling with your game in between; anyone remember Copeland’s skateboarding turtle?), embarked on the journey themselves. And then they found, oops, it does not work that way? Why not? Well, because there are more than 400 applications going live every day. And with the sheer number of them, it could well be that the best app ever written is already out there but buried deep a couple of categories down in the app store.

This is no big surprise. It is how it works in any sector: one smart kid is not enough, you also need the environment and a lot of other building blocks to have a winner (as reigning F1 World Champion Lewis Hamilton is painfully realizing this year).

In the app store’s (and a gazillion other) case, this means that you have to make sure that you gain some attention. From Apple (or any other app store operator), from the press, from the users out there. And this is not news. There have been very well written pieces about this galore (see here for just one of them).

So will this mean the fall of a lot of the developers that went about their business thinking the app store magic would do away with centuries of business logic (there is a reason why companies have sales & marketing departments, you know…)? Yes, very probably. But does that mean the app model is flawed? No.

The Hit Dilemma

One of the Mobilebeat participants, namely Playfish, creators of some of the most successful Facebook games who released on the iPhone, too, complained about the hit-driven nature of games on the App Store. Whilst I am painfully aware of this dilemma, one has – again – to point out that this is pretty much how most of the economy works, too, unless, that is, one builds a superior and dominant brand (Tetris would be the example for the games world).

Other industries know this, too. Everyone knows IBM is a leading computer maker. Hardly anyone remembers that the Dutch electronics giant Philips used to be one of the biggest players in that market (not even Wikipedia mentions this); their CeBIT booth was bigger than IBM’s throughout the 70’s and early 80’s (my dad worked for Philips then; I need to dig out some pictures). What happened? Hey, they missed some crucial disruptive innovations and they were history…

What I want to say is that no one is immune to the demand for constant innovation and improvement (otherwise some Firefox will sneak around the corner and steal market share). The reason why this hit dilemma is more painful in mobile games than elsewhere is the relatively small size of the market to date: it is more difficult to build reserves than in other, more established sectors.

How Many App Stores? Mee too, me three, me four, …

With Apple’s roaring success with the app store, the whole industry stampeded to put out their own, and they have been moderately successful or failed. But it is early days! Why did they fail? Because they equally had hoped that one thing and one thing only (just name your bucket of apps an “app store”) would heal the painful failure of the sector in converting otherwise gladly paying users to also using, consuming, contributing to entertainment and information on their mobiles. Now, this overlooked that Apple’s model did not only consist of a storefront. It also consisted of a fairly simple developer programme (with a click-through agreement), a fair(er) revenue share to the developers and unprecedented ease of use in getting to the app of one’s choice. Try and apply this to, say, the launch of Nokia’s Ovi Store

So do users need more than one store? No, not in general. If you can get all you ever need, want or desire from one destination, you don’t need another one. This however becomes a little precarious with a view to monopolizing channels. You would never know if there are not some that are a little more equal than you… So, having Firefox, Chrome, Opera, etc. next to Internet Explorer did the world a ton of good. And having Nokia, Sony Ericsson, the carriers working on alternatives to Apple’s app store is arguably of equal value. Will the user care? It depends on the execution: Google’s superior search algorithms made the old-style catalogue model previously found in search engines superfluous; why do I need to sort something if I have a little fairy that races to get me what I want in no time? So: if I have a bucket that comes with a little fairy, I don’t need long, long supermarket aisles. I’d rather get it home-delivered by the search fairies.

It’s the Usability, stupid!

Now to the key question: separate apps or web? Now in Google’s case, their pleading is somewhat obvious: well, they would, wouldn’t they?

Google, on the other hand, has apps out on most platforms for most of their web services: Be it Gmail (great Blackberry app!), Maps, or – all in one – their iPhone Google app, it comes as an app. And why?

Because it would otherwise be unusable! OK, let me rephrase that: the delivery of browser-based applications through mobile phones suffers some very severe setbacks today, amongst which usability on a small screen, constant connectivity and bandwidth. Whilst the latter two are arguably solvable some time soon, the former is a little trickier: when delivering to a mobile device, you not only have to download all underlying data (graphical assets, etc) but also an interface that works on that device. And because of the small form factor of mobile phones (even in the case of large-screen touchscreen phones like the iPhone), this is likely that your user experience will be significantly worse than on a large screen equipped with mouse, touchpad, etc. Apps can bridge this usability gap, and I would argue that this is precisely why Google is producing them. The underlying content can often (not always) well be delivered from the cloud but the UI of small devices is crucial to their sensibility.

With both (mobile) browser technology and handsets improving, the space available for services that can sensibly (and with superior costs) be delivered from the cloud (i.e. through the web) will increase, and steeply. However, there will always be applications that will either be impossible to deliver via the web (name a high-end 3D racing game on the web) or where a specific mobile UI would greatly improve the usability of any service.

It is another question if these will be delivered via flexible widgets or larger, more comprehensive apps (functionally, a lot of apps effectively are covert widgets); this will simply be (and remain) a question on the complexity of any given task and the ease and superior (or not) delivery an app would provide over a browser-based service. There will be an equilibrium between the two but I posit that there will remain large areas where browser-based delivery will not be able to compete with specific applications (that will draw on data from the cloud as well). Incidentally, 58% of Wired readers agree with me (and another 17% don’t care; check the bottom of the article) 😉

This can be seen on the (“normal”) web, too: Google Docs (Google’s online suite of office applications) is, despite a lot of effort and being free to use, an utter underdog to MS Office or Open Office (the only numbers I could find give Google Docs a market share of between 1% and 5%). It is, I think, because downloadable office “apps” are so much more usable (and react instantaneously irrespective of my ISP’s moods) than online services. The complexity of the computing (and – more importantly – the bandwidth necessary to deliver it) is just too overwhelming (see here for a previous post on this).

More evolved mobile apps often are (and/or will be) a hybrid: they offer a front-end that optimizes the data drawn from an online environment for use on a specific mobile device. It will not be an “either/or” but an “and”. Anything else would anyway be so last century!

In Conclusio:

Whenever possible, services will move online because it is cheaper to produce. Whenever necessary, they will be delivered through dedicated apps because it is required to use them!

Handset Choice: Ease of Use Rules!

A lot of iPhones later, the industry now also has it black on white: Ease of use is the primary reason influencing the choice of a handset for users. Or so we are being told. It is not that surprising, is it? Here’s the top answers users gave on what they look at when buying a new phone. It is taken from 1,500 interviews that were conducted for Nuance, a top sponsor of MEX (which is, you guessed it, a conference on Mobile User Experience).

So any vested interests aside, here’s the top results:
  1. Ease of use (69.0%)
  2. Screen Size (61.4%)
  3. Coolness Factor (61.1%)
  4. Camera (60.8%)
  5. Range of Accessories (58.4%)
  6. Keyboard (58.1%)
  7. Battery Life (56.6%)
  8. Music Playback (50.9%)

Powered by WordPress & Theme by Anders Norén