How to Convert a Non-Responsive Website into a Responsive Website

Author’s note: There are many articles and blogs floating around the InterWeb today that provide a technical response to this matter. These postings deal heavily with grid-based frameworks, breakpoints, media queries, CSS3, HTML5, etc. and are intended for a professional web industry audience. I will attempt to explain the process from a more practical, customer-centric and non-technical perspective. If you are a marketing manager or small business owner and find yourself tasked with taking your existing website and making it responsive I hope that this article will be useful.

The Coming of Responsive Web Design.

In 2013, Responsive Web Design became the defacto industry standard in web development. Responsive Web Design represents a new approach to building websites that optimizes the user experience across all platforms and mobile devices. If you own or manage a website it is imperative that you invest in the mobile user experience, and Responsive Web Design is the most complete solution to this complex problem. A typical business updates its web presence on a fairly predictable cycle. On average, a corporate website will last between 2-5 years before it’s time for an overhaul. In the market now? No problem. Any web developer worth its salt will propose that the new site be built using a responsive framework. If you are currently in discussions with a web agency and this is not the case I have only one thing to say to you: RUN, Forrest! RUN!

Houston, we have a problem.

All is well for site managers that fit within this cycle and are ready to build their new site from scratch using Responsive Web Design. Ideally, a responsive site should be built from scratch as the design and the framework both strongly influence how well the site adapts to different devices and screen sizes. But what about those poor unfortunate souls that somehow missed out on the responsive coronation? You have a shiny, new  (and most likely expensive) website that you took great pride in – at least prior to hearing about this new ‘responsive thingy’. You find yourself stuck with a web presence that was outdated and uncompetitive prior to it ever going live. And, perhaps worst of all, you did not plan for budgeting to fix the problem. What to do, what to do?

First off, DO NOT PANIC. Take solace in the fact that you are not alone. I receive several requests each week from managers in organizations large and small that are in this spot. There is a timely and cost-effective solution.

Transitioning into Responsive Design.

Let’s begin with the basic question that defines the problem: How can we convert an existing, non-responsive website into a responsive website?

Before we can begin to answer this question, we must determine what kind of website you currently have. Is your website driven dynamically by a content management system (CMS), such as WordPress, or is it a compilation of static, HTML pages? If you do not know the answer you will need to check with your IT staff or the original site developer as this is critical to the conversion process.

Now, to transition to a responsive design, we must:

    1. Assessment. To begin with the conversion process, we must first review the site design, layout and structure to ensure that it can fit within the responsive framework. This may require some tweaking of the original designs and layout, and not all sites are compatible for conversion.
    2. Information Architecture. Once we can confirm compatibility we will create interactive HTML wireframes that will demonstrate how the existing content will display for desktop, tablet and smartphones. The number of wireframes will vary by project and an understanding of user behavior via analytics will help us determine the types of mobile devices current site visitors are using. If, for whatever reason, you have a lot of users on Kindle Fire coming to your site (not that THIS will ever happen), we will need to ensure that the conversion takes this particular device into account.
    3. Design for Responsive. Next, we will rebuild the original design PSD’s templates to demonstrate the updated designs (based upon content and layout modifications required fro responsive conversion). As with the wireframes that precedes this step, we will provide design mockups for desktop, tablet and smartphone views. At this point, you will truly begin to see how your site will look and feel as a responsive website.
    4. HTML Prototypes. Once the design templates are approved, we go through the process of PSD2HTML, built upon a responsive framework (such as Bootstrap or Foundation).
    5. Convert the Code. We will then go through the tedious task of converting everything that was once fixed-with into a fluid, responsive layout. When moving from fixed layout to responsive design, we must establish “break points” that will trigger CSS style rules for different devices and screen sizes. Text is only one component of responsiveness. Due to the ever-increasing use of infographics, photos, and videos, images are also significant aspects of the responsive experience.
    6. Template Integration. As I have stated previously in this post, we must determine whether the existing site is static or dynamic. If the site is static, we will create responsive HTML template pages, which can be used in HTML editors such as Dreamweaver. Once these responsive templates have been introduced, the task of manually copying and pasting the existing content from each individual static page will begin. Based upon the number of pages the site has, this can either be a quick fix or a major headache. For dynamic sites, however, the solution is much more elegant. For website that use a CMS we need only replace the existing non-responsive HTML templates with the responsive HTML templates.
    7. Site Testing & QA. Finally, we will then test the converted site on multiple devices to ensure that everything is responding accordingly. The more you test your responsive site, the better the user experience will be in the end.

Although the solution is technical, the process of converting an existing non-responsive website to a responsive website, in practice, is more art than science. Each website is different and has its own unique challenges during the conversion process. For site owners like you, however, this means you no longer have to create a separate site for mobile users or make them suffer through an inferior mobile experience.

Have something to say? Leave A Comment Below.

Frank Farris

Frank Farris is Founder and CEO of DeepBlue. He has been an active thought leader in the application of emerging web technologies since 1998 and is a champion of the movement to make the Responsive Web Design approach the new industry standard.

More Posts - Website

Does Responsive Web Design Slow Down the Mobile Experience?

I am often asked whether or not responsive web design can slow down or sometimes simply degrade the user experience on mobile devices due to image file sizes and other technical challenges. The short answer is no, at least not if the website was built correctly. Let me explain…

For RWD Optimization we employ a “Progressive Enhancement” technique. Most companies that are not familiar with the inner workings of RWD tend to think that it’s a one size fits all approach. What we do is focus on enhancing the experience based on the capabilities of the browser/device. For example a small device would have a smaller/more optimized image presented vs a larger version that a desktop user will see. The way other companies do this is they will serve up the same image for desktop that they do on mobile. This kills both bandwidth and performance. To them Responsive is just about scaling content down. To us its about optimizing the experience for all users.

In general responsive web design, if applied correctly, can actually reduce load times.

Here are some optimization rules we may apply:

1. Images Optimization
The final aspect of Responsive Web Design is flexible images and media. Basically, this feature allows you to adapt your images or other media to load differently depending on the device, either by scaling or by using the CSS overflow properties. Scaling in CSS is pretty simple to implement for both images and video.

2. Media queries
Media queries are one of the cornerstones of Responsive Web Design. By adding some filter criteria around CSS definitions, we can control under which conditions those rules are applied to web pages. There are two places to define these criteria: using the media attribute of a link tag that references a CSS file or inline on a CSS file.

3. RWD Framework
We may use top RWD frameworks like Bootstrap, Foundation, Gumby Framework or HTML KickStart to organize the page structure.

4. Grid-Based Layouts
The grid layout helps define the size of content on any screen and can be used to define layout on different screen sizes. The Bootstrap, Foundation, Telerik Page Layout and other frameworks provide various sizes for their grid columns based on the size of the browser.

5. Minimizing HTTP requests
HTTP requests are sent to every device unless you tell it not to. JavaScript and CSS resources can help with this, such as Compass.
This is an open source CSS authoring framework that allows developers to create clean markup and create sprites and extensions simply and easily.

4 Enable Compression
We may apply JavaScript and CSS as compressed formats to speed up the loading.

5. Showing and Hiding Content / Conditional loading:
Not all content is intended for all browsers. In Responsive Web Design, this is the least technical design decision. What elements should appear on each of the page sizes? Not all devices need to display the entire website, nor should they. So we may apply some areas to hide on mobile devices that are not of significance to the mobile user.

 

Frank Farris

Frank Farris is Founder and CEO of DeepBlue. He has been an active thought leader in the application of emerging web technologies since 1998 and is a champion of the movement to make the Responsive Web Design approach the new industry standard.

More Posts - Website

Mobile-Friendly Website vs. Mobile Applications: No Monkeying Around

Although the two terms may intersect in many a new media dialogue they are as different as sharks and monkeys.

To paraphrase Socrates (poorly): I know that I know nothing. Yet, oddly, this makes me wiser than most. 

This statement is not made in some vain attempt to rectify the fact that the speed of technology moves faster than my feeble mind can possibly comprehend – rather, it is an acknowledgement that I am able to identify the 800-lb gorilla in the room when he is inspecting my head for fleas. We’ll call this great ape Steve Jobs.

The introduction of the iPhone, barely four years ago, changed everything. Not just in the way we communicate, how we navigate, how we interface, or how we accessorize, but in how we perceive the very nature of accessing information. The Web, as we know it, is dead. The ball-and-chain that we associate with the traditional PC/desk interface is becoming as antiquated a notion as television without DVR. Today, the Internet is mobile. It is truly free.

I am what you would call a serial early adopter. I was introduced to mobile browsing by my first “smart phone”, Motorola’s V200 Personal Communicator, which in 2002 was named Editor’s Choice by PC Magazine. Yes, it was a phone. Yes, it could send and receive text messages. Yes, it could handle email. And, YES, it could access the Net. My anticipation was that my long-sought dream of a mobile web would soon be realized. However, with its 2G speed, its tiny, monochrome, non-tactile display and text-only browser, the overall experience was less than nirvana. Today, my V200 sits in my drawer of misfit technologies, products that were perhaps a bit ahead of their time but failed to provide the killer app. My drawer is full of phones.

motorola device

Motorola described that its new technological marvel “combines advanced messaging and calling capabilities in a stylish, compact unit”

And then came Steve…

With today’s smartphones, including but not just limited to the iPhone, millions of us experience a rich user-interface and seamless access to the web and all its bounty – websites, movies, music, news, etc. Just take a look at some of the trending:

  • 63.2 million unique users in the US accessed news and information using a mobile device in January, 22.37 million did so on a daily basis.
  • Web access using mobile devices on a weekly basis grew 87% from 10.31 million to 19.28 million.
  • Monthly unique mobile web usage was up 71% from 36.87 million to 63.18 million since January of 2008.

But for many of us, the novelty of pulling up a website on a phone has worn off. For starters, smartphones don’t play Flash, making literally millions of websites absolutely useless for the mobile user. In addition, even websites that can be displayed properly on a mobile device lack a compelling mobile user experience as the size of the screen renders the content nay un-readable. Sure, the phones have their tricks – the double-tap was a great invention and a personal favorite of mine. However, the fact remains that these websites were designed for large monitors, using a keyboard and a mouse, and accessing them on a tiny device – no matter how high the resolution – leaves us frustrated and believing that there must be a better way.

Today’s modern web philosophy has seen the rise of alternative websites that are designed specifically for the dimensions and features of a mobile device. These “mobile-friendly” websites factor in size and usability to create page layouts that meet user’s needs quickly, show only essential information and make user input as simple as possible.

What is the difference between a Mobile-Friendly Website and a Mobile App?

I have experienced confusion of late with my customers in regards to the difference between a “mobile-friendly” website and a mobile app. Both are buzz words and both might seem to imply the same thing to the non-geek.

Allow me a moment to clarify their distinctions through rudimentary definitions:

Website

  • Website built for PC / Mac (enough said)

Mobile-Friendly Website

  • Website built specifically for mobile devices

Mobile App

  • Internet application that runs on smartphones and other mobile devices

Mobile Websites

When you’re building a website for viewing on a mobile device, you have to forget just about everything you know about traditional website development.

  • On a mobile device, screens are small. Because of that, you don’t want to display global navigation on every page as you would on a traditional site. For mobile devices, keep navigation links to a minimum.
  • Keep content to a minimum. Communicate only the most essential information.
  • Mobile device users are mainly interested in doing something. Strip away content that are research oriented, such as “About” and “Company History” pages.
  • Make sure every page has a “Back” button at the bottom, since mobile browsers typically don’t display one.
  • Don’t try to replicate the complicated design aesthetics of the main website – start from scratch and keep design to an artistic minimum.

Mobile Apps

Mobile apps aren’t websites at all – they are programs, human.

  • Apps are mobile software developed by using different platforms and programming languages based on the target mobile device.
  • Today, there are countless hundreds of thousands of mobile apps. Apple categorizes its Web apps as follows: Calculate, Entertainment, Games, News, Productivity, Search Tools, Social Networking, Sports, Travel, Utilities, Weather.
  • Usually task-specific – simpler, seeker services in favor of open, unfettered web
  • Less about the searching and more about the getting
  • True ‘Native’ apps do not require Internet access.
  • Content already downloaded to a smartphone can be instantly accessed. No waiting for web pages to download.
  • Can take advantage of a smartphone’s inherent technologies (eg, GPS, voice-recognition, touch screen, gyroscopes)
  • Create an omnipresent brand placement on a user’s smartphone desktop. Prime real estate.

When an organization is planning its Internet Marketing Strategy (IMS), it should strongly consider developing for all three platforms (website, mobile-friendly website, mobile app) so as not to neglect its current and/or potential users, regardless of where they are coming from. Although a mobile-friendly website and a mobile app may have features that are redundant, it is important to consider the differences we outlined above and determine how each can provide a unique and specialized user experience. For example, a college app might include a campus map, or a fast food franchise might include a location finder that locates the nearest chain via the smartphone’s GPS capabilities. Both of these features can be replicated on either a standard website or a mobile-friendly website; however, the benefits of these applications running on a native platform – not from an HTML web page running on a remote server – are significant in terms of time and ease of use. Think of the difference between watching a movie on DVD and streaming it online. Plus, having your app residing on the desktop of your user’s cell phone provides a one touch convenience that will ensure a satisfactory experience and encourage multiple uses – perfect for that moment when the mood strikes for a triple-decker caribou slider.  Proactive marketers can push the envelope even further by ‘pushing’ a message about that slider out to a user when he or she is in a geographically close proximity, thus actually creating the mood. This is something that only an app can do.

One potential down-side of mobile apps is Interoperability – the ability of software to function on multiple platforms – versus User Experience – the optimization of software to function at its highest degree on a specialized platform. Take an iPhone app for example. It must be programmed in the iPhone’s native platform, Objective C. Unlike a mobile-friendly website that will work on any smartphone, a native app built for an iPhone will not work on any other phone, thus eliminating about 70% of current smart devices. In order to cover the breadth of the smartphone market, therefore, one must build individual apps for the iPhone, Android phones, Blackberry, Windows Mobile, and Palm platforms. This can be time-consuming and expensive.

smartphone marketshare diagram

smartphone marketshare diagram

While the Android OS has overtaken Apple (iOS) in market share the two combine for almost 80% of the total market.

However, given the dominance of the iPhone and Android phones, an organization can cover roughly 80% of the smartphone market simply by building on these two platforms. An emerging option for complete Interoperability is to develop what has been coined HTML5 Apps, which have one single core application, are written with web standards, primarily HTML, CSS, and JavaScript and are deployed on more than one mobile platform. More on that later.

Regardless of whether you are an iPhone, Android or Blackberry user, these issues should be given strong consideration. Do the research and see what types of devices your customers are using. For example, if they are government employees, they most assuredly will have a Blackberry. Technical people may favor the Android platform due to its open source while creative people tend to fall in with the Apple-lovers crowd.

So, which platform is right for you? In addition to your website –  and its not inconsequential costs – do you need to invest in both (mobile web and mobile app) or should you hold back? Our belief is absolute that, regardless of whether or not you have a mobile-friendly website and/or a mobile app, you must have a mobile PRESENCE going forward. Not later. Not next year. NOW. Because, just today, consider that about 20% of people visiting your website are doing so from their cell phone, and that number is growing exponentially. And if your organization invests the time and research to learn about the inherent qualities of each emerging platform and how they can better serve your existing and potential users, you will find yourself at the cutting edge and in a competitive advantage over those that are trying to eat you.

Thanks, Steve. Have a banana.

Frank Farris

Frank Farris is Founder and CEO of DeepBlue. He has been an active thought leader in the application of emerging web technologies since 1998 and is a champion of the movement to make the Responsive Web Design approach the new industry standard.

More Posts - Website

Responsive vs. Adaptive Design: Which Approach is Best?

Those of us in the web industry have become familiar in 2012 with a new approach to website development. Responsive Web Design, or RWD for short. The promise of RWD is that it allows developers like DeepBlue to create a website from a single-data source and adjust its layout accordingly to provide an optimal viewing experience – easy reading and navigation with a minimum of resizing, panning, and scrolling – across a wide range of devices (from desktop computer monitors to tablets to mobile phones). RWD provides an elegant solution for a complex problem – how to develop a single website that satisfies today’s multi-platform consumer. RWD is not a new technology; rather, it is a new way of thinking about the web. Although a website built using a responsive approach is self-evident when pointed out, we have found that the term creates much confusion with customers, hence the purpose of this article. To try to clarify, we will define the two main design approaches to modern website development – Responsive Design and Adaptive Design – and allow the reader to decide for themselves which approach is right for them.

Let’s begin with the basics:

Responsive Web DesignMultiple Fluid Grids

Adaptive Web DesignMultiple Fixed With Layouts

Confused? I don’t blame you.

RWD uses something with the obscure concept of fluid-based proportion grids. Instead of designing a layout based on rigid pixels or arbitrary percentage values, a fluid grid is more carefully designed in terms of proportions. This way, when a layout is squeezed onto a tiny mobile device or stretched across a huge screen, all of the elements in the layout will resize their widths in relation to one another. In addition RWD uses flexible images, and media queries, and when all three components are combined we create a quality experience for users no matter how large (or small) their display.

Make sense?

Let me try to put this in simpler terms: RWD websites are like silly putty, they have the ability to bend and curb, essentially morphing themselves into the proper dimensions for any web experience, including desktop, tablets and smartphones. For those of you who remember the 1996 Summer Olympics in Atlanta – think Whatizit, just without all the horrible embarrassment it befell onto our fair city.

Olympics Logo

Got it? Good. Let’s move on.

Adaptive Web Design (AWD), on the other hand uses a fixed width layout in designing and developing a website. Instead of a responsive site that will adjust itself accordingly, the AWD approach is to create multiple versions of a website based upon its anticipated use. We used this approach for the Tennessee Aquarium website several years back. At that time, the iPhone had just made its glorious appearance onto the scene and users were excited about the ability to visit actual websites on their phone. Granted, of course, that the experience was not always optimal – I will not even mention Flash – we loved the fact that the geniuses at Apple were thoughtful enough to create an intuitive, gesture-based interface which allowed us to zoom in and out, making it possible to read content that was designed for a larger screen on our tiny 3.5 inch phone. For the time being, it was good enough. Soon, however, customers started complaining to us that their customers were complaining to them that their website was not very useful on their smaller devices. They asked us if we could create an alternative version of their website, designed specifically for small screens, squinty eyes and fat fingers. Witness the birth of the mobile-friendly website experience – a scaled back, dumbed down, easier to use version of what has become affectionately known across small screens everywhere as the ‘full site’. Even though the creation of a mobile version required additional cost, design, development and the creation of a sub-folder inside the CMS (thus duplicating content entry efforts), our customers were once again happy because, indeed, their customers were also happy.

Between the years 2006-2010, the Adaptive Web approach dominated mobile strategies. Essentially, we developed two websites – one for the desktop experience and one for the smartphone experience. Then, wouldn’t you know it, those geniuses at Apple introduced yet another disruptive product. The iPad. What exactly was the iPad? At the time, we were not quite sure. It wasn’t a laptop, yet it wasn’t a phone either. It was a brand new category. Inevitably, our customers started calling us asking about how we can help them optimize their tablet experience. Although the average website will default to its desktop version on a tablet, the content was not always an ideal fit, especially in portrait mode. Should we really build a third website that was optimized for tablets? Will customers actually pay for three websites? Things started to get a little murky, and that’s when we started hearing about yet another rumored device that would strike fear in the heart of designers – the iPad Mini!! Chaos ensued.

It all started to change with Responsive Web Design, an article by Ethan Marcotte on A List Apart. Essentially, the article proposed addressing the ever-changing landscape of devices, browsers, screen sizes and orientations using what you are now familiar with (thanks to this article) as the Responsive Design approach. RWD is still in it’s infancy and best-practices are being established as I write this article. It is by no means flawless – the concept of pixel-perfect has been thrown out the window along with Flash architecture. But it does represent the single greatest hope for a portable web that works the way we expect it to.

Earlier in this article, I offered to clarify the differences between RWD and AWD and allow you, the reader, to decide for yourself which approach is best for you and your organization. I realize that my intentions for objectivity may have been slightly influenced by my obvious subjectivity and preference for RWD. Still, I leave the ultimate conclusion to be made by you. If you were undertaking a new website, which approach would you choose?

RWD Rules!

Frank Farris

Frank Farris is Founder and CEO of DeepBlue. He has been an active thought leader in the application of emerging web technologies since 1998 and is a champion of the movement to make the Responsive Web Design approach the new industry standard.

More Posts - Website