Monthly Archives: July 2013

Standard

Posted by

Posted on

July 12, 2013

Posted under

Uncategorized

Comments

Leave a comment

Responsive website design

Kamila Mielczarek

1. Introduction

An increasing number of people use their smartphones or tablets to access the internet. The number of different devices used by each user to connect to the Internet also grows (Mintel, 2012). Therefore, it is vital for the designers and developers (website creators) to decide how the website would deal with the range of the screens and devices. It is very often a question of whether to create dedicated desktop and mobile versions or a unified, responsive website.

As website creators need to cater for a whole spectrum of screen sizes, it seems they have no choice but to recognise the differences between the traditional and the responsive website design (RWD) approaches. This essay will attempt to answer this question.

2. Description and definitions

There are many definitions of responsive website design. The device-agnostic responsive design means that the website’s layout and design responsively adapt to the size, platform (i.e. operating system) and orientation of the screen of the device (Knight, 2011). Responsive website is meant to recognise the size of the device it is viewed on and respond to it in order to provide the optimal viewing experience. It might be done through rearranging certain elements on the page, enlarging or decreasing images or fonts or even disabling some elements (Fox, 2012, and Gardner, 2011).

On the other hand, there is a traditional approach, which is about implementing device specific versions for each device. For instance there would be separate versions of the site for desktop and mobile screens. This approach is less flexible in use, but sometimes might be more appropriate (Fox, 2012, and Gardner, 2011).

3. The choice to make.

While a lot of people focus on the responsive website design and almost praise it based on its benefits (Joly, 2012), little work has shown the disadvantages or limitations of this approach. Although so many web creators are very excited with this relatively new concept (Chowdhary, 2012, and Frain, 2012), not all of them have actually adapted it successfully. In fact, the first and the most important question web creators should ask themselves is whether or not the responsive design is the appropriate solution for their needs.

3.1. Speed and performance issues.

As Podjarny (2012, p.102-103) argues, responsive website design can introduce some serious performance issues. By testing 347 responsive sites, he came to the following conclusion: “86% of the websites weighed roughly the same when loaded in the smallest window, compared to the largest one”. It indicates that, while the website on the desktop will be loaded relatively fast, mobile users might suffer in this aspect, as their devices are not capable of processing large files as fast. This seems like a big obstacle to the RWD concept.

3.1.1. The problems with flexible images

Flexible images are often used on responsive websites. The technique used CSS3 media queries to stretch or squeeze the images according to space available. Therefore, on a mobile screen the image would be resized to take less precious space.

As Podjarny argues (2012, p.102-103) when flexible images are applied, the large image files would still be downloaded on mobile devices. This meant that, as perfect as the concept might seem, it can actually break the user experience if not implemented correctly.

While this thinking seems logic, other sources (CSS-Tricks, 2012) mention remedies to that problem, such as using Foresight.js and HiSRC tools to test for the bandwidth before serving images and based on that, choosing the image size to display on the website.

It is also recommended (Kadlec, 2012) to selectively choose the image size to be loaded based on the screen size, which can be taken one step forward by compressing the images for different devices. The process could be also improved by using sprite images that combine many images into one and therefore reduce the size even more effectively (Gardner, 2011).

3.1.2. Complexity

While device-agnostic RWD approach seems like a lot of extra work for the web creators to make it right, it is still arguably a better solution to the problem (Marcotte, 2010). What is there to prove that the device-specific approach is easier to implement? By using RWD to build their sites, web creators no longer need to think about the whole variety of mobile and tablet and desktop devices. The design should work exactly the same on the iPhone as it would on Android devices with minor only differences in layout. In RWD, it is the size of the screen that determines the layout and content of the website (Gardner, 2011), but the content only needs to be written once.

Podjarny (2012) also mentions that hiding the elements with display:none CSS style does not mean that the code will not still be loaded. Why limit ourselves to using it? It can be better implemented by serving device specific CSS based on media queries. Media queries would determine the device’s screen size and orientation and serve a dedicated CSS or image files based on that (Frain, 2012, and Kadlec, 2012).

3.1.3. Misleading guidelines

There are articles that praise the RWD approaches for the ease of use and speed of implementation (Chowdhary, 2012). They mainly focus on the fact that the responsive website design focuses on the content, but they are overseeing the good practices in order to achieve good results, such as a site that would load fast on a mobile device (Gardner, 2011). What they see is just the pure concept and not its implications, mentioned above.

Web creators need to remember that those guidelines do not always paint the whole picture and they should look for a variety of sources, pointing out the positive as well as negative sides of the RWD and use their own expertise to judge whether or not the guidelines are appropriate in each case.

All this leads to a very important point of the responsive website design, which is “content is key” and “mobile first”.

3.2. Content is key

“Content first” is mentioned in almost every article about RWD. It means that the web creator needs to first determine the core content for the website. They need to determine what is crucial and start with just those key elements (Podjarny, 2012, and Frain, 2012). A very good example of the project that was really beneficial from this approach is the library project described by Fox (2012).

Once the web creators decided on the core content, they should gradually build on that and add more features and content as the screen size progresses (Podjarny, 2012, Frain, 2012, and Fox, 2012). This enables the users of the smallest devices, such as mobiles to access the main information of the website without slowing the devices down. On the other hand, the desktop user is enabled to see a much richer version of the website.

Because “content is key” rule usually means developing the website for the mobile devices first, it is often referred to as “mobile first”.

3.2.1. Implications

The “mobile first” is an opposite of the commonly used approach, which would first cater for the needs of the desktop users and then focus on satisfying the needs of the smaller device users. Therefore, it requires changing one’s way of thinking, as it contradicts the ways in which web design has been done in the past. This might cause delays in the project, as the web creators re-organise their thinking.

3.3. Functionality

Apart from the key content, it is very advisable to decide about the functionality of the website early (Fox, 2012, and Frain, 2012). Provided that the mobile, tablet and desktop versions will offer the same functionality, then RWD could be implemented.

On the other hand, the mobile version might offer some additional features, such as built in maps (Frain, 2012) or that the desktop version features might be incompatible with other devices (for example, Flash is not supported on iOS devices). It would not make much sense to implement RWD in this case, as it would mean that either the mobile version would not function properly or it could be a lot of work and resources to actually “hide” the feature from the unsupported devices.

Therefore, it may be argued that specific mobile versions might be best in certain circumstances. The traditional approach would be viable provided there are different requirements for a mobile than for a desktop version.

3.3.1. Experience

Is this thinking right? Based on experience (of the author) this statement is correct. It proved to be, on one of the maintained websites during work experience. The Flash tool was not working on an iPad tablet. Therefore, it was agreed that the incompatible part of the website should be hidden on tablet devices. This, unfortunately, did not serve its purpose well, as the content of the website has been updated on a monthly basis and the links to the tool were constantly changing place, causing it difficult to track and hide the tool. Furthermore, the content was updated by various people, making it even more difficult to track.

3.3.2. Solution

In the above case, a tablet specific version of the website might have been a better solution and improved the user experience. On the other hand, a responsive website would have been even more costly to maintain, as the design would need to be constantly reviewed on a monthly basis. The scope as well as the usage of the maintained website on tablet devices was relatively small compared to other websites maintained by the company, making it even less feasible to change. If the website’s traffic was higher or if it produced higher profits, it would have been wise to invest the time and resources into making it response to the device’s screen size.

On the contrary, if a website’s functionality did not differ across devices, it would be advisable to apply responsive design (Frain, 2012). This would mean that no matter which device the website was viewed on, it would always serve the most important principle of the RWD – the content is key. This aspect of responsive design gives the users the freedom of choice. And no matter what their chosen device would be, they will always access the most relevant content of a given website without worrying that they might miss something.

It would also remove the element of confusion – as the user is switching between the different devices. As already mentioned, the majority of the Internet users use at least one method of accessing the Internet. Therefore, by accepting and adapting to this trend, web creators can enhance user experience by allowing an almost seamless transition between the devices.

4. The conclusion.

One could draw from this experience that functionality plays an important role, when it comes to deciding whether or not to use RWD. The choice depends on various factors, such as the differences of content to be served across devices, the feasibility of adapting the website, such as time and resource constraints and even the number of people involved in maintaining the website.

Responsive website design has many advantages as well as weaknesses. It would be best used if the website was intended for a range of devices and the performance and loading time were not the primary concerns, although there was enough time to implement the RWD in such a way to not adversely affect them. Alternatively, it would be appropriate when the website was of as small size, which would still allow it to be loaded relatively quickly on a less capable device, such as mobile.

RWD also means that the web creator would have less code to maintain compared to multiple dedicated versions. The exception would be the initial set up of the required frameworks (i.e. the aforementioned Foresight.js) as well as selective choice of appropriate image sizes based on the screen size.

On the other hand, device specific versions would be a better solution for websites that have very specific functionality only either to a desktop, mobile, tablet device or even to all of those.

The most basic question to answer is whether or not the website needs to be responsive and is it worth making it so. The approach has certain benefits as well as the drawbacks and they need to be weighed carefully in order to determine whether to use the responsive web design or rather code for the specific devices.

This paper does not cover all of the implications of the device-agnostic responsive design. It is recommended to seek further information on issues, such as: browser compatibility, HTML5, choice of media queries techniques, approaches with flexible images and so on.

References