When thinking of contemporary websites, the mobile version is definitely a must-have. However, in a bid to provide users with exceptional experience, you often need to find a proper balance between visual presentation and mobile context.
“Responsive” is a magic term, but it is mostly used just for making websites look great on mobiles and tablets. Two main factors need to be considered here: screen size and touch. Of course you can consider a plethora of other devices (like TV’s), but usually this is not the deal for something we could call “a typical project”. You don’t need to be a web development superhero here, but knowing just the very basics of responsive web design gives a boost to your work. Let us stop here for just a while, mentioning the three pillars of RWD, saying what they actually do:
Fluid grids let you adapt the page layout depending on the screen width. There are many available and ready to use out of the box. One example is Profoundgrid. You can test it by re-sizing the browser window to see how particular elements re-size and fall down to meet the resolution constraint of a device.
Flexible media (mostly used for flexible images) in short resize to the space that is given for them.
Media queries (which have undergone a strong development since CSS2) in CSS3 give a possibility to adjust the content not only according to the device type, but also to the screen size, by selectively loading specific CSS.
Media queries are not only very useful – they are also quite easy to understand. For example:
rel="stylesheet" media="screen and (min-width: 800px) and (min-height: 600px)" href="desktop.css">
will tell the browser to apply desktop.css for screens that are a minimum of 800px wide and a minimum of 600px high. As you can see, this is no magic. This rule can be applied in various ways (e.g. desktop.css can be imported from a main.css file or it is possible to have all the CSS code in one file, and then just defining conditions for using one or another).
Media queries can also deal with other factors of how the site is displayed on a device, such as screen density, the ability to display color, supported color space and even aspect ratio. However, you should use it with caution, as some devices may not take the full advantage of media queries (e.g. many TV’s do not support identification by media type). Refer to this great article by Luke Wroblewski for more details and this explanation of media queries on Mozilla Developer Network.
This is also crucial in the majority of cases, as in this way (by using images as CSS backgrounds) we are able to highly limit the usage of data downloaded from the server.
Now, combining these three together allows you to make your website responsive. Yay! Depending on media type and screen size, various stylesheets are loaded, different images are used for styling, elements fall down to match the screen in a much controlled way and every cog in our clockwork works perfectly.
But proper implementation is not the end of the story (or rather: it’s not the beginning). Even if the technology itself is user-oriented here, it is not enough to think of how the content adapts to a mobile device, but how it adapts to the user. As a UX guy, you should care of what (and why) is shown on the face of the clock including the mobile version. A mobile-first approach is the key to do it properly, but if you cannot apply it, you need to think mobile when you create the desktop version at least. This is extremely important, because very often projects do not start with mobile from a business owner’s perspective. The factors that need to be considered here, are namely:
- Technology
- Device (with its technological possibilities and constraints)
- Mobile data connection (with its quantitative and speed possibilities and constraints)
- Mobile Usage Context
- User (with his/her needs on the go)
- Environment (sunlight etc., which is a non-user part of the mobile context).
“Mobile” as performance – addressing the device constraints
Every device is limited to a certain degree. It can become a very touchy topic when dealing with the mobile environment – with multiple brands and systems and devices equipped with different components. This leads to both hardware and software segmentation. Fortunately, the hardware diversity does not effect the web as much as mobile application development, but still, it is important to some extent. The operating system segmentation is more problematic. At the very threshold of 2014, we still face massive usage of Android 2.3 Gingerbread.
Addressing device limitations has one very depressing aspect – you cannot make the interface “contemporary and beyond” as much as you would like to. What looks great on your shiny new 5” mobile may perform poorly on older ones. You should, for example, avoid extensive usage of heavy javascript. Fortunately, the mainstream tends to be minimalistic and lightweight, and building mobile device agnostic interfaces is, at least, justifiable. After all, as mobile browsers do understand the aforementioned media queries, you can use them to gracefully degrade your design based on display features, plus add browser compliance detection through javascript.
Last, but not least – you should always consider the target group of your website – global stats may prove to be imperfect here.
“Mobile” as data usage – addressing data connection constraints
Eye-candy may play a different role in your design – allowing you to sometimes go minimal, whereas sometimes it doesn’t. Sometimes your site is heavily content-based. This is where mobile data connection becomes an important constraint. While some users have unlimited data plans, others don’t. Some of them live or work in places where network coverage is poor. Of course, you need to ask yourself, how many of them are affected with this limitation, but it’s always good to think about optimization.
Images are what usually make websites heavy. Downloading them may cause your site to load slowly in some situations, resulting in users drop. Scaling images may be not enough here. Alternative images for various screen resolutions let you save up a lot of quota, making the loading time shorter and thus making users more satisfied. These images can be predefined (e.g. several versions can be created upon uploading content images) or created on the fly thanks to RESS.
The whole idea behind RESS is going towards thin client model by shifting more processing needs from client to server. One of the services offering server-side image scaling is Sencha.io (formerly known as TinySrc). You can read more about RESS and find more about image scaling in this great article.
We should not forget about high-density displays, though. Serving high density images to make the site more aesthetically pleasant also affects devices with low resolution display. With help comes the srcset attribute, allowing the browser to be served with multiple versions of image: low and high resolution.
Javascript makes it possible to detect connection speed as well. Well, this is not going to be very accurate, but is fair enough to let the user see one or another version of a website, image set or tell the browser to use the low resolution image instead of the high density one.
Serving resized images to meet your screen is not the only thing you can do. You can still try to replace some images with CSS shapes or font shapes (Font Awesome is a great example).
Golden second and user experience of a semi-loaded site
Let me tell you one thing – I don’t believe in golden second, at least not literally. There are way too many factors to consider: information urgency, user interest, user knowledge about a weak internet connection and time utilization (e.g.while waiting for a bus etc.)
An interesting thing to consider is how the site performs while loading. Slow loading images may make some parts of the interface shift as the rest of the content is being downloaded. So having aimed at a button with his thumb, the user may actually tap something that half a second before was not there, going somewhere he/she did not intend to go. On the other hand, some scripts that are loaded too late may also severely limit the functionality of your mobile website, especially when that menu button simply does not work because the javascript has not yet been loaded.
Both of these can be resolved by properly planning content and script optimization and careful placement in your code.
“Mobile” as usage context
Adapting to a mobile device is one thing, but adapting to usage context is something beyond that. As a UX designer, you need to pay attention not only to how the site adapts to the screen, but also how it adapts to the user.
While on the go, user needs may differ from the ones when they are at work or at home. Very often it leads to severe limitation of website features in their mobile version, as well as adaptive content – but this is not the rule, as some sites make sense mainly or even only while on the go. Anyway, the difference may be so big that it may become hard (sometimes too hard) to keep it within the same code and causes dedicated mobile versions to be the best solution.
The other side of the coin is the actual environment in which the user accesses the mobile version of the site. Of course, he/she can do it at home, at work, when using public transport, on the street, in bright sunlight etc. So you need to make sure the design provides proper contrast and font size.
“Mobile” as coherence
The difference between the presentation layer and the mobile content make the mobile version of the website actually a semi-different channel, and it’s hard to say if it should be treated as a child of the desktop version or as a sibling. Most probably, this question is to be answered on project basis. Three more questions seem to be crucial here: how much of the desktop version should be “ported” to the mobile, should you go responsive or create a dedicated version and (in the second case) what to do with the redirections.
The first question is not very hard to answer in terms of methodology, but when it comes to analyzing the features, problems may appear. You need to know the mobile usage context, your users’ needs on the go and confront it with the value of your website. Often, graceful limitation of the features is necessary to provide optimal user experience on the go. However, you need to find the golden mean – the right balance between features you are going to provide versus the constraints to use them. Sometimes you can go parallel with the desktop version, but it also happens – especially in case of big, compound systems, that this becomes a utopia. So you actually need to limit the features altogether.
In case of more complex systems, when the decision about graceful limitation of features has been already made, you need to know how to do it properly. There are two ways to go here – either you keep it within the same code or not. And business-wise, this is a really important decision, as you need to consider not only the present state, but also the future of the system, with all the plan of further development, changes, evolution. Let’s say you decide to use the same code to maintain the mobile and desktop versions. You need to understand that with every change (especially if not planned, sometimes even: chaotic) the complexity of the code will increase, triggering a need for optimization after a bunch of changes like this (excepted only if it is perfectly planned and thus bullet-proof). And even if this approach is usually much praised, depending on how much the mobile site actually *is* the desktop one, just painted over, sometimes a dedicated, separate mobile version seems to be better choice.
If you finally decide to do a separate version of your website (often placing it on “m.” subdomain) you need to remember that neither accessing the desktop version on the mobile nor the other way around will be welcome for your users. So you need to consider smart redirection strategy, making it easy for your users to feel they are just in the right place every time they access the site from both desktop and mobile, and having in mind SEO aspects as well. One of the worst things to do is redirecting from desktop link to mobile homepage – it is very frustrating, bad UX approach, because the interesting page is lost on the way and users do not get what they actually came for.
Want to learn more?
If you’re interested in mobile UX, then taking the course on Mobile User Experience, which includes templates you can use in your own projects. If, on the other hand, you’d like to…
- learn all the details of Usability Testing
- get easy-to-use templates
- learn how to properly quantify the usability of a system/service/product/app/etc
- learn how to communicate the result to your management
… then consider to take the online course Conducting Usability Testing.
Lastly, if you want to brush up on the basics of UX and Usability, the online course on User Experience could provide you with the necessary knowledge. Good luck on your learning journey!
(Lead image: Depositphotos)
