Responsive width design? Sometimes consider screen height as well

Responsive web design is very much about screen width. Though we should probably be spending just as much time considering ways to lower page weight and other performance optimizations, there is no denying that we spend a lot of time considering questions like: At what width does our content begin to break apart? At what width should we introduce a media query to make the design work like this? And every now and then, how does our site look on a certain device with this specific width?

No doubt width matters a lot, but I would like to take a moment to discuss a few cases where screen height might be just as important, if not more.

Interactivity through the keyboard

One of the great things about touch devices is that the keyboard gets out of your way, when you don’t need it. Contrarily, if we’re not careful with our design, the keyboard may end up getting in the way, when you actually need it.

On the original 320x480px iPhone display the keyboard takes up more than half of the vertical real estate. When the keyboard slides in, it reduces the visible part of the viewport to a mere 320x200px rectangle. This holds for quite a challenge when designing interactive web applications, that take input from the keyboard and instantly provide feedback elsewhere on the page, e.g. in a calculator. “Elsewhere on the page” pretty much isn’t there, when you have this little space work with.

In taking a mobile first approach we’ve built a few applications on jyskebank.dk where we started by designing for a screen no higher than 200px. Our loan calculator (first image below) provides minimum and maximum monthly rates of a loan at Jyske Bank. The user inputs an amount and adjusts loan period on a slider; rates are then instantly calculated and displayed. With a little help from JavaScript the focussed input field is automatically scrolled to the top of the viewport, making everything visible above the keyboard. (Note: by default focused fields are centered vertically in the viewport).

Loan calculator on jyskebank.dkCurrency converter on jyskebank.dk
On displays of little height (less than 600px) the loan calculator and currency converter on jyskebank.dk both make optimum use of limited vertical real estate, by automatically scrolling focussed input fields to the top of the viewport.

A common case is to instantly display search results or autocompletes below a search field, as the user types away. Again vertical space below such a search field is very limited on a mobile phone, when the keyboard is up. The second image above shows an example from the currency converter on jyskebank.dk. On small screen devices the search field is automatically scrolled to the top of the viewport, making as many results as possible visible.

Building web applications, that take input from the keyboard, we cannot assume unlimited vertical real estate. To make things work well on mobile phones we must take into account, that vertical space is severely reduced by the keyboard.

Fixed position headers

In the latest edition of Google Chrome for iOS (Version 27) the address bar is automatically hidden as you start scrolling the page. The iOS 7 edition of Safari will bring along similar functionality, that reduces browser chrome to a bare minimum, when the page is scrolled. In doing so, both browser vendors seek to make as many pixels as possible available for your content.

Introducing fixed position elements in our design, unfortunately, goes against this effort to make every pixel available for content. Either way you look at it, a fixed position header is essentially chrome on your site, that eats up valuable vertical space, otherwise available for content. This becomes even more apparent when browsing in landscape on a mobile phone. On a 320px high display the fixed position header on mashable.com eats up 25 % of the vertical real estate.

Fixed position header on mashable.com
Browser chrome and “site chrome”, in form a fixed position header, takes up a lot of valuable vertical space when browsing mashable.com in landscape.

Introducing fixed position elements must be heavily weighed against the loss of vertical real estate. (Not to mention, that the address bar in Google Chrome on iOS can potentially block access to a fixed position header by laying on top of it).

Modal views

Oh boy, modal views… I hold a firm conviction that modal views should, by all means, be avoided. They get in your way and are simply a pain in the buttocks. However, if you happened to visit any of the links above pointing towards jyskebank.dk you will have been greeted by a yellow post-it note, informing you that the site uses cookies. As it turns out, at least with a bank’s legal department and EU legislation at your back, modal views are sometimes the only way out.

So how do we make a modal view work in a responsive context? First things first, to make sure the modal view is always visible regardless of scroll position it has a fixed position. On the desktop we wanted the modal view to be square shaped, resembling the shape of a standard post-it note (overlaid on the top-right corner of the image below). To achieve this we set max-width: 340px. At this width, the content inside the modal view makes it about the same height, but things are still allowed to squeeze together on less wide devices.

Modal view on jyskebank.dk
A height based media query allows the modal view to become wider, and hence less high, when browsing jyskebank.dk in landscape. Overlay in top-right corner shows the desktop styling of the modal view.

max-width: 340px in combination with position: fixed had quite an unfortunate effect when browsing in landscape. The desktop appearance of the modal view (top-right corner of image above) is too high to fit within the landscaped view and due to the modal view’s fixed position, the OK-button would potentially become inaccessible below the fold. To overcome this we added a height based media query that removes the max-width property on screens of less height than 350px. This allows the modal-view to become wider and hence less high, effectively making the OK-button accessible when browsing in landscape. Now, regardless of screen height, users can press OK, get rid of the modal view, and get on with using the site.

Images in landscape mobile browsing

Images look great when viewed on our desktops and on our mobile phones in portrait. In landscape, however, some images don’t work that well. Mobile phones in landscape aren’t that wide, so we typically allow images to take up 100 % of the screen width; but making an image wider also means making it higher, in order to preserve aspect ratio. Here’s the catch, if an image has an aspect ratio less than 16:9 it will simply be too high, to fit within a landscaped viewport on a widescreen phone. Of course an image taking up the entire viewport may look quite neat, but it raises a problem. If the image is to be viewed in relation with text (e.g. a caption), the user will have to do little scrolls up and down to understand the context. The image shown below on wwf.org is almost square shaped, making it look great in portrait, but turning to landscape it gets too large to be viewed together with the text below it.

Image in portrait and landscape on wwf.org
Especially images with aspect ratios less than 16:9 seem disproportionately large when viewed in landscape on widescreen phones.

On this site I’ve tried to do something about images blowing to disproportional sizes in a landscaped viewport. The bullet proof solution would be to set the max-height of images equal to some proportion of the screen height, but to my knowledge there’s no elegant way to achieve this using CSS (only to add multiple media queries at increasing screen heights) and I didn’t want my layout to be controlled by JavaScript. With a little experimentation I arrived at a simple solution, that seem practical for all the images I’ve so far put on this site. I’m simply setting width: 75% on images, when viewed on landscaped displays that are less than 672px wide. This gives the image a little squeeze, that is enough to make it fit nicely in landscape on a mobile phone. The end result is seen in the image below and on other images on this site, if you browse in landscape on your mobile phone.

Image in portrait and landscape on clausstadel.com
On this site images has a width of 75 %, when viewed in landscape. While not a bullet proof solution, for most practical cases this makes the entire image visible within the viewport.

I did experiment with putting the caption next to the image instead of below it. It worked quite well for demos, but wasn’t practical due to varying aspect ratios and caption lengths.

When building interactive web applications, adding fixed position elements, browsing in landscape, and surely in other cases I didn’t mention here; screen height has implications for the user experience of our sites. Width is important when doing responsive web design, just remember that sometimes height matters as well.