A mobile development strategy
Nowadays more and more interactive projects have a mobile component. This article lays out a strategy that I think would work for a mobile website. As there as so many different devices and screen resolutions on that market, one has to be very flexible and pragmatic to be able to develop something that works like it should. In this article I’ll try to explain how to make this happen with a couple of simple techniques. I will not go into the details of any of them just yet, this is merely an explanation of the strategy. Later articles will be much more concrete and will show hand’s on examples.
Things to keep in mind when developing for mobile
If you build a mobile website, you could re-use the templates that are used for the regular website and just change the CSS. So, downscale images, downscale the grid, hide certain assets, and maybe put the menu on the top of the page.
I used the tricks above on my own website and wrote about them here. I used media queries and a fluid grid to make my website accessible to all the devices I liked. Developing in this particular way is fine for websites that do not have a specific mobile concept. It just makes them easier to navigate on an iPad or HTC phone. But you should not do this for a project that has it’s main focus on mobile.
If you are developing a specific website or app for a mobile device, there are some considerations to keep in mind. Remember that you usually have a strict policy on Internet use and that you only have a 3G or GPRS connection. Even if you hide the slide show or the background images, the browser will still download them. The same goes for resizing images with CSS. You uploaded a big image for your desktop users, but you scale it down for mobile users. It turns out that the mobile browser actually downloads the big image and then scales it down.
For me this is a total “no-go”. Why load stuff you can’t even see or scale down? It just slows down the experience and drives up your Internet costs.
Some companies advertise that they allow flash to work on their device. That sounds promising, but I have not seen any workable and performing sites yet. The flash drivers on those devices are not optimized for a mobile and slow down or crash the browser. A definite “no-go” again.
Context baby!
When you develop for mobile, in what context users view your site is very important. On a mobile you are usually more hands-on and more goal-focused. Imagine running for the train and you forgot from what lane your train is departing. You grab your mobile, squeeze your bagel somewhere and browse to the train company website to check the departures. How frustrated would you be if you had to browse through 5 pages and scroll along media players that show the company’s history and such? You just want to get to these departure lanes...
I propose a set of simple templates that already know that the website is being viewed on some sort of mobile / touch device. In this template you can leave out all the fancy slide shows and high-res images. Instead, just focus on the most important information.
I personally think that if you design a website, you should start with the mobile version. It let’s you and your client focus on the most important piece of information on the entire website. After that, scale up and design the fancy stuff. If you organize your process this way, hopefully all your team members get a sort of group conscience that you are working on a design that has to be very adaptable to the users context. Everything should be flexible and fast. It’s the wobbly web people, not a magazine... Nothing is fixed anymore, not even pixels (check the iPhone 4 screen).
Device classes
Because you can never develop for all devices in the world, it’s handy to classify the most used resolutions and devices into some groups. You can target your design and development to each of these groups.
Each of these device classes has a unique:
- context (chill mode on the couch, desk use, running);
- input method (touch events, mouse etc);
- average display size.
Luke Wroblowski wrote a great piece about this.
Responsive design and fluid stuff
Responsive design is a relatively new term, but actually it’s as old as the Internet. Remember all these old school websites that would fill your whole screen? These designs where percentage based and would scale down if you had a smaller screen.
Responsive design means that you design something that is able to respond to change. The design is adaptive to the context it’s used in. For example: resolution, landscape or portrait, JavaScript support, CSS3 support, touch or mouse oriented. So it’s not just a fluid grid.
Read more about responsive design.
Stuff you can use when developing a responsive design
Progressive enhancement
This is a much discussed topic for years. Any respectable web developer should know about this by now. It is even more important to use it for mobile development. There are loads of devices with many different browsers and versions. Feature detecting is a key element in responsive design. This is a nice article about progressive enhancement.
Fluid “em-based” or “%-based” grids
Using a fluid grid can help you a lot in mobile development. As there are a lot of different screen resolutions it’s not manageable to design a fixed grid for every device. Just design for an average screen that has been classified in the device classes mentioned above.
If your design is fluid you can still pull of resolutions that fit in the classification but are a little different then the one you initially designed for.
Fluid images and client side adaptive image replacement
Fluid images is a very sexy technique which Ethan Marcotte helped make famous. It basically means that even your images scale according to the resolution of the device.
There is a drawback to this technique. To be able to scale the images you need to use the biggest one possible to match all your design stages. A stretched image on a website is horrible. A nice solution is “client side adaptive image replacement”. Read more about about it here.
Media queries
Media queries are hot! The spec is not entirely finished but they are very usable nowadays. Media queries let you add CSS rules according to a query that you specify. For example “orientation: landscape”, or “screen”, or “max-device-width: 768px”. Picture the strength of these when you build one interface for let’s say two devices classes. When you get below a screen width of 320px, move the menu to the top and when you hit 240px remove that new column and make the typography a little bigger. Try resizing this website, look at the Media query magic!
Conclusion
If you put all of this together, mobile development is in desperate need of “adaptive” design and development. It’s hard to predict how many devices are yet to come, and what their capabilities and resolutions will be. If your design is adaptive and feature detecting you can be almost sure it will service old and new devices. This is a pretty bold statement so let’s hope browsers keep implementing web standards the correct way.
If we developers and (especially designers) keep it about web-standards, we can show our team-leads and project managers that they do not have to buy insanely expensive packages like net biscuits. It would be awesome if designs become a little more web-oriented so that developers and designers can work together more closely. This not only prevents extra overhead in your project, but also helps creating a great standards-based web app that works on a large range of mobile devices.
Comments