In May 2010, Ethan Marcotte coined the term “responsive web design” in an article published on A List Apart. Now, just over 6 years later, it’s almost a given that any new website being produced will be built using responsive practices. The number of devices that people use to access the web is huge and ever-expanding, and responsive methodologies enable us to create good experiences for users across their vast array of machines.
Even as responsive practices were becoming de rigueur for website builds, native apps were - and of course still are - being built. But what about web apps that need to also be accessed on the desktop, as well as on mobile and tablet? One choice is to build an app AND a site, but that can lead to the issue of keeping two different sets of code and data in sync with each other. The other option is to build a responsive web app.
What does the user think?
Your app users may not even really think about the distinction between a web site and a web app. What they are concerned with is whether they can perform the task they need to do on the device they are using. Whether it’s reading an article, booking a trip or trying to learn more about a product or service they may want to buy, they just want to get the job done.
While we may be approaching our development as an app, with a focus on functionality, if it’s going to be a web app - built in the browser - the same guiding principles for responsive will apply as if we were building a traditional website.
- Design with content in mind - When at all possible, layout should be designed with real content in place, or at least an understanding of what the actual content will consist of. There’s nothing worse than designing with Lorem Ipsem and then having the design break down when the real content is ported in. Since many apps are going to be dealing with large data sets, this is especially important to consider.
- Determine your minimum display size - While content-heavy sites may all be adapted fairly easily to even very small screen sizes, some apps may contain content that cannot comfortably fit into smaller viewports, such as detailed imagery or very large tables. When building an app, it’s acceptable to suggest recommended minimum device size. You can’t control what device a user will use to access your web app, but you can warn them that the app is best viewed in a minimum screen size.
- Provide fallbacks when possible - You may not be able to guarantee the same experience on a small viewport as on larger ones, but you must do what you can to provide the best experience regardless. This may mean that not all functionality is available for small viewports, or it may be altered or adapted in such a way that it is still accessible, even if it isn’t exactly the same as when viewed on the desktop. One example could be to provide maximize or zoom functionality for larger images. Allow users to scroll through wide tables if they don’t legibly fit in a small screen the way they do on desktop.
- Keep an eye on performance - One thing native apps can have going for them is that they can work very efficiently on mobile devices. One thing responsive websites can have going against them is that the code can get very bloated very quickly. Remember that users of your app will using it to accomplish certain tasks, and while we all want our users to be delighted by the visual design and interactions, err on the side of snappy performance - your users will also be delighted if they can accomplish what they came to do with very little effort.
You know you’re building a web app, but your user has simply come to your app or site to get something done, and they’ll have a better time of it if the app works well in whatever device they have in front of them. At Cantina, we have proven experience delivering responsive websites and apps to more than a 40 enterprise clients over the past seven years. If you’re interested in learn more about how we deliver on similar projects, our customer stories are great resources to use.
Of course, you can always drop us a note at firstname.lastname@example.org if there is a question we can help with or a project we can collaborate on.