To join the team you should be able to demonstrate broad visual creativity, an understanding of user experience design and use of design techniques ranging from sketched storyboarding to pixel-perfect interface production. You will be expected to demonstrate previous interface design production and discuss relevant process and creative skills. Crucially, you must be excited by and engaged in mobile and new technology, bringing ideas and input to an expert team working in a small fast-paced environment.

We are looking to fill this position ASAP. Please get in touch for a chat by calling 01484 437454, email hello@commonagency.com or DM @commonagency.

No recruitment agencies, thank you!

iOS Human Interface Guidelines [aka "the HIG"]

The Apple Human Interface Guidelines should require no introduction by now as it’s reputation became known more for being the checklist by which an app could be rejected than as a helpful aid to interface designers and developers. Furthermore, initially much of the HIG can seem to a Mobile UX designer like “preaching to the converted” and as a result of these two things, and because we are all now so overly familiar with the iOS interface, it’s too easy to overlook referring to the Apple guidelines as often as one should do. However, when I actually go back and dig around in the HIG I’m always impressed with how it manages to convey a lot of detail yet with a general ethos that results in the coherent interface experience we know of the iOS platform.
Apple iOS Human Interface Guidelines

Android Styleguide

The recently launched [or at least massively overhauled] Android interface styleguide is a great demonstration of how to provide explicitly applicable interface rules whilst also providing enough visual examples to feel like “just a good read”. Undoubtedly the new guidelines make Apple’s documentation feel somewhat dry by comparison, though clearly this is down to Google needing to re-position Android as a genuine contender for the iPhone’s “best in class experience” now that recent Android OS versions are providing a much greater user experience. A very worthwhile read, even just as a general mobile UX guideline.
Android interface styleguide [Android v.4.0 / Ice Cream Sandwich]
Android user interface guidelines [general]

Windows Phone design guidelines

My usage of the Windows Phone guidelines has thus far been as an interested UX designer as opposed to requiring implementation on a project, but whilst not as slick as the Android styleguide the Windows Phone guidelines are a good introduction to the considerations required for Windows Phone interface and experience design.
User Experience Design Guidelines for Windows Phone
Design resources for Windows Phone

Blackberry design guidelines

OK, this is a slightly tougher read. Certainly much more a “design implementation” guideline than a styleguide, the Blackberry 6.0 design documentation is helpful to assist designers get up to speed with designing for the Blackberry experience in terms of the interface and also considering device performance and capabilities but it’s not exactly bedtime reading.
Blackberry smartphone UI guidelines
Blackberry Playbook UI guidelines 

Other resources

Of course, iOS, Android, Blackberry and Windows are not the only kids on the mobile block. Nokia, Sony, Motorola and most of the other manufacturers have all produced various design and UI guidelines over the years. I’d suggest that all the above ones are the most pertinent currently for UX designers working on the currently popular smartphone platforms. If that’s not enough though, check out the roundup on the Mobile Web Programming website.

One area I think this is particularly evident is the use of “Home” as a navigational element. When designing for iPhone or Android for instance, with their prominent ‘icon bar’ along the bottom of the screen imitating the use of a website ‘top navigation’, I repeatedly find myself defaulting to “Home” as the first icon, yet feeling this to be somehow inefficient. I have yet to fully resolve what the solution to this is, but here are some things which I think help inform the design:

• “Home” is a crucial navigational aid on most websites. I’ve witnessed many users in website usability tests who have always navigated back to a website homepage to start a task, as if “all routes start here” is imprinted across the back of their eyeballs. However, this is not necessarily the case with mobile apps, which are often more explicitly focused on a single tasks or group of related tasks. In fact, whilst I’ve not conducted website usability for some time, I’d hazard a guess that this behaviour is less blatant in current web usage as many more sites become “web apps” and adopt navigational methods and language specific to their content and features [Facebook, Twitter and GMail don't even have a "Home" in their navigation for instance].
• For apps which replicate a website approach – for instance about a company or organisation – there is presumably some rationale to having a “home page” in the app. That said, if you find yourself working on an app which replicates a website, the bigger question should probably be why a mobile web delivery solution wasn’t implemented instead, which would be accessible by any modern smartphone!
• Many digital experiences improve by adapting to the user. Websites have done this by the home page becoming increasingly personalised based on the user’s explicit or implicit usage. Mobile apps can be similarly optimised by adapting over time to the user, perhaps moving from an “introductory mode” to expose advanced features as the user becomes more adept, or hiding features over time that aren’t used. However, it feels lazy to do this by a single “page” becoming personalised. Why not just be brave and adapt the whole app experience to grow with the user.
• One of the issues apparent in the above thoughts is the use of “page” within mobile app interfaces. Pages make sense on the web and do so in some mobile apps, but generally as mobile interface designers we design “screens” and as mobile developers we build “views” [and sub-views]. Embracing this this different structure and presentational method is crucial in why “Home” doesn’t make sense in apps.

I’ve not reached a conclusion regarding an alternative to Home in mobile apps, nor even a fixed rule as to when it is appropriate and when it isn’t. However, I think the underlying principle is to be bolder with mobile app experiences, and not be afraid to break from web practices to create innovative approaches to mobile app navigational methods.

1. When you try to export a slice in a document with a lot of slices, if the slice isn’t the top layer then it’ll look like it has completed but in fact no image will be exported.
2. When you try to scroll through the text tool font list very quickly Fireworks will behave erratically and/or might crash.
3. Dragging and dropping layer groups requires pixel perfect precision, often resulting in accidentally creating a sub-group a few times.
4. You can drag and drop the tabs of open files into an order which helps your workflow… but be prepared for some pixel perfect dropping else you’ll find yourself with a totally new window being created.

Disclaimer: I shall endeavour to update the list over time, though I suspect individual workflows will offer up different quirks, and quite possibly not all quirks will apply to all users or of course all versions of Fireworks. On that note, we’re currently all still using CS4 here at Common and to be fair Adobe may have fixed some of the above in CS5. I’m sure they’ve introduced some new gems too though.

And coming out of the other side of this energetic development period, it’s blatantly obvious that iOS 5 is yet another exciting step forward for Apple, and for mobile user experience as a whole. From the seamless syncing of iCloud content to the many interface tweaks to the straight-up cool new features, Apple continues to blaze a trail by not compromising on the highest expectations for how software should work, and by demonstrating yet again that whilst beautifully designed hardware is great, the real beauty is in demonstrating how brilliant software can stand head and shoulders above it’s nearest competition.

Since the launch of the HTML5 browser based version of the FT back in June, the FT have encouraged users towards this source of the digital publication rather than that on the Apple app Store. The HTML5 version of the site allows the FT to sidestep Apple, avoiding the 30% commission and also giving the FT direct access to collect valuable customer data.

The FT have now withdrawn the app for the iPhone and iPad from the Apple app Store in an attempt to drive new customers to the HTML5 app download from the FT website.

Recently the FT reported that Mobile devices accounted for 22% of FT.com traffic and more than 15% of new subscriptions.

It will certainly be interesting to see whether the FT can drive sufficient traffic to the HTML5 version of the app or whether the distribution power of Apple app Store and iTunes will be missed.

Perhaps of more interest is the amount of money that gamers were prepared to spend. Compared to the alternative model where a user typically pays £0.99 – 2.99 upfront for the game, once a user has been engaged via the Freemium model they were prepared to spend over £60 [$100] per transaction. In fact, contrary to some expectations, whilst 71% of transactions were £6 [$10] or under, the 13% of transactions over £12 accounted for 51% of total revenue generated. The suggestion is that the Freemium model merely allows users to decide whether they want to spend or not, and that once they’re engaged and prepared to spend, the revenue generated can be vastly more than the comparable fixed cost sale of the game upfront.

A follow-up article demonstrates what type of purchases are most popular, divided into consumables [expendable items such as ammo, power-ups, etc], durables [lasting features such as a new vehicle, armour, etc] and personalisation [profile/character enhancements]. The results show that over two thirds of purchases are consumable items, reflecting the fact that mobile users generally consider digital purchases to be relatively disposable and correlate value with increased short-term engagement. Whilst it is suggested that the balance between the three types of purchase is important and will differ from app to app, it is clear that just because an app is initially free there is still ample opportunity to monetise “in-app” later in the relationship with engaged users.

QR codes are technically superior to standard barcodes in terms of the amount of information they can store and greater error correction meaning that they can be scanned more reliably – an important factor when considering mobile usage where the camera and environment might not provide an ideal scanning scenario. A side-effect of the improved error correction which appeals greatly to marketeers is that a logo can often be embedded in the QR code without breaking the stored information. For instance, the QR code below shows the Common logo, yet when scanned the QR Code remains fully functional. In fact, if you’ve got a QR Reader on your mobile [such as QRafter or QR Reader for the iPhone] then scan the code below and you’ll be taken to this post in your mobile browser!

QR Codes are increasingly used as part of marketing activity to help the reader find out further information. This might be the ingredients for a recipe on a cookery show, a list of retailers at the end of an Ad from where a product can be purchased or direct link to purchase tickets from a billboard. We recently refreshed our Common business cards and whilst we were most proud of the digital embossing and smart design, it’s been the incorporated QR Code which links to our website which has raised most comments.

It seems that thanks to the increase in smartphones, QR codes might finally have the opportunity to break through into the mainstream. For more information, have a look at the Wikipedia entry on QR codes or have a read though eConsultancy’s round-up of the pros and cons of QR codes, including a couple of examples of current usage.

Or to find out how we can help you use QR codes, whether in your next iPhone app or just on the back of your business card, get in touch by emailing hello@commonagency.com.

Ad Hoc Distributions allow you to install an iOS application before it’s available in the iTunes app store. This is how we test iOS applications bugs, review them with clients and distribute them for user testing.

Requirements

You will need:

• The .ipa file.
• The .mobileprovision file for the application.
• The device with the UDID that you have provided.
• The computer that you sync with your device.

Installing

1. Save the .ipa and .mobileprovision files to your desktop, or another convenient place.
2. Open iTunes, and drag-&-drop the .mobileprovision file onto Library.
3. Drag-&-drop the .ipa file onto Library (on a Window’s machine you can double click the .ipa file to install it). If you get an error don’t go any further, contact the developer as there could be a problem with the files or provisioning.
4. In iTunes go to the Applications area of the library, check that the ad hoc application is listed there amongst your other applications.
5. With your device connected, select your device and the applications tab. Confirm that the new application has been checked ready for syncing.
6. Sync your device with your iTunes. Once synced you should be able to see the ad hoc distribution on your device as you would any other application.