In his blog entry about Multi-Device Layout Patterns, Luke Wroblewski describes different layout patterns for web-sites that adapt to the device they are being shown on. These layout patterns are a central component to making a website that can be said to have a Responsive Design. Using such a pattern is not the only component to a site that has Responsive Design, server-sniffing to serve up only the right size images, for example, is just as necessary to not overwhelm small devices. The layout pattern, however, is the heart to deciding how the site is going to feel for users as they interact with different devices. All Responsive Design sites should equally make sure to send the right images for the size and density of the screen, or not try to do too much with fonts or frameworks on devices with slow connections, but different patterns are only appropriate for specific sites; and there are choices to be made.

Luke mentions the “Off Canvas” design pattern, a design pattern where the content is adapted to work on smaller screens by pushing non-essential content off-canvas. It is used well in Facebook’s mobile apps for example. The description really only discusses how the pattern works on a small screen, and doesn’t scale it up for tablets or desktops. I became interested in this pattern since I wanted something similar for a portfolio site that needed to show well on all kinds of devices.

The portfolio site is much like Facebook’s mobile experience of a central menu with different pages of content: the portfolio has a central menu of pages, in my case projects, to choose from, and then the actual project pages itself. It would be easy to follow this pattern for touch devices, but what should happen on less capable phones? And how should it scale up? Because yes, for a proper Responsive site, it is necessary to think about the least capable device first, and then scale up for better devices from there.

Re-using the work of Torkil Johnsen in making an implementation of a 3-panel “Off Canvas” design, I made a template experiment for this called Swipely Pages, it is now available on GitHub for anyone who wants to check it out. The design scales as following:

Simple phone, no scripting

On a device with little or no scripting capabilities, the menu page and subsequent pages are shown by themselves, and the user jumps between them by clicking links.

 

Touch phone, scripting

On a device like an iPhone or an iPod, the menu loads the first page of content into a panel that can be swiped in and out of view. By selecting Menu on the content panel the panel slides to reveal the menu, and tapping on a menu entry will load the page into the content panel.

 

Tablet

On a Tablet, the JavaScript in the menu page senses a bigger screen, and loads all the links in the menu into panels that are arranged horizontally. The user can swipe between the panels, and every swipe left or right neatly aligns the panel being swiped to with the left edge. The Menu button at the top of each panel is a quick shortcut back to the menu.

 

Desktop

On the desktop the visual behavior is much like on a tablet. However, swiping with the mouse or touchpad has not been implemented yet, so the user has to use the Next link to go to the next panel. Before deploying this template, the positioning of the Next link should be tested with users, and proper swiping with the mouse should probably be implemented.

As said, this template and experiment is available for download on GitHub. It needs work to be used in production, but I hope it accurately shows that more can be done with Responsive Design than just re-stacking elements into the viewport.

Recently I spoke to a company, very technology and features-driven, around for a little less than a decade, about their need for a UX person and what they wanted out of the role. My primary contact said that they were coming to the conclusion the company “needed their own Johnny Ive”, better known by his full name, Jonathan Ive, SVP of Industrial Design at Apple.

Finding your own Johnny Ive isn’t that hard: just throw money at an executive search of top-of-their-class grads with stellar subsequent careers. However, if what you are after is Johnny Ive-class results, finding this person is not enough. History shows that Mr Ive had started work for apple in 1992, and yet, as talented as he obviously was as shown by his current output, for the next five years Apple steadily slid backwards with a confusing, unimaginative, and mediocre line-up. It was only after Mr. Ive started working for someone who put good design above all else that his output became so stellar. In 1997 Mr. Ive had been empowered by a CEO Creative Director From Hell who, for example, was willing to move heaven and earth at great cost to make the outward appearance and feel of his product better six weeks before launch, while all his competitors were satisfied with the status quo. In that kind of environment, a designer can shine and the products end up spectacularly well designed, because spectacular design has now become the end arbiter of what gets made. Not ease of production, not time-to-market, not check-box features.

It’s not just the hire that matters, but how they fit in your culture and process, what you will give priority to as a company, how you will change to get the results you are after with this hire. When asked about how they saw their new “own Johnny Ive” fitting into their company, the team was very clear they wanted the “low-hanging fruit” picked up first, instant measurable ROI, features put out there before they were “perfect”, and fixing the current user interfaces without asking for fundamental changes to the existing code-base. Basically what they had been doing already. Only if  that was in place could they tolerate the design research to be done for their new products.

I warned my contact he had more work to do for the new desired results than finding the right person.

Mozilla Fest 2011 took place in London last weekend. Mozilla Fest is

The Mozilla Festival is a yearly celebration that brings together hundreds of passionate people to explore the frontiers of the open web. We mash developers, designers, and big thinkers together to make things that can change the world.

This year’s theme is Media, Freedom and the Web—how can the web can make us more creative, collaborative and connected in an age of broadcasters big and small?

I was invited to stop by for the day-long hack session “Touch the Web”, best described by the organizer, Johanna Kolmann, as following

We split up into teams based on creating groups of balanced skills, and self-organized into a format in which we discussed in the morning what we wanted to pursue, what our angle would be to make an iPad version of the Boston Globe website, and hack it together in the afternoon.

There was no time for a full User Centered Design process, but there was to discuss our expectations from online news media, our frustrations, and what we felt a news source on tablets should have. Writing and posting our wants, likes, and needs on PostIt notes gave us targets and a framework to keep in mind, which we then distilled to the Use Case we wanted to attack. Working that out by comparing to elements of sites we did like—also known as Best Practice or Competitor Research—we sketched a goal together, and in the afternoon we got to work to create a prototype on the iPad.

In a sense a very Agile process of defining a story, a goal, and a way to get there quickly. However, in Agile, at the point where developers go heads down to do the work, the UX team can then do preliminary work to get ready for the definition process of the next sprint, or consult on interaction details as the sprint continues. Except that eight now for us there wasn’t a new sprint waiting to prepare for, and there weren’t that many details of the interaction to really oversee.

But UX can always help the developers develop better: I started bringing them coffee and snacks.