iOS and UIQ

apple.gifEvery time Apple starts a new patent trial I think how Apple wasn’t that innovative in that some aspects of iOS were found in Symbian’s touch screen OS UIQ. However, it’s my belief that Apple’s deserved success came through being able to cleverly commercialise the innovations when others had failed. 

I have previously mentioned how tapping on something such as a telephone number or address to cause an appropriate action isn’t new, was found in UIQ and is almost certainly prior art. In fact, actioning (as opposed to tapping – because we had no touch screens) an item and performing an appropriate action was an early Psion innovation.

Today, John Pagonis, an ex-Symbian employee mentioned on Twitter that Steve Jobs had a UIQ phone and even had a licence to the Symbian UIQ source for evaluation. This licence forbid Apple from pursuing its own mobile OS. John mentioned he knows this because he was sitting near the account manager who was responsible for the Apple account. This tends to explain how some aspects of UIQ ended up in iOS. Many innovations, whether from Apple or Samsung, are based on previous innovations.

UPDATE: As ex-Symbian Keith Playford mentions on twitter, UIQ owed more to Newton and Palm than iOS owed to UIQ. Symbian even had ex-Apple Scott Jenson on-board.

Kintek’s Portkit iOS and Android UI Controls

kintek.pngIf you are designing cross platform then you should take a look at Kintek’s Portkit that shows some UX metaphor equivalents across iOS and Android. It also usefully shows how the new UI controls might look for iOS 7.
kintekkit.png

Android UI Fast Track for Designers

android.gifI have previously written about Android Design and how too many people approach me with iOS-looking designs for what will be an Android App. I previously created an article outlining some tips for porting iOS to Android. Assuming you now have an Android-esque design, what about variation of the UI on differing devices and for orientation switch?

There are broadly two types of project – what I call "cost sensitive" and "user experience sensitive" projects. Cost sensitive projects tend to leave fragmentation of the UI to the developer and there’s some great information on the Android Developer site.

User experience sensitive projects need to define more upfront. Designers need concise guidelines. The problem is that, depending on where you look, Google’s documentation appears either too technical or too verbose and contains no pragmatic tips to shortcut some of the possibilities. In short, the documentation seems more for developers than for designers.

One of my followers on Google+, Maksim Golivkin, has pointed me to a SlideShare presentation that he has created that provides a useful fast-track for designers. It defines what’s needed and contains some great tips to cope with screen variety.

Mobile Frameworks and Custom UIs

dotnet.gifIf you are looking for a good primer on how to choose a mobile framework for your app then you should take a look at "The developer’s guide to mobile frameworks" on the .dot magazine website. The author, Jonathan Stark, is correct. The actual choice very much depends on the needs of the project. 

One problem with web and webview hybrid apps is styling to get an iOS or Android look and feel. I am seeing many big brands’ apps forego this completely as a) It’s so complicated and takes an excessive amount of effort b) You’ll never get 100% look and feel c) It entails including lots of (large) javascript libraries that have their own bugs and d) The brand ‘look and feel’ across devices is more important than being consistent with other apps on the same device. This last point takes me back to 2007 when I talked about ‘Native or Custom UI?’ within the context of a wholly native app.

iPhone App UIs on Android

DmitryNekrasovski.gifDmitry Nekrasovski has some thought-provoking ‘design principles’ for converting iPhone apps to Android. He concludes that user experience differences between Android and iOS are only noticed by expert Android users. 

This implies it’s possible to keep much of the UI the same and only change a small sub-set (e.g. parts of the UI the Android buttons make obsolete). I suppose it’s an interesting, alternative, pragmatic approach for some types of projects on a lower budget.