Performance and Usability vs Pixel Perfect October 15th, 2011

When designing for a desktop some arbitrary ‘standards’ have been contentious issues for many years resulting in sites formalizing around grids based on a width of 960px - or should that be 970px! Really it does not matter however it does make a design agencies job easier as they only have to get one dimension signed off by you, the client.

Look at the person sitting next to you - you’ve probably got the same computer and monitor in front of you, set to the same resolution, with the same browser installed. Now look at their mobile phone - it’s probably not the same as yours, different brand, different version, different sized screen the list is endless. Therefore try working out how many versions your design agency now needs to produce for you to sign off ‘the design’, that’s a lot of effort and increased cost.

The pursuit of ‘pixel perfect’ design implementation has meant these real world requirements have all but been ignored. Some constraints have been overcome under the guise of ‘accessibility’ through the use of fluid or flexible grids and user controlled font sizes. These techniques are rare or non existent in the commercial world that has relied upon display advertising that’s based on the mythical ‘fold’ demanding that adverts are always in predefined locations with higher prices above this mythical fold.

These concepts are self-inflicted shackles used to make web design easy and comfortable for clients to sign-off and agencies to sell.

Prototyping early - just try it

There is a small, but never the less growing group of experience designers that have realised that many of their practices are no longer suited for the design of desktop solutions and even less so when asked to consider mobile. They are learning to prototype in code - html and CSS - rather than the wireframing tools of old.

Prototyping with content, in particular images and copy placed within the proposed Information Architecture, has many benefits. Doing so allows performance and usability to be tested and developed whilst testing interaction models and workflows within the context of the real devices and the scenarios described earlier. Testing prototypes at this stage becomes far more than just resizing a browser window to see what happens and what breaks.

If you’re designing in PowerPoint, Photoshop or a wireframing tool you’re missing the opportunities that only prototyping real content on real devises offers. Now’s the time to fix what has become a broken process amongst digital design teams that run the risk of losing touch with reality unless they are touching what they design.

There’s little to lose but much to gain from trying in the context of mobile design and delivery. Testing concepts whilst taking advantage of the constraints the medium enforces makes future decisions about mobile easier for the business.

Interface requirements and guidelines

The prototype practice recommended has far reaching benefits in educating and enlightening the team in what works and what’s less of a success. Documentation although detailed is often dry and inaccessible to those starting out. Rapid prototyping and the creation of a ‘sandbox’ environment allow techniques to be implemented alongside libraries and frameworks helping the identification of those that support your businesses needs. An appreciation of how little real estate is available for content once touchable functionality is made available on screen often surprises everyone.

With the mention of libraries it’s worth noting what should be considered when selecting a framework and library to support mobile needs and particularly the differences in OS support for gestures and touch. Scripting libraries from the likes of jQuery, DOJO and Sencha exist for mobile specific needs. In addition a multitude of html5 frameworks built upon evolving best practice also exist to get mobile solutions off to a good start. Our only comment here is that unless the majority of provided functionality is utilised should these frameworks be considered as every kilobyte counts against mobile performance?

Device Capabilities gesture vs touch

Each library aims to normalize the interaction model required of different OS vendors initially without this ‘support’ scripting successfully cross device is a time consuming practice. Your selection may seem simple - use the one you know - your selection criteria should also consider other, sometimes premium or subscription modules, that the vendor offers. For instance Sencha offer an image solution that resolves the complexity of delivering optimised images to varying screen resolutions and bit depth.

javaScript support or lack off

Whilst considering scripting libraries it is also worth noting device support for javaScript varies considerably. Some modern ‘smart’ devices namely blackberries indicate they support javaScript, this is correct but only certain parts of the standard. In many cases support DOM manipulation is incomplete and therefore AJAX functionality will fall back to the no script version of the feature - you do have this don’t you?

Connectivity - network coverage

Performance together with usability is key in delivering delightful mobile experiences. A delightful experience that is unusable through design or one that’s never seen because it takes so long to download fails everyone.

Every kilobyte requested increases download overhead; some of this is your responsibility in developing an optimal experience striking a balance between performance, user interface and data presentation. The constraint most likely to be an issue for businesses is that of service connectivity.

We are all to accustomed to having reasonable mobile connections whilst in town and cities. However, travel not to far outside of even a reasonable sized town any mobile signal becomes patchy at best and none existent at worse. Were demand for mobile services are located in regions known for lack of a quality mobile signal this is of great concern and worth resolving where possible.

This constraint can in some cases be overcome if users have previously visited content via their device through the use of local storage.

Testing - SaaS

Performance and usability are two of many factors that require formal and informal testing during and post development. To successfully test mobile interactions and usability emulator testing is not going to be a suitable solution because of the unrealistic delivery of presentation and differing interaction models available.

During development services from the likes of Adobe with their Device Central application, a software tool included in their CS suite of products is a good starting point to test presentation locally during development.

Testing on real devices can’t be avoided but the cost of setting up a device library to allow a representative cross section of target devices is costly and the amount of organisation required is problematic. Imagine multiple contract together with multiple sims for multiple devices, all with their own charger and connection cables. For this very reason testing is offered remotely on a SaaS model by a number of providers at reasonable cost and subscription models. I recommend clients I’ve worked with subscribe to such a service to understand current issues and monitor the situations once mobile services are launched.

User testing - device sleds

In addition to functional testing there is a requirement for most clients to run user testing on their digital services and mobile is no different. Means of doing this may at first seem difficult. Extremely good results can be collected relatively simply even in the field if this is required with the use of what have been labeled ‘mobile test sleds’ that capture the interactions and difficulties encountered efficiently live during test scenarios.