Test this on a small touch screen. Unless you channel all your swiping mojo, you won’t be able to scroll to the bottom of the page.

This is most common with single column mobile views where containers occupy 100% of the viewport’s width. To avoid this, I’ll usually set the container closer to 90%. This provides rails on the right and left sides that ensure there’s always part of the page to swipe. I also try and keep the map’s height short. Maybe something like this:

Get directions

In the context of designing for the multi-device web, the high level of iteration and communication required to build a modern website is rendering the assembly line approach obsolete and reorganization necessary. However, if a process is changed without rethinking the network of talent, resources, and management that support it, friction and inefficiency can arise.

Let’s assume that an assembly line process has 3 key phases: planning, design, and code, where each phase determines the next, and a project transitions primarily from strategy to execution.

Within this approach, teams are often structured to mirror the process. Planners (stakeholders, content strategists, management) define objectives and direction. Then, designers take the handoff to add form, hierarchy, and aesthetic. Finally, coders (front & back-end developers) execute the plan.

I think that this skill-based compartmentalization is one shortcoming of the assembly line. Locking developers and/or designers into a 100% execution role is a missed opportunity; ideally, every role contributes to strategy. Things like device compatibility and technical debt (typically in the realm of developers and often overlooked until the latter part of the project) should be a core part of strategic planning.

Teams compartmentalized in this fashion can have a difficult time iterating and exploring at a reasonable pace. For example, if developers need to schedule a meeting with designers and planners every time a layout change/breakpoint is needed during the coding phase, the iteration loop may extend from a few minutes to a few days. Traversing these compartmentalized phases and roles becomes cumbersome and time consuming, ultimately diminishing the potential for the final product.

If a process calls for multiple builds and rapid iteration, why not structure teams accordingly? I like the idea of smaller, tactical teams that are capable of executing multiple rounds of planning, design, and code quickly and independently.

The size, structure, and number of teams can be tailored to the organization, but the idea is to assemble teams with complementary roles in a truly collaborative way. Members are available to each other regularly, and the chain of command is not isolated to each division/skill (e.g. designers reporting to a creative director). The teams are ultimately responsible for what they build and how it performs.

Within this structure meetings become quick chats, ideas become prototypes, and the overall process becomes more efficient. For example, think about how much effort is involved when a Photoshop comp is polished, then all the color, sizing, and spacing values get harvested and reproduced in code form by developers. It’s duplicate work. With a collaborative team all the polish effort would be directed at the browser. Sophie Shepherd outlines these benefits in her work with Happy Cog:

By jumping right into the template phase before design was finished, we were able to make all design decisions in the medium they were meant to be in. We could do QA and device testing as we worked. With the help of SASS, it was easy to make changes and incorporate feedback directly in the browser—infinitely faster than it would have been in Photoshop.

When various skill sets are combined in this way, people learn from each other. Rather than creating to-do lists filled with nudges and site tweaks for developers, designers could learn CSS and edit designs in the browser alongside more intensive development. Developers could hone their design sensibilities and contribute by making enhancements such as gestures, geolocation, and performance a part of the design process.

Because the things we build rarely take one shape these days, it’s key to keep in mind that our processes and teams probably shouldn’t either. The time of neatly organized process charts and workflows is behind us. Building for the web has become a journey with infinite potential for forks and bumps in the road. Let’s make sure that our process and organization ready us for what lies ahead.

I find it’s better to err on the side of larger type and bigger touch targets on any screen size, but I do think I was over-generalizing. In fact, there are a lot of places on the current Microsoft Homepage where we’re using 14px (0.875em) text. I think it works quite well for things like labels and caption/sub-text, especially for narrower columns.

Also, it’s entirely possible to have type smaller than 16px and maintain reasonable touch target sizing through vertical spacing like line-height and padding. Why both? Take a look at the two unordered lists below (Demo also on CodePen):

Example A only uses line height to establish vertical spacing, but when text wraps at narrower views the list items are hard to tell apart because lines of text and list item links are spaced the same. Example B has a tighter line-height with the difference being made up with the extra padding. This way, when the text wraps it’s easy to tell items apart. Bada-bing!

The first is the Dribbble meetup on Saturday, March 9th at 8pm at Scholz Garten. The event is hosted by Dribbble, Microsoft, Squarespace, Creative Market, Happy Cog, and Paravel. We had a trillion people and an ice sculpture last year, so don’t miss it.

Then, on Sunday, March 10th I get to be part of Adobe Creative Camp, which spans the entire day. I’m on a panel at 3:30pm called Responsive Design From Every Angle with Sophie Shepherd, Jacob Surber, and Emily Wengert. I’m honored to have been asked and think it’ll be great.

Update: 3/13/13
The infinitely talented Gerren Lamson recently posted his sketchnotes from the Responsive Design From Every Angle panel. Gosh, he’s good.

If you’d like to take the book for a test drive, good news! Mine is the free sample chapter (8.0mb PDF). But there’s nothing quite like the real thing. This is Smashing’s best looking book, topped off with illustrations by the infinitely talented Mike Kus.

I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.

Consider RWD From the Beginning.

I believe this starts with a shift in perception. Whether massive or minute, this shift usually involves letting go of a lot of assumptions that center around desktop-centric browsing. There is so little that we can actually count on: mouse pointers vs fat fingers, hover states, screen sizes, connection speeds, device capabilities, etc. What good is initial planning (content strategy, IA, sketching, prototyping) without considering all of the variables the multi-device web provides?

If a team is knee-deep in .PSDs before considering layout changes and alternate viewports, opportunities for optimization and innovation will be overlooked. I’d rather proactively embrace a new approach than try to shoehorn an old one.

The Benefits of a Lengthy On-Ramp

If I were on a team organized around fixed-width desktop-centric production I wouldn’t want to be expected to immediately start building responsive sites at the usual pace. Taking time to fiddle with devices, hack code, and perhaps most importantly, time to think pays off in the long run. Giving teams and individuals a cushion to get back up to speed after taking a new direction helps instill a sense of purpose instead of panic.

This cushion could be in the form of extra time for reading and research, extra time budgeted into a project, or even better, a responsive hack week project. Imagine teams of 2-5 that build a responsive site on any fictitious topic they want.

We had to uproot a lot of what we were used to at Paravel, and there are only three of us. Processes and roles will change. Not everyone will be delighted about these changes all the time, so ease in and give team members time to learn by doing.

De-compartmentalize the workflow.

I’ve mentioned this before, but ditching the assembly line method of site building for a more communicative, iterative process will be helpful. Team members learn from each other (fatten those T’s) and arrive at solutions more quickly when they work closely. Rather than a more traditional design and development departmental split, why not create small teams with both design and development talent? That way, when someone has a good idea, it can be designed and prototyped without the hassle of multiple handoffs.

@-webkit-viewport{width:device-width}
@-moz-viewport{width:device-width}
@-ms-viewport{width:device-width}
@-o-viewport{width:device-width}
@viewport{width:device-width}

if (navigator.userAgent.match(/IEMobile\/10\.0/)) {
  var msViewportStyle = document.createElement("style");
  msViewportStyle.appendChild(
    document.createTextNode(
      "@-ms-viewport{width:auto!important}"
    )
  );
  document.getElementsByTagName("head")[0].
    appendChild(msViewportStyle);
}