Fling identifies 6 rules for designing apps that we should follow:

1. Understand the medium – Get to know the difference between mobile and other mediums.
2. Get your data dialled – Data is the new content and it comes from everywhere.
3. Be the master of context – Dive into context, it is the easiest way to level up to awesomeness.
4. Design for interaction – A gift for pixel perfection and a psychology degree can come in handy.
5. Focus on the details – Small screens don’t make things easier. They make things a lot harder.
6. Allow ample time – It takes a lot longer than you might think.

Fling’s presentation at @media 2011 can be found on Slideshare. It’s long, but certainly worth a viewing.

To provide the best possible experience on each platform, don’t deliver an iPhone experience to a BlackBerry or Android user. Every platform has its own UI and usability guidelines that every user is expecting from your application. For example, the popular Twitter application TweetDeck has a different user interface and therefore user experience between its iPhone and Android versions, albeit the TweetDeck team aims to provide a similar user experience on both devices. The same can be said between mobile an tablet devices with Reeder and Pulse prime examples on iOS devices.

Apple (iOS)

• iOS Human Interface Guidelines or the PDF version (PDF 12.9MB, pp. 150)

BlackBerry

• UI Guidelines for BlackBerry 6.0 Smartphones or the PDF version (PDF 9.2MB, pp. 109)
• UI Guidelines for BlackBerry 4.x, 5.x Smartphones or the PDF version (PDF 7.4MB, pp. 89)
• BlackBerry Browser Content Design Guidelines (PDF 356KB, pp. 29)

Google (Android)

• Android User Interface Guidelines
• Motorola’s Best Practices for Android UI

Microsoft (Windows Mobile, Windows Phone 7)

• UI Guidelines for Windows Mobile
• Windows Touch UI Guideline
• UI Design & Interaction Guide for Windows Phone 7 version 2.0 (PDF 11.9MB, pp. 101)

Nokia (Symbian)

• Nokia Design & User Experience Library
• Symbian^3 UI Style Guidelines (PDF 4.5MB, pp. 105)
• Forum Nokia Design Portal
• Symbian UI Wiki
• Nokia Series 40 UI Style Guide
• Hildon UI Guidelines for Nokia Maemo

Palm/Hewlett Packard (webOS)

• webOS UI Guidelines

Sony Ericsson

• Sony Ericsson UI Rulebook

Others

• Bada Application UI Guide
• MeeGo UI Design Guidelines

If you know of any other examples of UI guidelines for mobile or tablet devices or have any general thoughts, please feel free to add them to the comments.

In January 2010, Apple announced to great fanfare that they had recently sold their 3 billionth iPhone application. Of course not all these applications are paid-for, but with a 30% levy taken on each and every paid-for application, Apple are taking a significant share of the revenue from the application pie. However, as a distribution channel, the AppStore is second to none, whilst the iPhone uptake is staggering, with a majority share of the smartphone market in many regions of the world. There is a significant opportunity for any developer to make a huge return on investment, assuming the idea is a winning one.

iPhone, Android, Windows Mobile, Blackberry, Nokia and now the larger form factor iPad and Kindle support the idea of applications, or will do in the near future. So what do you need to do to design and build your first application?

1. Familiarise yourself with the rules
   Whether you’re going to build applications for the iPhone OS, Android OS or any other of the mobile platforms, you will need to familiarise yourself with how each operating system does things. Smartphone development is different from the development we are accustomed with on the Web. Reading the user interface guidelines for each platform will go a long way to developing your first application. Smartphones are personal devices and know where you are almost all the time through GPS. They have rotation detectors, compasses and multitouch screens with gestural interfaces. Only once you know what is possible with each smartphone platform can you begin to design your application.
2. Brainstorm the issues
   This is the creative part of your application development process. You have a basic idea, but you need to take it forward into something that has features and benefits. Will the application be paid-for or free? Will it provide a service or be a marketing channel? Will it be standalone or link closely with other online presences and networks? Smartphone applications, unlike ordinary websites, invariably need to actually do something. There is an element of artificial intelligence at play, whereby the phone can actually know where it is in the world and it’s orientation, whilst the user interface is remarkably different from that of simply a mouse and keyboard. Smartphone applications can’t simply be flat catalogues, they need to do something and do it well. Whether this is booking and accessing a car as with StreetCar, buying something from eBay, paying with PayPal, creating music with RjDj, drawing pictures with Brushes, price comparison with RedLaser, reading the latest news from the Guardian, video casting with Qik or planning your journey with Tube Deluxe your app needs to be compelling.
3. Create a prototype
   You have your compelling idea; create a proof-of-concept prototype. This prototype is used to test some or many aspects of the intended design without attempting to exactly simulate the visual appearance, content or intended interactions. Such prototypes can be used to “prove” out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. Making paper prototypes, for example, is a great way to test the application rather than creating low or high fidelity wireframes and hoping for the best. Doing this also provides a perfect opportunity for people around you — friends, colleagues and family members — to try out the prototype with little fuss. Only once you’re happy with the design should you begin any form of coding.
4. Submit early
   You have your application working. You have conducted a number of usability tests and all is looking great. It’s time to submit it to the appropriate application store. Apple has its AppStore, Android its Market Place, Nokia its Ovi Store and so on. Each store has its own nuiances, but if you’re considering an iPhone application, Apple has been know to drag its feet when approving applications for release. Apple has a much discussed approval process, with the possibility of rejection commonplace. Don’t make plans that depend on Apple. It is better to silently release the application, rather than creating a huge fanfare.
5. Iterate often
   Once your application has been launched your work is nowhere near over, indeed it has just begun! As you gain more and more users, improvements will suggest themselves not only from within your team, but more often, from your users. Here is where you go back to stage two and start brainstorming again. Version 2 may include bug fixes, but also major feature updates. For the latter, your brainstorming will decide what is most important for the next iteration. When your next iteration is complete, the AppStore, for example, makes upgrades far easier to achieve than for normal desktop software.

If you’re planning an application that could disrupt one of the smartphones capabilities, such as Google Voice for the iPhone, it may be worth considering whether building an application specifically for that particular operating system is worthwhile. Google Voice was neither approved nor rejected by Apple for the iPhone, but has now been replaced by a fully featured HTML5 web-based application; circumventing the Apple approval process. Of course this now means that the same web-based application can be used for not just the iPhone, but other smartphones.

Now go forth and build it!

Resources

Smartphone User Interface Guidelines:

• Apple iPhone Human Interface Guidelines (HIG)
• Apple iPhone Application Programming Guide
• Android User Interface Guidelines
• Android Human Interface Guidelines (adapted from Apple)
• Nokia User Interface Style and Visual Guidelines
• Palm User Interface Guidelines
• RIM Blackberry User Interface Guidelines

Application Development Frameworks:

• PhoneGap an open source development tool for building iPhone, Android, Blackberry and other mobile apps with JavaScript
• Appcelerator a mobile development platform for javascript developers

Mobile Web Application Frameworks:

• jQTouch a jQuery plugin for mobile development
• iUI an iPhone/iPod Touch user interface framework

Other:

• Wikipedia article on Mobile Development

QR-Kill Rules

1. A QR-code with your name and phone (SMS format) will be printed in a 20cm minimum width sheet of white paper. It will be reinforced by a hard cardboard and stuck to the back using american tape.
2. The QR-code must be visible at all times. It cannot be covered by any means, wall, floor, etc.
3. Once you receive the deathly SMS you must leave the scenario right away.
4. When team playing, members can only communicate by using same phone they use as a weapon.
5. Disguising is allowed as along as the QR-code is visible.
6. Unless playing sniper mode no extra devices can be used to capture the QR-codes (e.g. zoom photo cameras, videocams, etc.)
7. If there is a conflict deciding who killed first, SMS time will decide (we recommend synchronising watches before the game starts)
8. No one can assist you to kill the enemy with your phone. However you can hire spies, etc.

You can create QR-codes on Kaywa’s website.

But there was something missing in my toolset; a WordPress app. Typepad have long since had one, so it was about time my favourite blog platform upped the ante!

Well, I’m glad to say, as of today an app has finally reached the Apple App Store that allows me to write posts: thank you Automattic.

In fact, just for good measure, this blog post has been written from the app.

The interface is intuitive and easy to use, although it does lack admin features, which for some may be a concern.

I’m sure I’ll get RSI if I continually blog via my iPhone, but for those moments when I’m caught away from a computer and desparately want to offer my 10 pence worth to the blogosphere, it’s a good tool to have.