May 22nd, 2013

Based on a true story

A few years ago, in a company whose name doesn’t really matter there sat a programmer working on fixing a few bugs and adding a few features. And as he was sitting there, an idea struck him. An idea for a feature which was kind of related to what he was doing. And he leaned over to his cube mate and outlined the idea. And the cube mate told him that it’s a nice one. And that he should see if the idea can be turned into a patent. Not because that idea would actually be turned into a feature. But because everybody else tries to patent ideas, no matter how small or big they are. Or no matter what actual connection they have to what you’re doing in the office. Play the game. Send an email. Let the process begin. Sit in a couple of meetings. And then a few years later, if it turns out to be an actual patent, get some extra money. Just for having had that idea.

And the programmer sent that email. And got a conference talk scheduled for the next week. A talk with a patent attorney. And with every day that passed, the programmer’s excitement has declined. And declined. And declined.

It started with patting self on the back and kind of marveling at self for coming up with the idea. And hey, extra money doesn’t hurt. Not that it’s a lot of money. But not loose change either. But with every day, the realization of how ridiculous and pathetic it is to think that an idea for a pure software-side flow is patentable started to sink in. Growing claws. Clawing at the inside, reducing the self-built pedestal to a heap of quick sand.

And then the time came to sit with the attorney. And the programmer was so dejected at that point that he just wanted to make it all go away. And the attorney sat there and said that he was going to just read this paragraph. And he started reading from the piece of paper. And, sentence by sentence, in six or eight short sentences it described the exact flow that the programmer had in mind. And then he asked whether it was in any way similar to what the programmer had in mind. And the programmer said that it was exactly the same. And the time to sit with the attorney was over.

And ever since then, the programmer has hoped to never be in such a situation again. To never bear the burden of self-inflicted aggrandizement of self. To never think that a mere idea in the realm of pure software is worth the notion of being patentable. To remain humble. To stand on the shoulders of others. To push himself to hone his craft and become better at it every single day. To hope that one day some of his ideas and code will be useful to others. And to never presume to claim that they were original in any shape or form.

May 22nd, 2013

The conclusion does not follow

Over the last few months I’ve read at least a couple dozen online articles, threads and discussions about skeuomorphic and flat design. The articles came in three waves. The first wave was about how skeuomorphic is well past its prime time and needs to go away. The second wave was about how flat is the exact opposite of skeuomorphic, and how it is the new direction of visual interface design. And finally, the third wave is about the poor usability of flat design.

Some of this discussion is happening on Twitter. There’s only so much one can say in 140 characters. Even when you break your argument into multiple consecutive tweets, the argument – more often than not – gets a simplified presentation. And sometimes the simplification of presentation leads to cutting logical corners.

Flat is indeed the exact opposite of skeuomorphic, but only if you consider the constraints that the designer employs in choosing his palette. Leaving the restraint part out of this argument leads one to believe that as the opposite of skeuomorphic, flat design is always done well. That, of course, can’t be further from the truth. This omission, by the way, can be deliberate.

If one can simplify the argument to pure one-dimensional comparison, and follow the stripped down logic to the “necessary” conclusion that flat is good – and immediately show bad examples of flat design, then the entire argument falls apart. Now, if you trace the refuted conclusion back to its beginning, the implied coup de grace is that flat is bad.

The opposite of a poorly done skeuomorphic design is not a well done flat design. The logical fallacy here is taking one part of the constraints/restraint spiral and extending the comparison to include the second one. The opposite of a poorly done skeuomorphic design is a well done skeuomorphic design. The opposite of a poorly done flat design is a well done flat design.

The opposite of a poorly done design is a well done design. Well done design that takes a long, deliberate and careful look at the available tools (constraints) and plunges into a long exercise of applying restraint in using a subset of those tools to arrive at the final product.

May 21st, 2013

Fifty shades of flat

Design lives and dies by two things – constraints and restraint. Constraints bound the variety of tools at designer’s disposal, while restraint guides the designer’s hand at how the chosen tools are used to create the final product. It’s rarely a sequential process, but rather a spiral that tightens toward the end, where the outcome of the previous steps informs and guides the next iteration. And each step – in both spaces – requires painstaking attention to details, paced deliberation and continuous pursuit of honing one’s craft.

There is nothing inherently wrong in what people have come to call “skeuomorphic” design. The choice of fewer constraints gives you a wider selection of tools to work with. Glossy bevels, generous drop shadows, intricate textures, strong gradients and more – all of these justly belong in a rich skeuomorphic visual palette. There’s no shortage of examples of strikingly beautiful visual design. Design that combines multiple textures, gradients and materials in a consistent form. Design that exercises restraint in how the rich palette is used. Restraint in how elements are chosen, which elements are left out and, most importantly, how the chosen elements are combined together.

On the opposite hand of the spectrum, if you will, is the “flat” design. Design that chooses to constrain itself to a very small number of visual elements. Sharp corners, solid colors, simple shapes, absence of drop shadows or, for that matter, absence of a global lighting model. The stark beauty of flat design is particularly impressive given the constrained choice of the tools. One may even be led to believe that the simplicity of this palette translates directly into the simplicity of the overall design iteration spiral.

This couldn’t be farther from the truth. Tighter constraints that result in a reduced palette do not necessarily obviate the need for restraint. Restraint is not only which tools you choose from that palette. It is also – and much more so – about how you combine the tools together. How you define and implement a visual language that stays true to the flow and shape of the interaction.

It is trivial to create a bad skeuomorphic design. There are entire blogs dedicated to ridiculing poorly-executed mashes of garish textures, exaggerated lighting and gaudy 3D controls. It’s not surprising to see these sites – and most recent blogo-bashing of skeuomorphism – focusing on pure visual aspects of such interfaces. On the other hand, as more designers dip their toes into the field, we see an increasing number of badly executed flat designs. The drive-by critics focus, this time around, on the usability blunders.

When you constrain yourself to simple shapes, solid colors and lack of depth, it becomes much easier to sacrifice usability. A hurried design executed from a rich skeuomorphic palette will look garish, but at least there are enough visual tools to help set the different pieces of content apart. With so many textures, gradients and shapes to choose from – and little restraint – one can still create a fairly usable interface. Usable in the sense that a button “looks” like a button – something that can be pressed to initiate some kind of an action. When you directly migrate this hurriedness into flat design, it is much easier to end up with an interface that jeopardizes the structure of your content.

Flat design necessitates deliberate definition of the visual language. How do you convey the logical structure of your content and maintain the logical separation of blocks in the visual realm? How do you convey the behavioral difference between the different blocks? How do you convey the logical importance and relationships between the content blocks?

When everything is a flat rectangle, and you only have a few accent colors to use, you have to exercise a much higher degree of restraint in defining that visual language. When your tool palette is restrained to a very few elements, you cannot afford to use the same element to mean two different things with no significant user-facing distinction. If your buttons and your section headers are the same flat solid-fill magenta rectangle, but the section headers are not tappable, you are not exercising enough restraint in how you’re using your palette.

It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving skeuomorphic design. The restraint that the designer must exercise at every turn of the spiral to use the rich variety of tools at his disposal takes attention, energy and time.

It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving flat design. The restraint that the designer must exercise at every turn of the spiral to use the small variety of tools at his disposal takes attention, energy and time.

Finally, skeuomorphic and flat are just two extremes of the same  spectrum. One does not have to go from one extreme to the other. There’s enough space in between to carve out your own, unique niche. The closer you get to one of the ends, the closer you get to the “extreme” choice of your tools – be it the rich palette of skeuomorphism or the small palette of flat. But the size of the palette has nothing to do with the next phase of the spiral – defining, refining and restraining your usage of that palette.

January 25th, 2013

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.