Category Archives: interfaces

The 1″ Gap

Smartphones are phones – devices for one-handed use on the move. They are also devices for consuming information. The restrictions on size by the former, and the requirements for screen real estate by the latter leave a gap between two ideal sizes – and mean that there is currently no device that spans the entire range of uses.

When looking at today’s super-sized touchscreen slabs, one-handed use doesn’t seem to have been a consideration in their design.
This is puzzling in a way. Be it taking a call, hammering out a quick answer to a text, changing a track or checking a map – I want none of these core activities to be restricted to situations where I have both hands free. A mobile should be that – able to integrate seamlessly into mobile use, without the need to pause and put down things before operating it. This, of course, puts restrictions on the size of the handset – which, after all, is mainly determined by the screen size. Anything up to 3.7″ is comfortable for me personally, up to 4″ doable, while something like the 4.3″ of the SGS II is already a stretch. With screen sizes beyond that it’s no longer possible to reach every part of the screen with the thumb. They require two-handed operation. The modern superphone, at 4.7″, is already firmly in that territory of two-handed operation.

But then there are good reasons why screen sizes have grown so much. Browsing the web, watching video, reading books, playing games – most modern uses of our smartphones benefit immensely from more screen real estate.
Small screens limit the amount of information that can be displayed. Even with high resolution displays, they are only a small window on the information space, a frame into which things have to be crammed. It’s not possible to read desktop websites without problems, video remains an at-a-distance experience, and they can’t really replace an eBook reader.
Large screens fix this problem – but not really at the 4.7″ of the modern superphone. Sure, things get better at this size, but the crampedness doesn’t really disappear. They are just a halfway solution. To make the crampedness disappear, we need to add another bit of screen size. My guess would be another .3″ at least. At another .6″, i.e. a 5.3″ diagonal, at the latest, the frame no longer dominates the content. EBooks are a joy, movies acceptable, and the vast majority of desktop websites work without a problem. And while one-handed operation is no longer possible, every adult should be able to comfortably and securely hold  a phone with some screen size between 5″ and 5.6″ in one hand.

So, for the time being, there is a 1″ split between mobile phones that really fit the name by allowing one-handed operation, and mobile handheld devices that allow fully mobile, unrestricted information consumption. The current form factor of 4.7″ superphones trades in the former without really achieving the latter.
I say for the time being since I still hope for the flexible screens and other new display technologies that have been promised to us for seemingly ever. Given these, there is a chance for a device that adjusts for either use without compromise. I’m waiting for a future compact mobile that has a screen that unfolds or unrolls to a larger size when needed. Until then, I guess I’ll be using and carrying two devices.


Leave a comment

Filed under interfaces, mobile

Locked into a feature

As I’ve previously said here, it’s often the smaller features that make or break a device for me. The lock mechanism is of these. Since the unlock/action brackets every other interaction with my phone, it’s something that needs to be done right.

The slider on the N8 is exactly the kind of control I want there. It enables me to lock/unlock my phone with a single action. It’s located almost directly under a finger when I hold the phone – so it doesn’t require much movement or effort. Because it is a mechanical slider with some resistance, it doesn’t get triggered accidentally. Operating it gives the kind of nice, haptic feedback that modern phones (especially touch slates) usually lack.

Both the Android and the iOS mechanisms of a button press followed by a slide across an on-screen element are clunky by comparison. Two different actions, two different fingers, two different locations on the phone. They require twice the effort and have twice the complexity. For now, the simplicity of unlocking my N8 is one of the reasons that I’m still locked into Symbian.

Leave a comment

Filed under interfaces, mobile, tech usage

AMOLED for the time

In a lot of ways it’s a toss-up between AMOLED screens and LCDs. The deep blacks on AMOLED screens are wonderful, but the oversaturated colors are not everybody’s cup of tea, as is the fact that less protective layers are needed, and the interface appears as printed on the surface of the device. The sunlight legibility beats most regular LCD screens, but is in turn eclipsed by transflective LCDs. Energy consumption is lower than for LCDs when lots of black and dark colors are used, but when browsing the web with mostly white web pages this advantage is lost. In these respects, AMOLED is a question of usage scenarios, and, more importantly, taste.

The reason I’m firmly in the AMOLED camp is a single feature that Nokia have implemented on their phones with AMOLED screens, and which can’t possibly be replicated on a LCD screen: the lock-screen clock. It takes very few dots to make our pattern recognition kick in and see shapes – in this case a display of the current time. With AMOLED pixels are lit individually, so these  very few dots consume very little energy. With a LCD, where the screen is backlit as a whole, this display of the time would necessitate the screen being permanently on – and kill the battery in no time.

Not having to press a button on the phone to see the time might seem like a small thing, and it is, when taken as a single action. Summed up across a day, a week, a device lifetime of use, it adds up to a substantial advantage. But it’s not just saving a few thousand taps on a button – it changes the nature of the time telling. Not requiring any interaction is a fundamental difference from requiring even the simplest one. It is no longer just a device that can tell you time when you request this information. The fact that all you need to look,  that the time is right there for you to see makes the phone into a real replacement for a watch and a clock.

Leave a comment

Filed under interfaces, mobile, tech usage

The Symbian Myth

Nokia’s in a free fall with smartphones at the moment. Having held on to the market leadership in volumes, with a slow and steady decline, for years, they may now actually have been overtaken by Apple in their market share, just as they were overtaken in both profit and sales revenue share by them before.

Now success in mobile is a multi-faceted thing. It’s not simply about having a better product, or better sourcing, or better advertising, or better sales channels. Why Nokia is failing is not a simple story, and a lot has been written about it. There are articles about when Symbian was killed, whether Steven Elop is a Trojan horse for Microsoft, whether MeeGo would have been ready before it was killed, the timing of the Microsoft/Nokia announcement, and all other kinds of aspects.

Through all this the question of whether Symbian would have still been a viable OS for Nokia going forward is usually a pure fanboy topic.  There’s little between “Symbian sucks” and “Symbian was and is the best mobile OS”, and actual arguments are scarce. Being a Symbian user, and having some experience with both Android and iOS devices to compare the Symbian experience to, I’d like to contribute to a more balanced and detailed picture here.

The question was posed here has two parts: There is the state of Symbian itself, and then there’s the state of Symbian development within Nokia.

The State of Symbian

When talking about the state of Symbian, not even the strongest proponents of Symbian argue that there aren’t at least some problems. The usual arguments here go along the lines of features and technical capabilities vs. interface, with the Symbian diehards maintaining that it is only with the later that there are any problems.

Admittedly, on a pure feature list comparison, Symbian may still be the leader. So let’s take it as a given that you can do more with your Symbian handset than you can do with one of competitors. Let’s also take as a given that Symbian handsets can have better battery life than those on other OSes. There is at least some truth to both. These are not the points I want to argue, because these are not the points that matter much out in the marketplace at the moment.

_Effective_ feature parity

The vast majority of users have a very limited base of knowledge when making a buying decision. Feature lists in consumer magazines and stores are very short. All the major current OSes have feature parity – as seen on these lists. Symbian hasn’t managed to get anything on there to differentiate itself. (USB on the go is not something on there, because it’s too unknown to be explained in two words. Ovi Maps is not a feature of Symbian itself – but Nokia should have marketed the hell out of it.) Battery life, while important in everyday life, is just one point on a checklist, and not something you experience when trying out a handset in a store – or trying a friend’s device.

Interface pain

What  sticks in these situations is the interface.  Now the Symbian interface certainly has come a long way since the release of Nokia’s first (mass-market) touch screen phone, the 5800 XM, and that itself improved vastly from the catastrophic launch state. Personally, I like a lot about the interface as it is. I’m not a fan of bling, and will take efficient over pretty transitions every time.

For example, once configured, the home screens are efficient and work for me. The ‘once configured’ is a big ‘but’ here, though. When my N8 forgot the entire homescreen configuration after a crash, I had to keep from screaming (no exaggeration here). Configuring the shortcuts widgets is a process from one of the deeper circles of usability hell. The choices made in designing this really do defy belief. Let’s take a closer look:

The UX hell of changing a homescreen shortcut

You can only have shortcuts widgets containing exactly four shortcuts – no more, no less. There are no single shortcuts. To change one of these four shortcuts on a widget you first need to enter the configuration mode for the homescreen (long tap anywhere, or via the context menu). Then you need to enter the configuration mode for the widget (tap, select option from pop-up context menu). This then switches to a different screen which gives you a list of the positions and the currently assigned shortcuts – in writing, without using the icons you just saw. You then select the one position to change by a tap. This brings up a question about the type of shortcut you want to replace the current one with: to an application, or a bookmark. Choosing an application brings up a scrollable list of installed applications. This list uses about a third of the screen, and so displays only five entries in a small font. Additionally, it only displays application names, no icons. You scroll through this list (painful because of the small size) and select an application by tapping on a radio button next to it. Then you choose back (no ‘ok’ or ‘save’!) to exit the configuration screen. Now all you have to do is tap ‘done’ on the homescreen configuration screen – and you’re done.

This is insane, pure and simple. That was nine steps to change a shortcut – across three different screens, none of which after the first one use the icons for the applications, which to me are their main identifiers. The first time I went through the process I didn’t believe it. This was clearly coded by an engineer – and not even using standard parts, since that ridiculous small application picker menu doesn’t appear anywhere else in the system, and doesn’t look like anything else in there. I believe even the font size on this menu is not used anywhere else. The engineer may be excused since he was assigned a task he obviously wasn’t qualified for, but the manager ultimately responsible for allowing this deserves to lose his job. It may be argued that this is not a very common thing to do in everyday use, and thus doesn’t matter too much to me now, but I can absolutely see a new user return the phone after first encountering this. After all, it is one of the first things you do with the phone.

There are other disastrous design decisions. Menus for configuration are still the same as they’ve been for years, nested three- and four hierarchical layers deep. I often need to go on a search expedition to find particular points that I know are there, and I’ve capitulated in respect to the SIP client that’s supposed to be in there and working. Using a third-party app is just less painful.

Just plain broken

This is the design issues part  – and as said before, Symbian fans do admit that there are some problems there. There are, however, a lot of parts of both the interface and the underlying system that are not misdesigned but plain broken. Examples?

The taps on the home screen that get registered (i.e. the icon changes to indicate this) but don’t have any effect. The application menu that gets massively slower to first display the more applications are installed (did somebody, a long time ago, try to save memory there by not caching the application icons?). The screen timeout, which does not work (it’s only the auto lock that turns off the screen, before that there’s just a dimming that somewhat imitates the behavior of an LCD screen with the backlight turned off).

Setting a browser other than the default one gets ignored even by some of Nokia’s own applications. The browser itself – which by now is so old that it has to be considered broken by today’s standards. The ‘back’ button in the email app which exits the app when you’re in a subfolder instead of returning you to the folder overview menu.

Payment and installation via the Ovi store – which, for me, has a failure rate of about 25%. The Qt smart installer which for a while crashed the phone each time during the installation of a new Qt app, and then needed manual removing before allowing any new installations at all. Nokia Social, which often takes a few attempts to start, and then often presents me with a black screen.

The network stack: some applications always ask for permission to connect, others connect via packet data when wi-fi is available. The stack even allows simultaneous wi-fi and packet data connections! Sometimes, for some applications, the connection process is not even triggered at all – but this doesn’t get communicated to me as an error. I once wondered for a couple of days what was happening since email and Opera Mini were still connecting, but the internal web browser always failed. I had to switch to manual approval of connections for that to get things going again. At this point most users would have either given up or contacted support. Accessing links from Nokia Social while on 3G? I’ve given up – I don’t see any pattern to the few times it actually works. Oh, and the fact that there is a single font that Symbian^3 uses for all font rendering, including web pages? I’ve never heard this mentioned by anybody in the Symbian world, but it is bizarre for a smartphone in 2011.

Two steps forward…

Other things are even more bizarre: Symbian^3 actually has less features in many respects than the previous versions. No more auto-redialing. No user-adjustable EQs in the music player. No podcasting – at all. No converter app, or stopwatch.

Some of these things may be cosmetic. Some may indicate shoddy development and quality control. Others seem to indicate some things are really fucked up under the hood. Taken together, they lead to pain on a daily basis when using a Symbian^3 handset. No, it’s not all pain, and there are a lot of good things about Symbian^3, but the level of bad design, confusion and frustration is simply unacceptably high.

S60 the edition – the skeleton in the closet

And I’m only talking about Symbian^3. What is often forgotten is that Symbian^1/S60 5ht edition is still what runs on all the low-end Nokia smartphones – which should have been at least a significant part of the 150 million Symbian handsets that Nokia still wanted to sell. And Symbian^1 with resistive touch screen on a 3 year old hardware platform vs. the current crop of low-end Android phones? No competition to the average user, not at any prices where Nokia could still make a profit.

Developers: There’s no pain like Symbian

Since today users are not the only people whose interests are important, let’s take a quick look at the other big group: developers. I’m not one myself, so I’ll have to go by what I heard. A friend described the experience of developing for Symbian as the most perverse, painful thing he’d done in over 25 years of programming. The sentiment has been echoed by others. Well, this was supposed to change with Qt. Which is currently in some transitions under the hood. Where the toolkit still doesn’t support kinetic scrolling. Or have a standard widget and icon library, apparently. So no, despite significant improvements, the average developer will still choose iOS or Android over Symbian without a second thought. Now in theory the strategy of taking the pain away from developing by establishing Qt for development, and then easing the transition to MeeGo because these Qt applications would run on that as well (with small changes for anything non-trivial, but still) was brilliant. The best in the industry, as a matter of fact. But then there’s nothing theoretical about the handset business. And the market doesn’t forgive delays in execution.

Symbian in the State of Nokia

That brings us to the second question: would Nokia have been able to fix the problems with Symbian? My consumer view is shaped by the fact that the promised update for my N8, the mystical PR 2.0, the one with the real goodies like then new browser, a portrait QWERTY keyboard, and some real fixes for the current problems, is already between 5 and 7 months late – depending which non-announcement from Nokia you believed. The only thing they’ve managed so far is a change of name – it’s now called “Anna”, but still projected for “the next few months”. There are some puzzlers here as well. That the portrait QWERTY keyboard everybody in the blogosphere demanded has not been delivered yet independently of “Anna” speaks of gross mismanagement regarding development priorities. This particular point can’t be a technical problem with Symbian – and plenty of third-party developers have implemented such keyboards in their own applications, so it can’t be a matter of resources either. Or perhaps the update process itself is broken, and there are bizarre, deep interdependencies that don’t allow such changes on their own?

Regarding the resources for Symbian development at Nokia: There are blog posts out there from former Nokia employees who tell of entire new UIs and frameworks for various things being scrapped, of double- and triple developments, of reverse engineering UI patterns from the already written source code (!). There are references to fractions inside Nokia that effectively sabotaged, and sometimes entirely ignored, instructions from the CEO and higher-ups. How much of this is true matters little.

In the end there is a simple truth regarding Nokia and Symbian:
Nokia had years to fix Symbian. Whether you count from the time the iPhone was released and upped the game regarding UIs, or from the release of the 5800 where the public reception must have told them there were some very big problems, its years either way.  They had 6500 engineers working on it. If you think that is an incredible number of people – it is. There’s nothing like it in scale in the entire handset industry. With all this time, and all these resources, we got Symbian^3. An update to Symbian that was delayed, and then delayed again. An update that improved things, but not by enough. We got promises of delivering upgrades and fixes quickly. This simply hasn’t happened. Nokia has proven that it isn’t able to deliver software of necessary quality, and to deliver it on time. It has been proving it for at least the past two years. Whether this is the result of gross mismanagement, the result of an OS that is no longer maintainable, or, most likely, a mixture of both is an academic question. Changing any of the reasons to enable it to catch up with the market would have required time. A lot of time. In today’s market, this is not something that any handset maker has.

The Symbian myth: Symbian as a viable OS at Nokia

So I think it is a myth that Symbian, at Nokia, was still a viable OS in today’s market. It is a myth that, without Steven Elop, Nokia could have found a way to soldier on with Symbian, and maintain its market share. Nokia would not be at 30%+ market share with Symbian at the moment, no matter what. Symbian handsets would not be considered market leaders by anyone. Not in this universe, not with where Symbian stood at the end of 2010, and not with the track record that Nokia has at this point in time regarding software development. This truth was a slow and painful realization for me. Things seemed OK for most of 2010, and it seemed like Nokia had a chance to turn Symbian around. They missed it. I am deeply saddened by this, but it’s no use pretending the situation was any different.



Filed under interfaces, mobile

10/30/90 seconds – and you app is gone

I try out quite a lot of apps on my mobile devices. Most of them get deinstalled again immediately. Some rules of thumb have emerged for my personal expectations when I first start up an app. So here’s for all the mobile developers out there:

Your app has 10 seconds to start up and get to where it’s working, then 30 seconds to give me a feel for how to handle it, and finally another 90 seconds to give me a first feeling of achievement.

Failure at any one of these stages means I’ll just close and uninstall it. No second chances given. Continue reading

Leave a comment

Filed under interfaces, mobile, tech usage

Records, CDs & Love

I once fell in love with a girl because of her record collection. Those of her records and CDs that I knew were all great. The ones I didn’t know were either ones where reviews or references had made me interested, or had really great covers (which, for a brief time in the mid 90ies, was strongly correlated with the quality of the music). Leafing through the collection was an experience of surprise, amazement, intrigue and delight. Continue reading

Leave a comment

Filed under digital media, interfaces, tech usage

Holding up the proceedings with idiocy – 1: Windows copy

Found this morning that an overnight copy job to an online disk had stopped after 5% execution with a message asking whether to overwrite a file at the destination.

A perfect case of holding up the proceedings with idiocy. There is no reason why this dialogue has to be modal. Throw up a dialogue, sure, but allow me to deal with the problem at my convenience – which includes at the end of the copy job, after everything else has been copied.

Leave a comment

Filed under interfaces