Did an interesting comparison yesterday:
- my SonyEricsson K800i, bought a year ago from O2 via Carphone Warehouse, which has minimal customisation vs. the 'vanilla' device - an O2 menu & link through to its portal
- my friend's SonyErisson K810i bought direct from Orange 3 weeks ago & heavily customised with a new idle-screen menu, different icons etc
The UI on mine is rocketship fast, clicking a button has near-zero latency, and it has crashed once in a year. I like it.
The UI on my friend's is like wading through treacle. Much of the time, the idle-screen menu has 3-sec latency to do anything, and the rest of the phone also much less useable. He hates it and is about to take it back, or may try to have it reflashed to vanilla settings.
I suspect the fault lies with the custom UI, which I think is rendered in Java (some S-E phones have multitasking Java but no smartphone OS). I know that some Orange subsidiaries use SurfKitchen's software on certain 'Orange Signature' devices & it works OK on Symbian devices I've played with, but I'm not sure if that's the culprit here.
Either way - it's a horrible user experience and reflects negatively on both operator and handset vendor. Will it increase his spending on new & wonderful multimedia services or improve loyalty? Yeah right.
Perhaps phones are like cars.... the people who design them best are the original designers, especially non-smart featurephones. I don't add on nasty bits of plastic from Halfords to modify my car, and I don't want nasty bits of software modifying my phone.
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
7 comments:
On balance, operator UIs do very little to improve and an awful lot to degrade the user experience, and that's even without taking performance into account.
Invariably, operator customisations involve disabling or hiding functionality—which is rarely good news for the consumer, and very regularly includes hard-coding softkeys to take users to a particular option or web-site (the right-softkey on my K800i is hardwired to Planet 3, whilst on my wife's K800i on a different network it's just “Menu”, and customisable—which is actually what I'd prefer mine to be).
Basing a point on a single comparison may make for provocative, if flawed, reasoning. Carriers have a clear interest in building their identity with a branded UI, and generally these UIs are better received that the generic implementations of the handset manufacturers. Particularly in the CDMA space, carriers like SK Telecom, KDDI, Alltel and Helio have received quite a few praises for their innovative (and fast) UI implementations.
Fair point, but there is a big difference. CDMA carriers are mostly active in Japan & the US, where phones tend to be exclusive to individual operators anyway - there often is no 'vanilla' version at all - for example of Helio's phones. They're all customised top-to-bottom.
Conversely, for most GSM/European operators, it is possible to compare customised versions of Nokia, S-E, Moto, HTC or Samsung devices with the same device from other operators, or 'pure vanilla'. I have yet to see a custom version which is better than the base version.
Pursuing the car analogy, if you have a totally custom, ground-up coachbuilt, handbuilt 'special' from Zagato or Pagani or whoever, then it should be awesome. But if you take a typical Ford or Honda & bolt on crappy accessories it'll probably be awful. I don't want some nasty chavved-up Max Power'd Nokia or S-E when the original version has been optimised already.
While device performance was degraded by a native idle screen application in this case (i.e. not an On Device Portal, ODP), this post raises a valid point on the importance of overall device performance as an essential consideration for mobile application usability.
ODPs complement the native handset UI as standalone applications that improve subscriber access to operators’ data services. At SurfKitchen, we focus specifically on developing ODPs that deliver a simple and intuitive user experience that ensures seamless, minimal clicks access to content services and we are acutely aware that overall device performance is a central tenant to this endeavour. To this end, we undertake rigorous testing across multiple combinations of devices and operating systems to assure overall device performance in combination with the superior user experience provided by our ODP solutions.
Best regards,
Tim Barber
Senior Vice President of Sales
SurfKitchen
I'd imagine this sort of customisation is much more likely to be done in Flash Lite than Java?
Java has no standard screensaver API, whereas SE devices support Flash for screensavers, standby screens etc: http://www.adobe.com/mobile/supported_devices/handsets.html#sony_ericsson
Flash would seem to be the more natural tool for this kind of eye candy, and fancy icons and screensavers strike me as the kind of customisation you get branding/UI agencies to do (comfortable in Flash) rather than developers (more au fait with Java).
Top level menu and idle screen apps should be build in Flash or C (e.g. using UI platforms such as uiOne, TAT Cascade or handrolling it). Unless you have a high performance, multithreaded JVM with really solid JSR based Address Book access, you do not want to build this in Java.
There are two things I hate about my Samsung phone from Cingular (now AT&T--wait, didn't they sell that line off before they bought it?) are
I have to take out the battery to see the model number. Hard to do during a call.
The menu defaults to item 5 Cingular Mall instead of to my address book or recent call list (that is, something I actually use), and I can't change it.
Using the red hangup button as the on/off switch is merely an annoyance. Off, I can see. On, why not the green call button? Please, please, oh, please.
Performance is not an issue on this phone.
OpenMoko phones can't come too soon for me.
Post a Comment