Mashable declared 2013 as the Year of Responsive Web Design
, so it felt an appropriate time to investigate updating Red Gate’s browser based products for phone and tablet. We wanted to know if and how we could make the in-browser user experience better without needing to invest in writing separate mobile applications yet. So we hatched a plan: We had 5 days, one Developer, one User Experience Specialist and a bucket-load of ideas…
What is Responsive Web Design?
The idea behind responsive (also known as adaptive) web design is to optimize the user experience for all device formats including phone, tablet and desktop. This throws up a ton of challenges:
Getting the [right] information to fit.
Phone or tablet’s physically smaller display size can represent a huge challenge in displaying the breadth of information used on desktop screens. We preferred to view this as an opportunity: Do we really need all this content? Is this content really valuable for the phone or tablet use cases?
Designing for higher pixel densities.
Though the screen on mobile devices has a smaller physical size compared to desktop hardware, they also have a higher pixel density, measured in pixels per inch (ppi). The upshot is that you can no longer rely on absolute pixel sizes to guarantee that your web site or application looks the same on all devices.
Designing for touch.
Pixel densities of iPhone5 and Samsung Galaxy S4 phones
The display size and pixel densities vary between the devices you use, but your fingers stay the same size. It is crucial to design for selection by touch: UI elements in close proximity may work OK when selected with a mouse on desktop, but can become frustratingly fiddly to select on touch devices. Interactions like hover states to disclose information do not translate to touch either.
. Smartphones are getting faster, but slow connection speeds and volatile connections still remain a problem. We should tailor the content to the device and context of use to maximize performance. Luke Wroblewski illustrates the problem well:
“Most of poor performance is our fault: the average page in 2013 weighs 1.4MB. The average load time of a top 2000 site is 6 to 10 seconds…86% of responsive designs send the same assets to all devices.”
Why design responsive web applications?
Just take a look at the worldwide hardware sales for Q1 2013:
- PC sales are down year on year by 13.9% to 76.3 million units [source IDC]
- Tablet sales are up year on year by 142.4% to 49.2 million units [source IDC]
- Smartphone sales are up year on year by 70% to 210 million units [source Gartner]
For Red Gate this means that though we still expect the users of our tools to continue to use the Windows desktop platform, there are opportunities to introduce new products and services into the mix and an increasing expectation that existing web applications will work effectively on phone and tablet.
The mobile context doesn’t necessary mean that we’d expect you to deploy your applications whilst in the coffee shop; it’s the convenience of a small format device that means checking the status of monitored servers or backups is a quick and easy activity whilst you are doing something else.
We needed a product to work on, so we chose Red Gate Deployment Manager
, an automated deployment tool for ASP.NET and SQL Server applications. This web application is not currently responsive and has a few interaction challenges that needed to be solved:
- To view the web application on mobile required the user to pan excessively. The worst case was the deployment dashboard grid
- Hover interactions were commonly used to display deployment and environment success/failure information and the project selection list
- The application uses data tables to display information for variables. We need a way to get the tables to display well on phone and tablet
Time was short. A usable working prototype needed to be created within the week so we could do user testing. We needed a plan and to validate it fast. The solution was to build prototypes of increasing fidelity and complexity and to test at every opportunity. To build an interactive prototype we selected Twitter Bootstrap
, because of its comprehensive set of web tools and we’d already had some experience with it. Here is how we got started:
Step 1: Lo-Fi paper prototypes
Day 1: The first step was to print out pages from Deployment Manager and get the scissors out. Cutting up the page content gave a fast, fluid and collaborative way of changing the information architecture on these pages; to group elements in better ways and then experiment with how the layout would change for phone, tablet and desktop. The first morning was spent working out how to lay the pages out, sticking them down to preserve the layout and get some feedback from colleagues.
Lo-Fi prototypes: UI was cut up and assembled into new layouts
We learned at this stage of testing that we could make some core workflows more intuitive and discoverable by consolidating information into fewer pages.
Step 2: Hi-Fi paper prototypes
Day 2: Using the feedback from the Lo-Fi mock-ups the next step was to create higher fidelity prototypes taking advantage of Bootstrap’s 12 column grid.
To create higher fidelity mock-ups the grid was drawn using guides in Adobe Illustrator. This was done for phone and desktop then the UI components were blocked out within the columns. These were not fully styled presentations, just gray-scale layouts to the correct grid size so the proportion and font sizes could be evaluated.
Once these had been created the phone layouts they were printed out and cut into strips. By inserting these into a cardboard mock-up of an iPhone we got some internal user feedback about the navigation, layout and scrolling.
Higher Fidelity paper prototypes
We learned from the tests at this stage that the main navigation was flawed (too small, not scalable) and we needed to refine the log-in UI on phone.
Step 3: Interactive prototypes
The first page to be created was the dashboard. This page displays the deployment statuses for each project and environment in a grid (see below left). The plan was to make the grid of deployments turn into a list when on phone. This proved to be pretty easy by using <row-fluid>
, which uses percentages rather than absolute pixel sizes for the column widths, and setting <span> widths to get the desired layout and behaviour (see below right).
Dashboard layout on tablet (left) and phone (right)
Next to be worked on was the release settings pages. These were a challenge due to their use of tables, which do not display well on a phone. For these we experimented with FooTable
, a jQuery plugin to make HTML tables responsive. This gives the ability to take the full table display (see below left) ,hide columns on phone and make the cells expandable to show the hidden data (see below right).
Examples of FooTable layouts for tablet (left) and phone (right)
Though we started out creating a static prototype, we soon discovered that we wanted to go further but we did not want the overhead of merging in the existing back-end code yet. A tip-off from a colleague led us to Knockout js
which allowed us to quickly create custom bindings, which made the user tests feel more dynamic.
Once we had created these pages we tested on iPad and Phones. The results were very promising and we got a lot of valuable feedback about the changes and how we could improve the designs.
So what did we learn?
- Iterating the design quickly through a series of prototypes of increasing fidelity saved a huge amount of time and gave us the confidence we were on the right path before writing code.
- Phone format paper prototypes that users could hold in their hand helped illicit a lot of valuable feedback about how and when they would use this web application.
- The design exercise made us question the web application’s content. This resulted in better layouts, simplified navigation, fewer UI patterns, more concise text strings and tailoring the content for phone and tablet.
- Bootstrap’s out-of-the-box 12 column grid was too restrictive on desktop for the dashboard page. We would consider using a 16 column layout and full width in production builds.
- UX prototyping directly in HTML proved to be far more efficient than creating wireframes.
- We could test ideas and iterate the designs so much faster
- We were able to observe the responsive nature of the design
- Nothing was “lost in translation” between UX and Development. We just handed them the HTML and CSS files.