This is the second article in the series that extends the concepts covered in the presentation design for mobile . In this post I will review the current landscape of smartphones in Spain and explain previous decisions to be taken before you begin working on a mobile project.
Designing for Mobile: return to the past
The biggest headache is caused by the diversity of devices and their different capacities. And, to the surprise of many, designing for mobile is not designed exclusively for iPhone . In our industry we have a skewed view of what the real penetration of smartphones (especially the manzanita) in the bulk of the population. According to the latest statistics from Nielsen for the first quarter of 2011 only 4 out of 10 Spaniards have a smartphone and the predominant operating system is still Symbian (ie Nokia) with a 65% market share.
While it is true that these numbers change every Christmas season and will increase the proportion of smartphones (thanks to subsidized terminal operators) so I doubt that any will be imposed on others short term. So we can not lose sight Android, WP7, Symbian or Blackberry (which prevails among adolescents surprisingly well in corporate environments) and perhaps at some point comes with Badá Samsung and HTC with their new fun Every so.
The conclusion is that users who want to get hold hundreds of different devices , and the bad news is that it is impossible to make a unique design that works in every one of them. Therefore we will have to limit ourselves to the terminals that are more common among our target audience.
Faced with the prospect of starting a new project for mobile (and “adjusted” times we usually manage) the first impulse is to download enthusiastically iPhone PSD template and start designing screens like crazy. However there are a number of decisions affecting the design that must be taken before you start, especially if you want to save time and trouble to post.
A good solution is to group the terminals for families to meet the 3 or 4 most common options, and perform a design for each of them. It is usual to make the grouping based on the nature of interaction (touch vs non-touch) screen resolutions and support key functionality.
An example of a group that made for a real web project was:
- Touch screen High resolution: covers iPhone4, Samsung Galaxy, Samsung Omnia, Nokia N7, etc
- Other tactile: iPhone3 and lower Androids medium resolution and low, Blackberry Storm, Nokia 5800 …
- Terminals with navigation buttons / wheel / pad: Blackberry Curve, Nokia E7, Nokia N97 …
For this project we define a total of 34 screens, as each was designed in 4 variants we end up with 136 PSD files. Obviously first became one of the versions until she was not fully accepted by the client did not start with the other.You can imagine that even a simple “color change” at the end of a project of this type can result in hundreds of additional hours of work.
¿OR WEB APPLICATION?
We apply different design patterns in the case of a native app or a web page.For example in a web will have less screen space available as we reserve the occupying browser bars, yet will not need to find a place to put a back button / back. For iPhone users is common to find a navigation app in the foot, but web browsing is sometimes placed in the header, etc.
We can apply the same graphical load an application to a web because we have to be very careful with the weight of the images , there are still many areas without 3G coverage and throws GPRS connection (as many will have discovered this holiday) .
¿GRAPHICAL OS ITSELF OR CONTROLS?
Whenever an app is chosen by a graph itself will most likely have to make the graphic resources to 3 different sizes (higher resolutions for low, medium and).It also affects the time and cost of programming.
A clumsy solution I’ve seen more than once to save costs is to design the iPhone application and then replicating it pixel by pixel in Android. The result is a dismal failure between an Android phone owners who feel uncomfortable with visual design and user experience who are totally unrelated.
WHAT WILL BE VISIBLE ON THE SCREEN?
In deciding the amount of items that need to display on screen the factors to consider are:
- Presence buttons hardware buttons or keyboard. Eg buttons back / back or up a menu with devices with Android, Nokia and Blackberry.
- Interaction wheel / pad or touch. Ex: If the device is touch I can not show options “rollover”
- Gesture recognition device. Eg: “drag” or “long press” to show hidden options.
- Common interaction patterns. Ex: I put a button to update data or known gesture “pull to refresh”?
WHAT SCREEN RESOLUTIONS?
There are many different screen resolutions, both in size and orientation. If we want to support multiple we will have to generate the graphs to 2 or 3 different sizes .
For the web’s best to think of a fluid design that can adapt to small variations in the dimensions of the screen and even the change of orientation of the devices. In native applications orientation change in mobile can serve to navigate between different screens or change the display mode (eg from list / graph data).
If we need to save costs and there’s only one version of the application / web is not advisable to make it more powerful and better screen devices as the most basic phones have performance problems (more limited storage cache, slower processor, etc.). If we do the reverse (design for basic terminals) lose quality graphics in next generation smartphones but the app / website may be used by a wider range of users.
If you’re working on a web project you might wonder if it is a viable solution to use responsive design . In general, the user does not expect the same content in a “moving situation” , so not enough to show the same but with different distribution. Sounds like a good choice for small websites, personal portfolios and information pages or small business.
In fact, if approached correctly, a website with responsive design can be much more expensive than a mobile version designed and developed from scratch.Depend much more expensive phone models that want to support. A good solution is to combine this technique with detection device to the server to serve different key components within the structure of the page: RESS (Responsive Web Design + Server Side Components)