Going responsive

I’ve been talking about responsive mobile design for quite some time now, but was kind of neglecting my own blog and how it looks like on smaller devices. My main focus is on readability, and this was severely impaired on smaller screens. I was using the WPtouch plugin on the blog, and while it was doing a somewhat decent job at scaling down the content, it was not very good.

And so I spent the last few evenings doing semi-random things in my CSS and poking around the developer tools in Chrome. It’s not finished, of course. I still need to figure out how to bring back the search. But otherwise I’m quite happy with how things look now when you browse this site on smaller screens.

Mobile web is a commonly used name for browsing web on mobile devices. It is a rather useful, but very misleading way to talk about how web pages look on a variety of smaller screens. Screens which are, at least at the present moment, associated with devices that are more mobile than traditional screens found on your desk. The ill-fated push for netbooks and the recent wave of hybrid tablets that have desktop docks with full-size physical keyboards are blurring this traditional line between mobile and desktop screens, but I digress.

As Jeremy Keith points out in his “There Is No Mobile Web” presentation, and as I have mentioned a number of times on my blog, one of the more important facets of responsive design is adapting the presentation of the content to the current context:

Now the important thing is, each time I switch the layout there, going from two to three to six, those break-points, those changes, were not dictated by the size of devices; they were dictated by the content. When did it make sense for the content to switch from two to three to six? Because again, I don’t think it scales to just choose your break points based on whatever’s currently popular. So at the moment we’ve got 320, 480, 640, whatever, but there’s so many different devices out there with so many different sizes and dimensions that it makes much more sense to let your content decide when is it time to expand; when is it time to allow some breathing room.

One of the greatest strength of Web as a platform is the ubiquity of access. A device, no matter how small or big, that ships without a built-in web browser is quickly becoming a thing of the past, a curiosity, a gadget at a severe disadvantage in the fiercely competitive landscape. This landscape is seeing a lot of experimentation in the physical screen size, aspect ratio and pixel density. Designing your structure around a few “well-known” pixel widths of a small subset of popular devices is a losing proposition. Instead, the logical hierarchy of your content – the blocks, their logical importance and the spatial relationships between them – must be the primary factor in the decision to switch between different representations of it.

This blog has four blocks: header, content, sidebar and footer. The word “content” is rather overloaded here, and by “content block” I mean the left column that contains the article(s) that you’re reading. As part of the recent redesign the content column switched from 600px width to 720px width to accommodate larger font sizes (with a nice side-effect of being able to use larger images for interviews and other articles). As I started thinking about the different ways to scale down the presentation of the blog to smaller screens, my main goal was to reserve as much horizontal space as possible for the main content block, and to preserve its width (720px) for as long as possible.

At its widest, the current representation is 1120px wide, with 720px going to the content and 365px to the sidebar. Using auto as left and right margins centers the entire content in the browser window. This worked nicely when you viewed the site on a large screen – or rather when your browser window was sufficiently wide to fully fit the entire 1120px span under the current zoom level. However, if you started to make the browser window smaller, horizontal scrolling kicked in and the entire experience was not very user-friendly.

In the new implementation, after a rather short intermediate step where the content column remains at 720px and the sidebar shrinks to 245px, the entire layout switches to one vertical stack – header, content, sidebar, footer. In fact, the transition from displaying this secondary content (“about” blurb, links to recent entries and links to social media profiles) at the right side of the main content to displaying it below the main content reveals a rather unfortunate naming convention for it. It goes along the same vein as the distinction between the semantic <em> (for emphasis) and the presentational <i> (for italics).

At width of 1000px – encoded with @media (max-width: 1000px) – I switch to width=auto, margin=auto and max-width=720px. Here’s a screenshot to illustrate what this does:

As the sidebar is no longer displayed to the right side of the main content, there’s a certain range of screen sizes where I can display the main content in an area which is wider than 720px. My decision here is to limit the content to its “original” width with max-width=720px and center it horizontally in the parent with margin=auto.

As you go along the axis of progressively smaller screen sizes, at some point you need to decide what to do when you just don’t have enough room to display even a single block of content at its “ideal” width. This is where width=auto kicks in, making sure that your content wraps within the available horizontal space.

Once you have a decent presentation figured out, there’s a lot of things that you can refine and polish. Depending on the the logical structure of your content you can have multiple breakpoints (or switching points) where content shifts between a number of possible presentation structures. You can play with font sizes (as I did for the main title and subtitle in the header). You can play with content paddings to give it more breathing room on slightly larger devices. For example, in the next screenshot you can see that in portrait I use 12px padding, while in landscape I use 24px. The difference here, of course, is not the specific pixel size or orientation of the specific device, but rather the available width. Currently I encode the switch from 12px to 24px by @media (max-width: 480px). Some sites use percentage based paddings and margins, at the expense of not following a well-defined grid rhythm.

At slightly over 100 lines of CSS and one extra meta directive in the <head> section, with no changes to the overall content structure, this has been much less painful than what I feared it to be.

The full explanation of the viewport meta tag is somewhat over my head, and I don’t quite understand why this needs to be specified explicitly for optimizing the content viewport and default font size on smaller screens, but suffice it to say that without the magic of adding <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=yes;" /> to the <head> section the site looked quite badly on a variety of devices and browsers.

I’m not a web developer, nor do I pretend to be creating a complete guide for turning any blog into a fully responsive one. This is just documenting a first and very important step towards making Pushing Pixels look good on a much more diverse variety of screens.

Unsolicited redesigns and focus on visual

Circling back to the topic of unsolicited redesigns, the discussion over at Branch largely talks on one of the points I mentioned last week – focusing on visual instead of interaction.

Looking at the existing screens of a product (be it a web site, web app, mobile app or desktop app) and making them prettier is all about visual design. Playing with colors, fonts, alignments, paddings, margins, gaps – or adding crisp stock photography – is a very visceral way to show your skills as a visual designer. This process sometimes omits certain technical aspects, such as, say the impact on the loading time and network (monthly bill) consumption, limitations of the underlying platform and the impact on framerate for some transitions, font rendering capabilities that can make your nice typography look quite bad and more.

But what about the interaction design? What about taking a hard look at some of the products you’re using on the daily basis and seeing how you can smooth the bumps that you encounter along the way of completing a certain task.

How about the process of finding the certain episode of your favorite TV show, buying it and watching it? How many screens does it take? How many taps, swipes and flings does it take? How much do you type on that small virtual keyboard? How much of that annoyance can you shave away without degrading the functionality scope?

What about making an hotel reservation? Direct messaging somebody on Twitter? Muting an annoying hash tag? Finding what is the closest movie theater that is playing The Hobbit in HFR 3D? Buying a ticket to that movie? Bookmarking the location of that movie theater? Navigating to that theater a few hours later? Taking a few pictures of yourself and your friends in the theater lobby and creating a booth-style photo strip? Ordering a pizza after you get back home?

There’s plenty of apps that do these tasks. You can redesign the outer layer of each one of those. But what about looking at the navigation models of each one, really looking at them and trying to improve them? Talking about what bothers you in the particular flow, showing how you restructure it and convincing the reader that your changes are an actual improvement? Taking those changes and applying them to the rest of the app? Making those change consistently better across various form factors where larger devices may combine two or more smaller screens at the time?

This is not shiny. This is not sexy. Interaction designers operate on the level of wireframes and flow charts that show transitions between various screens.  A vibrant pixel-perfect mock with glamorous stock photography is visceral. Easy to look at. Easy to consume. Easy to understand the change. A wireframe that rearranges the content to move some things above the fold, or group related things is not. It takes time to understand. Words from you to describe why your change is better. Attention from the reader to look at how things were arranged before, how they are arranged now and what is your reasoning behind this.

Unsolicited redesigns

Fred Nerby’s “Facebook – New Look & Concept” is the latest in a stream of unsolicited redesigns of well-known products.

Some random thoughts having survived a few redesigns myself, and having seen quite a few unsolicited redesigns for other apps.

• The mockups always (really always) use full-bleed nicely balanced pictures of young smiling handsome people. The vast majority of the actual content as seen during the development cycle is somewhat less appealing.
• 50% of the replies say “I hope Company X is listening”. Another 25% say “Company X should hire this guy”.
• Companies are listening, and in quite a few cases the redesigns live in an ideal world divorced from harsh business and marketing realities of the specific product.
• “Hiring the guy” assumes that “the guy” is actually willing to do the dirty work of understanding all the non-glamorous details of various scenarios and tweaking the initial mocks endlessly to adapt. A non-trivial number of proposed mocks are a no-go to begin with.
• Static mocks are static. It’s only when you start putting them on the actual device / browser that you start thinking about the myriad dynamic aspects of layouts, transitions, animations and other pixel-level mechanics.
• On a related note, most of such redesigns that I’ve seen focus on the visual design, and put very little emphasis on addressing problems in the existing interaction design or moving between the redesigned screens.
• By the time an actual implementation is ready to ship, the pixels on the screen don’t bear much resemblance to the original mocks. They are not necessarily less pretty. Just different.
• In a world of an almost continuous spectrum of device form factors, it’s very rare to see a redesign that bothers to address how the layouts respond to changes in screen size and orientation.

If you’re doing such a redesign, it’s an opportunity to show your skills. If you get noticed, people will link to you, and you might get hired to work on good projects – or even on a product that you’ve tried to redesign.

If you’re a reader looking at the redesign, you can look at the nice pixels and do “your part” by saying that Company X should hire this guy or do exactly what he did. You essentially did nothing, and you’re feeling superior because if Company X is not going to do this today, they’re a bunch of clueless dudes. It sure gives you a nice warm feeling, but otherwise is  a waste of time for everybody involved.

Code reviews. Seriously.

To mark the end of my third year on the Android team, here’s a TL;DR version of the last thousand days or so.

Do code reviews. You’ll occasionally butt heads, as there’s rarely a single “best” way to make even the simplest bug fix. But no matter what’s the seniority of your reviewer, you’ll always be better off at the end. I lost count of the number of times that I said to myself “Huh, I didn’t know that” after seeing a reviewer leaving his comments. Not to mention that you’ll have somebody else having at least some level of familiarity with your code if you ever get too swamped.

Every once in a while you’ll get out of your comfort zone working on a new feature or fixing a bug. At some point you know your reviewers, their style and their strengths. Don’t be tempted to add reviewers that will be inclined to rubber stamp such code. Seek out people who are deeply familiar and well versed in the specific area. You will be afraid that they’ll pick your code apart like a poorly constructed house of cards it is. Better now than after it ships. Such a reviewer knows how to do this better than you, and the result will be better for both you and your code base. It will just take longer. Don’t let your ego take a hit. It’s just code.

When you’re asked to do a review, do it quickly. Don’t drop everything and do it immediately, but do it the same day. The quicker you provide good and actionable feedback, the fresher it is on the side of the code author. Don’t let your reviewers rot. This also helps preventing unnecessary rebases. Not to mention spreading your strengths around, and learning from the strengths of others.

Don’t do gigantic code drops. If it’s a big feature, start on smaller steps towards the final goal. Mark unfinished places with TODOs so that the reviewer knows this is not the final thing. And make damn sure there’s not a single TODO left at the end.

Cross reference all code changes with bug tracker entries. Document all discussions, decisions and alternate solutions that didn’t work in the bug tracker. When somebody asks why things were done this way a year later, they’ll be thankful. In most cases, that somebody will be you.

Do code reviews. I might have mentioned it. But seriously. Don’t be that guy whose code ends up on The Daily WTF. By the way, if your team members start posting your code there, you might want to contact your internal security guy. Just saying.