A common problem in software design is a mismatch between the proposed visual or experience design and the actual result, as implemented in the product.
Ironically, a user experience that is well designed ‘on paper’ can still yield a poor experience for the end user. This may occur if, for example, the designs:
- Are hard to implement, requiring workarounds that may affect stability and performance.
- Require downloading or use of many otherwise unnecessary graphics.
- Do not scale or adapt well to other devices.
- Require unnecessary calls to the network, which may increase the cost of using the application.
An experienced designer will take these problems into consideration, and key to this is an understanding of the limitations in the underlying technology. Below, you’ll find a collection of recommended techniques to assist in marrying your application’s design with its overall performance.
Optimising graphics
Consult the following guide for tips to optimise the use of graphics in web and native applications.
Optimising for screen size and pixel density
While it may be obvious that a design should be optimised for various screen sizes, ignoring the impact of pixel density is a common mistake. Consider the three devices pictured below.
Each of the devices shown has a 240 x 320-pixel display, but the displays vary in physical dimension and, therefore, in pixel density, which ranges from 154 to 199 pixels per inch. The implications are most obvious for images, particularly those that contain graphic text or fine details.
Pixel density can vary more than you may think. The Nokia N900 mobile computer, for example, has a 3.5-inch screen and a
resolution of 800 x 480 pixels. Those measurements result in a pixel density of 265 pixels per inch (PPI) — considerably
higher than any comparable mobile device (120–160 PPI) or even a typical desktop computer (67–130 PPI).
Optimising data use
In terms of loading and manipulating content, your choice of data format can affect the performance of your application. Here are some things to keep in mind:
- In web, WRT, or Flash Lite development, loading and parsing XML will require additional processing power and affect performance. XML files can also be larger, in kilobytes, than equivalent content delivered in other formats. For HTML or WRT development, consider using the JSON format instead. You also can achieve good results by simply loading content preformatted as HTML.
- In Flash Lite development, store data in simple name/value pairs and load them from a text file using LoadVars, or from precompiled SWF files. Name/value pairs load more efficiently than XML-formatted data, because Flash Lite technology automatically parses these pairs into variables. Shortening variable names can help, if you are using hundreds of name/value pairs. See Flash Lite authoring and optimisation tips in the Flash Lite Developer’s Library area of the Library.
- Note that Flash Lite technology also is not very efficient at parsing large XML files.
What is JSON?
’JSON (JavaScript™ Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It
is easy for machines to parse and generate. ... JSON is a text format that is completely language independent but uses conventions
that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and
many others. These properties make JSON an ideal data-interchange language.’
— json.org
Optimising text and font use
Font control for mobile devices is still poor, and designers are, for the most part, limited to use of the device font. On S60 devices from Nokia, this font is S60 Sans and is used in the browser and the operating system.
There is, however, more flexibility in font handling with the following device and development platforms.
Flash Lite
In Flash Lite applications, you can specify the use of a device font, make use of specially optimised pixel fonts, or embed a font of your choice. Whichever option you choose, consider the following limitations when working with text:
- Anti-aliased text in the Flash Lite environment is essentially a complex vector shape. As with any vector shape, rendering it requires processing power. Because processing speed on most devices is relatively slow, animating a lot of anti-aliased text may degrade application performance. To improve performance when animating anti-aliased text, try temporarily lowering the Adobe Flash Lite Player's rendering quality during the animation and then returning it to the original level when the animation is complete.
- Avoid superimposing text on an animation. Consider instead using text as a bitmap, which typically requires less processing power to render.
- For multiline dynamic and input text, the line break of the text string is not cached and must be recalculated every time the string is redrawn. This can be processor-intensive. When dynamic functionality is not required, be sure to use static text fields, because their lines breaks are precalculated at compile time. (Source: Adobe)
See Fonts, in Flash Lite Developer’s Library, and Font rendering methods in Flash Lite, on the Adobe website, for more information.
Optimising design for multiple interaction models
One of the key challenges when designing for newer mobile devices is the difference in interaction models. While most Nokia devices utilise indirect (keypad) manipulation, many newer devices now support direct (touch) manipulation. Some — such as the Nokia N97 mobile computer — even support both.
Here are some factors to keep in mind when designing for touch-enabled devices:
- Design for touch, but don’t disregard the keypad: Applications for touch-enabled S60 devices should, of course, be designed to enable users to accomplish every task with the touchscreen UI. Be sure, however, to also test applications on a keypad-enabled device to ensure that keypad interactions do not fail.
- Make touch discoverable: While nontouch application UIs use highlighting to indicate focus, touch application UIs typically don’t. It’s therefore important to make a clear distinction between content, shapes, and controls that can be manipulated through touch actions. You can use borders, bevels, glow effects, and other visual indicators for this purpose.
- Ensure adequate size: To optimise controls for touch, also consider size. Controls should be large enough to grasp, and adequate space should also be left between adjacent elements to ensure that users don’t accidentally trigger unwanted actions. See Scale and Positioning of Controls, in the Developer Library’s Design and User Experience Library area, for guidelines regarding the optimal size of S60 5th Edition controls.
- Plan for user customisation: The appearance of the Nokia UI can be fundamentally customised through theming. Don’t rely on the active theme to indicate touch functionality and affordances. Some themes may reinforce the touch cues you have provided, but others may not. Test with multiple themes to better understand and anticipate their impact on your design.
See the article Touch-enabled vs. touch-optimised, in Design and User Experience Library, for information about the advantages and disadvantages of touch-based manipulation.
Links and resources
Nokia’s Optimising Software with Built-In Power Profiling describes S60 software profiling tools that enable developers to measure power consumption without external equipment. The
document also contains guidelines and best practices for maximising application-use time.
A section of tips for Flash Lite authoring and optimisation, in Flash Lite Developer’s Library, provides guidelines for improving Flash Lite performance. The section covers
both content and ActionScript optimisation.
