Assuming you know what responsive design is, let me start with what I call multidimensional responsive design. It’s not about spatial VR stuff or space travel. I’m sorry if that’s what you came for.
Many responsive websites check the width of the window and adjust the layout to that. On a mobile you get a single column for instance, and two or three on a laptop. That width is one dimension.
Sometimes it makes sense to check for the height of the window. Need to show a big website header with a logo, search and navigation? Just show it all on a tall screen, collapse it on short ones. That’s a second dimension.
Occasionally, designs take the user’s screen orientation into account. They show a portrait-sized image when the phone is held vertically and a square crop when it’s in landscape mode. Now we have three dimensions to which the design can be responsive already. There are many other things designs can be responsive to: browser capabilities and whether or not the device has a mouse, to name a few.
Here’s a practical example where I combined three dimensions of responsiveness: Big Timer (again). It’s the countdown timer for workshops and stuff that I’m making as a side project. One of Big Timer’s features is that the countdown is as big as the screen size allows. I didn’t want the controls to cover the countdown, so I created grids on which the buttons are placed around those numbers. The buttons are positioned such that they leave as much space for the countdown as possible. On wide screens, the buttons can be placed next to the numbers, as a bit of padding can be added there. On vertical mobiles, the numbers get the full width of the screen.
To achieve that, I experimented with (sidenote: A breakpoint is where the layout changes when you change the size of the browser windows. Breakpoints are commonly defined with CSS media queries, for example @media screen and (min-width: 600px) to define what should happen on screens wider than 600px. ) for horizontal and vertical window dimensions and aspect ratios. You can imagine that such multi-dimensional responsiveness can get unpredictable. That leads to my first bit of advice.
Tip 1: Don’t make multidimensional responsive layouts
Seriously, it’s a total pain in the butt. Specifying the design takes long, implementing it is also a lot of work. Even worse is testing. When a layout is responsive only in one direction, you can check around the break points in your browser, look on a couple of popular devices and see if it works as intended. But say, you’re making a layout that is responsive to 4 horizontal breakpoints, 4 vertical breakpoints and one orientation breakpoint. That’s 4×4×2=32 layouts already.
After having made several iterations for Big Timer’s responsive design and implementation, I got rid of the portrait/landscape breakpoints. Too often (and too late) I found elements falling off my layout grid at window sizes that slipped through my tests.
Right now I have 10 break points left and as far as I can tell, the layout works well for most screens. Still I’m considering abandoning it for a simpler approach. It’s just so much testing after changes to the design. Time that I can spent on other design problems instead.
Tip 2: Create an overview of all layouts
You wouldn’t have read this far if you weren’t interested in making a multidimensional responsive layout. So if you really must, I recommend making a complete visual overview of the different layouts.
I added a colored background to group what are actually the same fluid design grids. This helped me identify where the breakpoints were chosen wrongly. Like, why does the yellow group have a different layout to begin with?
Tip 3: Show testing information
CSS is plain text, so the overview from tip 2 must be turned into a single column of code. This can easily get messy. I partly solved that by sorting breakpoints by horizontal queries first and then by vertical queries. Still, sometimes (sidenote: To ensure consistency across different parts of the design, I’m using SCSS variables for the breakpoints, so I can’t just look up a breakpoint with the inspector. ) finding the breakpoint creating the layout in my browser. Therefore I find it helpful to name the breakpoints and show the active ones in the browser when testing and debugging.
Tip 4: Test on actual mobile devices
I found that in some cases phones used different layouts than what they would based on their screen resolution alone. I guess this has to do with zoom or pixel density. Anyway, you may not want to buy like ten new phones every year for testing. I use Xcode’s iPhone simulator, which seems to be realistic enough. A service like BrowserStack advertises you can remotely test on their actual hardware devices. I haven’t used that enough yet to endorse them, but it looks attractive.
Tip 5: Don’t use breakpoints
This may actually be the most important thing I learned the last year about responsive design in general.
In the example in the picture above, I forgot to take one thing into account that messed up the layout on medium-sized screens. For the smallest screen, I was using a smaller button size than for large screens. I picked a breakpoint for the change to the larger size that didn’t correspond with the breakpoints for the overall layout. As a result, the buttons stuck out of the grid between certain break points.
So by applying fixed sizes to both the layout and the components inside it, you can expect problems like the above to happen. They can be avoided by making the grid respond to its contents. Or by making the content flow on a fixed grid.
I find that for most cases a fluid grid is most versatile, predictable and best looking. Such a grid can give content the space that it needs while adding whitespace between the components to make the layout breathe as much as needed. I define minimum and maximum sizes for the columns and rows. Some components can get min and max dimensions, but only if they’re much smaller than the grid. This way, everything snaps into place just like it should. Not enough space to show a sidebar next to the main content column? Let the layout become vertical. Not through breakpoints, but just by letting the areas float as it’s called in CSS.
So my advice is to get rid of breakpoints as much as possible. CSS Grid offers really nice ways to get around breakpoints. Check out Mozilla’s nice intro to grids and the documentation for making responsive layouts without breakpoints. If you really, really have to work with breakpoints in two directions, try doing it in a way that’s limited to single components, where it doesn’t matter how the layout of one component affects the overall layout.
If I’ll ever work on a layout again that really needs to be responsive to multiple dimensions, I’ll try to keep that system as simple as possible. I’ll make sure to spec the design completely before it’s getting built. I’ll name the layouts and breakpoints so that testing and reporting bugs becomes a bit easier.
Note that this post was about responsive layouts for whole pages and apps. Making individual components like buttons or text size responsive to more than one factor isn’t so complicated, as long as they don’t affect the layout.
Please share this post if you found it helpful. Let me know if you have something to add to my tips!