One of the major goals of my recent redesign was to develop this site responsively. I’ve talked quite a bit about responsive design the last few months and don’t want to rehash it all, but thought I would share some of my thoughts and process along with some lessons I learned in building this site.
I didn’t do exactly as I’ve preached, though in fairness to me much of the work here came before I’d worked out my sermon. The work I did on this site is actually what led me to the many of the thoughts I now hold about responsive development.
How I Designed Responsively
This site was the first I began to design responsively and so it was as much a test case for learning as anything else. As you might also know if you’ve been following along with this series about the redesign, I was trying to put in practice quite a few things new to me at the same time.
Because of all the new things I was trying, I began by designing how the site would appear in a widescreen browser. This helped me focus better on working with grids and type in order to better understand both beyond their theory.
Thinking mobile first doesn’t mean you have to design the visuals for mobile first
I started by pretending I was working on a fixed-width 960px site. This was mainly to help set up the grid math. Since that was relatively new to me, it was just easer to remove the responsive challenges initially. I no longer start a responsive site this way, but this one time I found it helpful.
On the other hand, I did keep mobile devices and a single column design in mind the whole time. Just because something could fit within the widescreen design, didn’t mean I included it. I considered how elements would need to appear in the html, as their source order would ultimately be the display order on the screen.
As I’ve mentioned previously I didn’t create the usual design comps during this process. I worked out type, layout, and color independently and applied them to some basic sketches and style guides. A lot of the work happened in the browser itself. I had a good idea how things would look on a widescreen display, but not much more until development was under way.
Again while I didn’t necessarily go about things in the best way I did learn a few things I now use when designing responsive sites.
- Think mobile first — You always have to be aware how your design will work on a mobile device starting with the content to be included in the design.
- Design Flexibly — Think proportions. The goal isn’t pixel perfection. It’s to place elements relative to one another in ways that allow for expansion and contraction of both the positive and negative space and provides a means for elements to reflow.
- Design loosely for breakpoints — Your design will likely change beyond being flexible at certain points, usually when you add or remove columns. You don’t need pixel perfect comps for these different ‘states’ in advance but you’ll find it helpful to know something of how each will look.
- You can design end points in any order — Thinking mobile first doesn’t mean you have to design visuals for mobile first. You can design any of the different looks between breakpoints first.
Designing in the browser doesn’t mean you begin development without any idea how your site will look and work. It’s likely your site will have two or more different looks from smallest to widest screen. It’s ok to design these endpoints in advance, though you probably don’t want to stress the details.
Know that your design will mostly be flexible with greater changes at a couple or more key points. Loosely design these key points in any order you want, though don’t feel the need to design every last detail in advance.
How I Developed Responsively
As with the design, I don’t know that I developed with an ideal process. I began by turning my notes and style tiles into an html/css page for the design of a single post. I did convert measurements from absolute to relative right away, however, as with the design I began by developing a page for a widescreen browser.
Again I kept mobile in mind, mainly in how I ordered elements in the html source. I probably worked a little more than I needed to on this widescreen page, though it was to help me get the grids and type the way I wanted.
Once this page was built, I stripped out all the css and then set the page container’s max-width to the equivalent of 320px. Then I started copying and pasting from the widescreen css I had written. I copied the type styles and color styles and general styles, while staying away from layout styles.
I ended up developing 2 complete web pages with a lot of shared css, one for a widescreen browser and one for a smart phone. From this point I worked with the page I developed for the narrow screen. I grabbed the css I hadn’t yet copied over and little by little added them to media queries.
That raises the question of where to set breakpoints, and initially I didn’t go about this the best way. At first I listed common device widths (320, 480, 600, 768, 1024, 1200) and set up media queries.
With these I adjusted my browser, looked at the design, and added and moved css inside media queries. Mostly I used my eye to decide what was needed and either grabbed the code from the widescreen css or wrote some new css.
It led to an iterative process of adjusting my browser, spotting potential problems and fixing them, and refining the design under different conditions.
As with the design I learned a few things during development and reinforced some of the lessons from designing.
- Best to consider mobile first — Your source and display order will be the same on the smallest of screens so develop the page for the small screen first.
- Set breakpoints based on content — Don’t develop with preconfigured ideas of where the design needs to adapt. Check in a browser to find the points where your content needs the design to change.
- Use proportions — Set horizontal measurements in % and vertical measurements in ‘em’s. Set breakpoints in ‘em’s too. (Something I learned after finished the site)
- Iterate in the browser — You don’t have to or want to wait until the design is perfect to develop. Begin development as soon as you have a good enough idea of the layout at your endpoints and refine your design in the browser.
Start your development by creating the correct source order and develop your css flexibly. Think proportions and relative measurements. Start on the small screen and increase your browsers width, observing where the design needs to adapt more than growing larger.
Work your way toward your widescreen end point, setting up em based breakpoints. Fewer breakpoints are better than more. You probably only need to add a media query when your design adds or removes a column.
Iterate to refine the design and correct any problems that might arise.
This was the first site I attempted to design responsively. It was the second I completed, but it was the first I actually started. I didn’t quite follow what I’d now consider a more ideal approach. In part that’s because I needed to hold things fixed initially while I practiced other things I’d learned and in part because I used this site to work out how best to design a responsive site.
I designed things initially for a widescreen browser and even thought of the site as fixed-width for a time. I did keep the narrow screen of a smart phone in mind throughout the whole process, though.
When developing I also began with the widescreen, though I quickly switched to setting proportional measurements instead of thinking of absolute px. When the widescreen template was ready I stripped out the css and copied and pasted some back for narrow screen development.
With these 2 endpoints developed I set breakpoints and iterated over and between them until I had a finished responsive site.
I didn’t work with an ideal process and I’m not 100% happy with how things turned out. However, I learned quite a bit and now have some guidelines to follow for future projects. Subsequent responsive sites I’ve worked on have taken less time to both design and development.
Next week I want to look at one last part of the design. One that’s far from my skill set. I want to talk about the how and more importantly the why behind the logo. I’ll wrap up this series in another post with a look at where I failed in the design along with any leftovers I meant to include.