The tips for successful mobile calls to action are mostly backed up by examples and could be split into the following main areas:

• Visual design [make them colourful; make them massive]
• Usability [put them where they can be seen; use of unambiguous wording]
• Behaviour [create a sense of urgency; get them to the checkout ASAP]
• Functionality [offer a click to call alternative; adapt for different devices]

Check out Econsultancy’s original article at http://econsultancy.com/uk/blog/10341-mobile-commerce-calls-to-action-eight-best-practice-tips/

The method

It’s unlikely there’s anything new here but just for clarity, firstly a little description of the method used to implement retina interfaces. Apple of course provide documentation to explain the requirements of designing and implementing retina graphics but it’s really very straightforward. An asset in iOS code should be referenced in it’s standard (e.g. non-retina) size, and when displayed on a retina device the asset will automatically be replaced with an available retina version, represented to the OS by an asset of the same name with “@2x” appended to the root of the filename. For instance, the image “myLogo.png” will automatically be replaced on retina devices with the version “myLogo@2x.png” if provided. Simple as that. Furthermore, the @2x version is optional, so some assets might need it and others might not. So an icon or logo might benefit from more detail in the retina version whereas a tiled background might either not be needed or could have a different tiled pattern.

The approach

Once the above method was declared, mobile UI designers mostly adopted one of two approaches – either design to standard sizes using vector artwork and scale up to produce retina assets or design to retina sizes and then scale down the retina assets to produce standard ones. Personally I prefer the latter approach because I find it preferable to work at the detail level required of retina, because scaled down bitmaps (when scaling to a nice scale such as 50%) usually look fine and because it seems mad to work at the standard resolution which will over time be phased out. Very occasionally you’ll find for detailed assets that the standard version lacks clarity because there was too much detail in the retina version before it was scalled down. This is a) easily avoided by using some handy tools (see next bit) and b) easily rectified if needed by recreating the asset from scratch.

The tools

• Fireworks
  Despite it’s quirks, Fireworks‘ mix of bitmap and vector tools and the ability to break UI designs into pages, as well as a load of slicing/exporting/prototyping output tricks has for me continued to keep it ahead of Photoshop as my core UI design tool.
• LiveView Screencaster/XScope
  The free Liveview Screencaster is an indispensable aid to producing better interfaces for iOS. By enabling a designer to view designs in real-time on a device as they’re being produced will improve the designs from the outset. The commercial tool XScope offers the same feature along with some other very helpful measuring tools, though I usually prefer the simplicity of Liveview.
• Prepo
  Reducing retina assets to standard size is a simple drag-and-drop operation when assisted by a dedicated tool. Originally I used the excellent Unretina but it’s now open-source as not as easy to work with these days so my preferred tool is now the very capable and free Prepo.

A new trick

So, if you’re much of a mobile designer and have read this far then chances are you’ve not learnt much new. You’ll also be completely unimpressed to have read that producing standard non-retina images is a matter of dividing the retina version by 2. However, my recent revelation was that in some circumstances as a designer you need to consider whether the retina version is divisible by 4! Somehow I only recently hit this problem, but when I did it took a considable amount of reworking to reproduce the assets – enough that I’ve learnt to plan for it next time.

The issue comes with centred assets. Let’s say I have a big round button which I want in the horizontal centre of my interface. It’s 100px diameter with a 5px border, so that’ll be 110 pixels total diameter at retina size. On the 640px wide iPhone retina screen, this will therefore have an x co-ordinate of 265px e.g. (640/2) – (110/2) = 265. Now let’s consider the standard version which is 55px wide. In most circumstances, standard images can have odd pixel dimensions and you’ll not notice an issue. However, if we try to place our 55px image centrally on our 320px wide standard iPhone screen you can see what will happen e.g. (320/2) – (55/2) = 292.5. As a result, depending how the drawing of the image is coded, the image will either be off-centre as it’s placed at 292px or will be heavily anti-aliased as it attempts to be placed at 292.5px. Maybe an image explains it better…

So, how do we avoid this at the design stage? Just check that your retina asset is divisible by 4. For instance, had my original button been 112px in diameter, the standard one would have been 56px wide which sits perfectly centre-aligned and “on pixel” at an x co-ordinate of 132px.

Anyway, the upshot of all this is that I recently learnt something new about preparing retina assets, and figured others might like to learn it too. It’s not rocket science but just remember that sometimes you need to consider if a retina image is divisible by 4 as opposed to just by 2.

In fact, the above models are just the European ones we have in the office for testing. There are a few other model numbers relating to iPhones distributed in other regions. Check the full Apple support article for full details: http://support.apple.com/kb/HT3939

• Whilst not as radical a “shift change” as felt evident moving to the iPhone retina display from a non-retina, the screen on the new iPad is indeed beautiful and has genuinely drawn a few “wows” from onlookers. Smitten as I am, I’ve found myself marvelling at the detail visible in the lush 144x144px icons or small drop-shadows and textures in updated app interfaces.
• It’s “rapid” [as teenagers are currently prone to say]. The only one of my apps which ever shows a hint of interface delay is Sketchbook Pro, but that’s only very occasional and to be fair I do throw some fairly heavy Photoshop-like tasks at it.
• I’ve got a red leather cover. Looks and feels sexy!
• Migrating from the iPad 2 to the new iPad has suddenly made “the cloud” essential to me. In my case the cloud means both Dropbox and iCloud. I didn’t want to use the excellent “backup old device and restore to new one” method of migration even though it works flawlessly. Instead I wanted to start again and hand-pick the apps which have become essential to me. I was pleasantly surprised to find that all of my essential productivity apps [most of which are mentioned below] have embraced the cloud so throughly that migration was usually as simple as installing the app on the new iPad, entering my account details and watching as the data dropped into place. I mean, I know that’s how the cloud is meant to work… but only when it’s this effortless, efficient and robust do you get that “I’m never going back” feeling.
•  And then there’s the apps. I couldn’t possibly list all of the apps here – and it would be pointless anyway as there’s some “obvious” crowd-pleasers in the list below – but iOS devices are all about the apps and in my first week these ones have brought the whole experience to life:
• Sketchbook Pro: Fantastic sketching tool with clever intuitive features that make you want to draw, whilst offering great cloud and export options to other packages.
• Readability: Saving web pages to read later on your mobile device is not new, but there’s something about the experience of Readability that make me want to save any text-heavy webpage to read on the iPad e.g. blog posts, news pages, etc.
• Byword: I’m increasingly becoming a Markdown fan and I also buy-in to all the “purist” considerations that simple writing apps remove any distractions but more than that, Byword just enables me to write stuff quickly and easily whilst on the go.
• Penultimate: I’ve stopped taking notes on paper this week. I’m not throwing away paper just yet as I think it breeds a different creative freedom to digital interfaces, but the convenience of having meeting notes digitally and, if I’m honest, the brevity enforced by feeling very slightly restricted compared to writing on paper are both huge benefits, and Penultimate is the best note-taker I’ve found yet.
• Kindle: I didn’t used to read “proper” books much because I like to read in bed. Increasingly now I do thanks to an experience which applies very subtle enhancements which just maximise books when presented digitally.
• Thanks to the other AirPlay-friendly gadgets in my life [speakers, Apple TV, Macbook, etc], my media consumption has now gone through the roof. BBC iPlayer, 4oD catch-up, LoveFilm, TED…
• When I have my User Experience Designer hat on, my toolkit is now iPad-centric. App Cooker is indispensable for wireframing iOS experiences, UI Sketcher is handy for quick interface ideas, WiFi photo lets me grab screenshots off my device effortlessly and LiveView helps me to preview designs on the iPad in real-time as I’m creating them on my Mac.
• Machinarium: For whatever reason I never gave-in and bought this game previously but now on the new iPad it’s just beautiful. It’s not had a retina update but doesn’t need it. The story, gameplay and attention to detail feel like gaming meant for the iPad.

So that’s it. I know plenty of the above also applies to previous iPads but the genius of Apple’s design process is continual product evolution, so it’s often hard to define why the latest is “just a bit better”. All I can say is that after a week of reckless romantic abandon with the new iPad, this one’s a keeper.

Other enhancements through iOS 5.1 include:

• With iOS 5.1 the camera icon is permanently on the lock screen and a simple swipe up reveals the camera app.
• There is new camera functionality for the new iPad and iPad 2.
• iOS 5 will allow the new iPad to play 1080p HD.
• Sadly we don’t see Siri making the jump over to the new iPad but Apple have added support for Japanese with Siri on the iPhone 4s.
• Whilst not getting Siri the new iPad does get dictation as part of the iOS 5.1 offering with a new key on the virtual keyboard.
• In iOS 5.1 the audio for Movies and TV Shows has been enhanced.

So, the new iPad has a screen resolution of 2048 x 1536 pixels [double the 1024 x 768 of the iPad & iPad 2]. As an iOS designer/developer though, the joy of the improved visual clarity is marred by the concern about asset sizes. A full screen photo or UI background for iPad would typically be around 1Mb in size. Having done some brief resizing tests, this is likely to result in the new iPad retina versions being between 2.5Mb – 3Mb. Add to that the original non-retina version which still needs including to support the older iPads and each full screen design will conceivably require at least 3-4Mb of space. Add to this the increased processor performance in manipulating such assets and it’s clear that the retina display of the new iPad will introduce some interesting challenges for iOS designers and developers. [Note: All the above sizes are pre-compile sizes. During the production of the final binary using XCode, files are compressed using pngcrush which will in most cases reduce the file sizes considerably, but comparatively the above sizes still demonstrate the issue].

One of the obvious challenges which was a foreseeable concern for developers was the “wifi required” install limit of the App Store. Until the launch of the new iPad, users could only install apps larger than 20Mb if they had a wifi connection. However, to produce a “Universal” iOS App – one install that is optimised for non-retina and retina displays on both iPhone and iPad – 20Mb now seems measly. Hence, Apple have increased the limit to 50Mb – as shown in the attached screenshot.

Another challenge for designers is the implications of working with design files at this size. I’m a huge fan of Adobe Fireworks for UI production, and we always work at retina resolutions so that we have a choice to either reproduce or just down-scale assets for non-retina displays. However, Fireworks can sometimes suck when using complex multi-page, multi-layered documents, and to now be required to work at 2048 x 1536 for iPad designs is going to be a challenge to Fireworks’ stability and to a designer’s patience! Is it too cynical to suggest that Apple might have noticed we’ll need to go and buy bigger and better Macs now too?

Finally of course, it goes without saying that there will soon a be a rush of new templates and design resources to assist us in designing and developing for the new iPad retina display. To save any digging around, just keep an eye on the excellent Teehan + Lax downloads. Let’s hope they’re working away on the new iPad version right now!

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.