My article about Responsive Design was recently published by the international trade publication, The Software Developers Journal. The SDJ is read by thousands of technical people around the world but my article was written from the perspective of a lay person in the industry. This is part two of our article. You can read part 1 here. Drop me an email if you would like a copy of the entire publication at gary@lwebg.com!
I've posted the article on our website for you to review! It's not hypertechnical, so have a look and enjoy!
Three Categories of Mobile Web
Mobile Web falls into three categories. The first is a mobile website. A mobile website is a custom mobile site that has been built specifically for mobile viewers. We write a snippet of code that resolves to the mobile website when a mobile device is detected. The downside of custom mobile sites is that each site is independent of the other, including the domain name. If you want to change information on one, you have to go into the other and make the same change or the two will lose consistency. This also presents problems with SEO. Google search doesn’t like to see duplicate content and you have to have duplicate content since each of the two websites are supposed to be identical, or close to it.
Mobile, or Native apps are programs designed specifically for each mobile operating system and they are usually downloaded through an app store. These apps reside on the device and can run without an Internet connection. There are specific business cases where a native app would be considered appropriate and that would be a single action that you want people to interact with online. Or if there is value to be added in what an app can do that a site cannot. In many cases, the main use case for Flash (more interactive applications) is being replaced with native mobile applications. What many organizations used to do with Flash, they are now doing with mobile apps. An example of a situation where an app might be a better choice would be for a flash card study program for someone who sells textbooks.
If you have a native app, Apple puts you on the app store and that’s pretty cool. But an app isn’t a website – apps are tools that enable a user to do something very specific. So it really just depends on what the needs of the client are and what his/her goals are. Plus, the cost can get crazy – thousands of dollars for one and you have to get one for each mobile computing platform, Apple, Windows 8, Blackberry (if RIM survives this latest failed effort, which is highly questionable) and Android.
Whatever your app is, it cannot be a true replacement for your mobile site. You're link shared on Facebook, you're link shared on Twitter. Those links will not open your app. They will open your website, and you don’t want to scare people off by giving them an app that doesn't work. The Facebook app is currently one of the top 50 most downloaded apps in the Apple App Store, and is #4 under social networking. Even so, according to Facebook’s James Pearce and Gomakethings.com, they receive traffic from 7,000 devices a day via the mobile web and they get more traffic through their mobile HTML5 website than from their Apple and Android apps combined.
There isn’t anything wrong with having a separate mobile website as opposed to a responsive site – that’s a legitimate way to do it. But Google recommends you not have a separate website domain because it can hurt SEO and its also two different websites you have to manage. And you also have to deal with duplicate content issues.
Google recommends responsively designed websites because:
• “Using a single URL for a piece of content makes it easier for your users to interact with, share, and link to your content, and a single URL for the content helps Google’s algorithms assign the indexing properties for the content.
• No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience.
• It saves resources for both your site and Google’s crawlers. For responsive web design pages, any Googlebot user agents needs to crawl your pages once, as opposed to crawling multiple times with different user agents, to retrieve your content. This improvement in crawling efficiency can indirectly help Google index more of the site’s contents and keep it appropriately fresh.”
Is There A Downside to Responsive Design?
There is a downside to just about anything, including Responsive Design. But the only downside I have yet to see is the cost. It can be expensive, if you want to do it right. And if it isn’t done right and people don’t really understand how to implement it and if they ignore the main key, which is progressive enhancement, then the desktop version of the website can look pretty bland because the site is focused on mobile, or the mobile version of the website can look bland because everything is focused on the desktop version.
Progressive enhancement is part of our Mobile First approach and represents the technique of gradually improving the experience as more capabilities are added. So in the case of Mobile First progressive enhancement, as viewers move from a smaller screen to a larger screen, they can see more and do more.
According to the WC3, an alternative to progressive enhancement is “graceful degradation”, where the desktop version serves as the baseline and the user experience decreases gradually as the screen size decreases, but it does so “gracefully”. I’m sure that some developer in tech heaven is getting a good laugh at that one.
The WC3 author states his distaste for graceful degradation, but accepts that this approach can be viable in some situations:
• You retrofit an old product and you don’t have the time, access or insight to change or replace it.
• You just don’t have time to finish a product with full progressive enhancement (often a sign of bad planning or running out of budget).
• The product you have is an edge case, for example very high traffic sites where every millisecond of performance means a difference of millions of dollars.
• Your product by definition is so dependent on scripting that it makes more sense to maintain a “basic” version rather than enhancing one (Maps, email clients, feed readers).
The design aspect of responsive design is more time consuming because there is more artwork needed. We do our wireframes first and sometimes we go ahead and do a full home page mockup so we can get our bearings and get a better understanding of the overall visual direction we want to go in. But then we go right back to mobile. We will employ some of the desktop concepts to ensure the right continuity and gain a fuller understanding of the visual hierarchy. But our philosophy is “mobile first” and that’s always where we start.
A lot of people these days are using style tiles which helps them lay out the visual elements and the overall style of the site that can be carried over from mobile to tablet to desktop. They can help with some clients, but our clients seem to prefer seeing what it is going to actually look like. You need a more technologically sophisticated and educated client before you can pull that off. There are some other things you can do but we generally employ the more traditional back and forth creative process depending on the client. Every client’s needs and expectations are different so the process we follow is a little bit different for each one as well.
We still do mockups in Photoshop but as opposed to a standard website where you might have four different page mockups, in a responsively designed website, you’re talking about as many as 12 different mockups for the same website, if you continued with the old traditional approach. There’s exponentially more work involved in building a website in responsive.
That is where style tiles are for…so you don’t have to do so many mockups. But they haven’t worked very well with our clients. So we still do a few mockups – home page for the desktop, the tablet and for the phone, then we create mockups for each individual break point, wherever we think it will look the best. But once you get one page down, a lot of how the visual hierarchy works and how things are going to move based on the screen size, then a lot of that carries over into a lot of other things.
But for truly unique pages that are important for the goals of the website, we design a mockup for each primary screen size. Generally the mobile mockups don’t require as much time after the visual hierarchy is determined and the content architecture is already established.
The Importance of Content Architecture
Our first step in the creative process is to determine the new website’s Content Architecture. Content Architecture (CA) describes the information the website will contain and defines the way that information will be presented to the viewer. If I am working with a client to define his/her CA, input should be gathered from multiple sources both in the company and outside. In the case of a lighting company, the company president knows which products and services offered are the most important. Operations can tell you what products need to be sold because of high inventory and accounting knows which products are the most profitable. Sales knows what customers ask about the most and then which product they end up purchasing and what motivated them to make that purchase, or what product motivated them to come to the store.
Outside sales or the customers themselves can provide an excellent resource because they know how the most important or most popular products are described in layman’s terms. This information plays an important role in future SEO efforts.
If you are working for a company that sells fishing equipment, you need to know how actual customers describe the product they are seeking to buy before you can build a website that is profitable for your customer. And in the case of multi-location businesses, you need to know what products are popular in the areas in which the locations are situated. A tackle store on the Florida coast might not be the best place to emphasize trout flies.
Once the CA is completed, it’s important to point out that it doesn’t have to be set in stone, but it can be tweaked. And then you can allow the design to inform on the Content Architecture instead of always allowing the CA to inform on the design. After the CA is done, designs are all approved and the CSS is complete, then we start converting into the Drupal theme. Our firm uses Compass and SASS and a framework called Susy to help with the responsive aspect. Susy is not an overbearing framework – it does the math for you, giving you almost total control. And it’s a Mobile First Framework.
So we start first with the mobile styles first on the CSS and then next we do the tablet. And when we go to the desktop, it usually has less styles than the mobile or tablet versions. We use SASS and Compass because it makes our job faster and easier. So if a lot of the traditional CSS syntax is lacking, SASS makes up for it. It compiles to straight CSS anyway. It makes writing it a whole lot easier and a whole lot faster.
Drupal’s Role
We like using Drupal. We like it a lot! And while Drupal has made some great strides in handling responsive websites, there are still going to be challenges and the most common challenge is what to do with loading images of various sizes. The poor man’s way of handling images in responsive is just to resize them in CSS or just hide them. But the image still has to be loaded. After that, they’re just hidden and you’re still forcing the mobile user to use all that wasted bandwidth.
Drupal has made some pretty good strides towards the image handling issue. Recently we implemented the latest modules to help handle that so, based on the screen size or breakpoint, we can load a certain size image. We can load a smaller sized image for tablet and then another even smaller image for mobile phones. Or if we don’t want to show the image at all we just don’t load an image, or we can load a 1px x 1px image and then hide that. It’s very straightforward to set up.
That feature is going to be out-of-the-box in Drupal 8, and the new version will also have a native administration theme that is responsive, so the site can truly be managed from anywhere. Also in Drupal 8, we’ll have a lot more control over individual element caching, to make it easier to control individual blocks on the page or individual elements. To cache some and not others, or to show some and not others based on certain criteria. It is going to have a lot more granular control over the content that is shown based on the context of the user. This allows us more flexibility when trying to give mobile users the best performance possible.
Summary
If my company is to be successful, we have to continue embracing mobile technology and keep a close eye on the trends, in hopes that we can continue to make the good decisions and keep the bad decisions to a minimum.
These are exciting times to be in the Web business, with Social Media, Mobile, SEO and Ecommerce continuing to grow and evolve. The coolest part is that there are new, incredibly awesome things coming our way just beyond the horizon and I look forward to meeting you there!
About the Author
Gary Rawlings, CEO of Louisville Web Group in Louisville, KY USA, has served in the Web development industry since 1998. A native of Danville, Kentucky and a graduate of the University of Kentucky, Rawlings and his Web team have developed several hundred websites over the years and they have extensive experience in Web design, SEO, eCommerce development and mobile development, employing the Drupal platform. A former journalist, Rawlings personally handles SEO and content development for the firm, in addition to his administrative duties.Rawlings and his wife, Sande, live in Crestwood, Kentucky, with their son, three dogs and two cats.
