The Responsive Unknown: Introduction
At this point, if you’re a web designer, responsive design should be a tool on the belt that you are rather comfortable with. Many of us have transitioned to a “responsive by default” sort of approach, treating it as the new normal. Why? Well the browser support is there. Where there isn’t browser support we have great tools like HTML5 Shiv (or Modernizr) to get our backs. What’s more is we are starting to reach a critical mass in wonderful example sites. Not just the personal blogs and design agency redesigns we see on galleries like mediaqueri.es but meaningful execution like the Boston Globe or the new Microsoft design.
So if responsive design is going to be our new default approach, it’s important that we start to explore ways to improve our project efficiency. This is nothing new for designers. We have been mastering the art of recycling for quite some time now. Pattern libraries have long been standard for companies or agencies, grid systems help us speed up layouts, barebones themes get us kicked off with CMS projects and projects like HTML5 Boilerplate save a surprising amount of time with simple assistance in building a good reset and starting point for any project.
Some of these tools can be carried with us to the responsive promised land but others are doomed to be left in the graveyard of static site design. Over the next few weeks I would like to explore some areas where we can prepare ourselves ahead of time for responsive projects that have yet to begin or even be conceived.
How can we prepare?
There are quite a few areas in a RWD project that allow for time saving methods. While some components, like how to create media queries, how to handle media and where to define breakpoints have been heavily discussed there are other areas, like how we do wireframes, concepts and style guides in an efficient manner that have room for exploration.
A lot of these things are flexible in their nature, not too unlike responsive design itself. There is no inherit right or wrong when it comes to decisions like how to build out wireframes for a responsive project. Some designers may be comfortable developing static representations in Photoshop, Illustrator or Fireworks. Others take it straight to the browser and some keep it LoFi with pencil and paper. Your best bet at this stage in a responsive project is to find out what you’re comfortable with and get the practice and experience you need to be efficient.
Project workflow is another area of concern with a responsive project. Responsive designs are less likely to consist of a designer passing a finished concept off to a developer and walking away. More parties are involved at more stages and communication becomes a crucial skill set. If you are freelancing or your project doesn’t have a dedicated manager or owner, you’ll need to start honing your communication and management skills. Adopting personal policies of writing clean code, making clear notes and comments, and submitting frequent updates to the other stakeholders will save a lot of headache.
These are areas worth covering more in depth but not my biggest interest for this series of posts. Instead, I will be focusing on the execution side of things. This is because I think there is a lot of work a designer can do to be prepared for a project before any project even exists. My goal is to share and discuss ways we can be prepared for a responsive project that has myriad unknown factors… the responsive unknown.
What is the Responsive Unknown?
Working on projects that don’t exist may come across as an incredibly stupid waste of time. But really it’s nothing new. Anyone who has ever used a boilerplate or framework, like one I mentioned earlier, has benefitted from this sort of practice. It’s basically recycling common project components where it makes sense to do so; it’s simply a smart practice that saves time and money without sacrificing originality or quality.
But can we go beyond the starting line with our preparation? There is a bit of a debate to be had here. We all love to share clever solutions to common page elements like navigation, popups, data tables, forms, etc. and often times it doesn’t hurt to start with a pre-made solution to avoid writing all of the HTML or CSS from scratch. We even have some rather exhaustive resources for these kinds of patterns in a responsive environment. If you haven’t already, checkout (or contribute to) Brad Frost’s “This is Responsive” project. The other side of this coin is that we wind up with a bunch of sites that look the same. I don’t consider this to be a big issue at this point, so it’s an argument for another day.
So we have these resources available to us, but not all of them meet the right criteria. If we are going to use a pattern for “the responsive unknown” it not only needs to be responsive but also flexible in the content it can hold or the content that’s around it. And this will be the purpose of the next few posts here. To explore our options with popular site components and seeing if we can find or develop some good resources for building responsive solutions that have unknown variables, not just in viewport size but content and purpose as well.
What’s the Benefit?
Is there a measurable advantage to this? I say there is. Especially when it comes to the world of responsive design, there is a lot of tweaking and nudging of HTML and CSS before I’m happy with a result. If I can produce a starting point where a lot of that work is already done, I know I am saving myself time.
There will be occasions where I can slap a pre-built solution into a wireframe and it works perfectly for the application. We like to hope these scenarios are going to come along often but the reality is that design involves a lot of “it depends” scenarios. This means making adjustments to our starting point. But I think that starting point can come from a much smarter place, in which case there is still a lot of time to be saved.
Time Saving Areas
Finally, let’s look at what areas I think we could stand to save some time with really smart defaults. I will be covering these things here on my blog in the coming weeks. If you think something should be added to the list suggest it!
- Typographic Scale
- Grid Layout
- Tabbed Page Structures
- Images / Video/ Multimedia
- Popups / Modals
- Smaller Components (buttons, form fields, asides, etc.)