martymoo

Designing for Tablets: Not Quite “Mobile”

Tablets (the iPad in particular) are increasingly popular right now, but web design patterns for tablets are still very much in flux. At IBM, tablets fall under the umbrella of “mobile computing” and many of IBM’s collaboration tools currently redirect tablet users to the mobile version of their site. Many other big industry players do the same: for example, Google+ currently redirects iPad users to their mobile site. On paper this makes sense – tablets are ultra-portable, and share much in common with other touch interfaces (the iPad is just a big iPhone, right?). In practice, I’ve found it’s not so simple.

“mobile” sites for IBM Connections are great on phones, awkward on tablets

My team conducted a simple user study to get a basic understanding of what people wanted in their mobile, desktop, and tablet experiences. We asked users to perform a series of simple tasks using the IBM Connections mobile and desktop sites on a phone, an iPad, and a desktop browser. The results were perhaps obvious: for phones the mobile-optimized site was much preferred while the “normal” site was preferred for desktop browsers. For the iPad users unanimously preferred the desktop site despite the fact that some features (notably the rich text editor) were broken. People complained that the mobile site on the iPad felt “stretched and awkward” and that while they were glad that the navigation became more compact on the phone, they found it frustrating on the iPad. These findings are very similar to the public reaction to the Google+ iPad support: people do not want to use phone-optimized interfaces on tablets. Here are some new assumptions I’m working on when designing for tablets:

1) When it comes to browsing the internet, the iPad is not a mobile device

While tablets are often grouped into the “mobile” bucket, they are in fact only as mobile as laptop computers. There is a reason Steve Jobs introduced the iPad from a sofa – it’s not a “pull out of the pocket” computer. Traditional mobile websites are frustrating to use on a tablet. Single-column mobile layouts work great on phones, but can feel stretched and awkward on tablets. Unless you are willing to spend a lot of time tailoring a special tablet-optimized mobile site for the iPad, you are better off supporting and tweaking an existing desktop site for the iPad. A better strategy for supporting many different form-factors with a single site may be using responsive web design, but this is hard to pull off if you are working with a pre-existing site rather than starting from scratch.

2) When it comes to apps, people have high expectations for the iPad

iPad apps may have been “nice to have” at first, but the number of iPad users are growing at an alarming rate.  iPad apps are popular for a reason: they are easy to discover and install and they tend to be simpler, faster and more content-rich than their website or desktop counterparts. Popular services that don’t offer iPad apps will see 3rd parties rushing to fill the void. Facebook is a good example of how the app development ecosystem is struggling to fill the void created by Facebook’s lack of an iPad app. An interesting middle-ground is also emerging for developing app-like iPad websites, which can be just as successful as a traditional “app” but may be harder for people to discover or adopt (adding a website to the homescreen is something I don’t see people doing very often in the wild).

3) iPad apps may point toward the future of desktop installed apps.

The breakout iPad app Reeder has recently introduced a desktop app that is clearly inspired by their iPad release. The simplicity and clarity that users expect in iPad apps are so popular that desktop sites and apps are likely to follow suit. Dan Lythcott-Haims at Pandora recently said that Pandora redesigned their web site after the success of their iPad app’s simplicity. I expect that desktop applications will begin to look more and more like iPad applications: simpler, content-rich apps with a high attention to both experience and visual design.

1984 – Now: Computers I have known

I just finished reading the fabulously nerdy Ready Player One, a book that celebrates the early days of computing. This set me to thinking about all the computers I’ve ever owned and how they’ve changed over the years. Thanks to wikipedia I was able to quickly put together a list.

What struck me most was just how much faster and better computers have gotten in such a short amount of time. Because I’m a nerd, I decided to make a visualization showing the progress. I used RAM as the yardstick because it’s pretty much the only easy constant to measure: processor speed is hard to compare, I have no idea how much hard disk storage there was in each machine, and there is a mix of laptops and desktops so size is out. The results shouldn’t surprise me, but it still did. It’s an object lesson in Moore’s Law. Every computer I have ever owned has more RAM than all the previous computers put together. If car performance had improved like this since the 80′s I’d be driving a million miles a gallon now. Thanks to XKCD for the inspiration for this visualization!

Click to enbiggen!

Mobile First, Responsive Design and Me

I’m a big fan of Luke Wroblewski’s “mobile first” motto. The general idea is simple: design and build for a mobile site first and scale up to deal with larger form factors after you’ve established your mobile site. This approach forces you to narrow your focus immediately: The smaller canvas of mobile sites prevents you from adding any nonessential elements.

Now that a mobile-first approach has helped establish a solid, simple foundation, how do you scale up? Even though mobile sites may share the same core design challenges,  automatically scaling a small site up to a large one is just as bad as resizing a desktop site down to mobile sizes. A recent user study my team conducted inside IBM reinforces this perhaps obvious finding: phone-optimized sites are frustrating to use on larger devices. After reading Ethan Marcotte‘s amazing book Responsive Web Design, I was pretty much sold that the best way to scale a mobile site up is by dynamically adapting the layout of a site based on the browser’s width. (Honestly, go buy and read the book, it’s worth it. I’ll wait right here.) I didn’t want to just arbitrarily grow or resize elements, though — I wanted to establish a predictable system that could easily determine how my site should render at bigger sizes. One powerful way to scale your site while still establishing a consistent feel is to use grid-based layout.

Grid systems provide a visual structure for your site

I was originally trained as a graphic designer and am no stranger to grid-based design. There are many contemporary CSS frameworks that make building grid-based sites a snap — 960 Grid System is a wonderful framework I’ve used in the past. One downside with many of these frameworks is that you have to assign classes like “col1 span2″ directly in the markup that may not make sense at all different sizes. An element may span 3 columns on the desktop, but only 1 column on a mobile device. One way to work around this is by using a system that allows you to separate the grid layout from your html markup, which is exactly what the Compass blueprint semantic grid framework does. With this framework you can assign grid values to existing CSS classes with no need to add any bogus “col1 span3″ classes to your markup.

I decided to use martymoo.com as a testbed for this approach of mobile-first, responsive design. I have been meaning to update martymoo.com for years. It’s a wonderful domain name that my sister gave me as a birthday present back in the late nineties, but I’ve hardly ever used it. I decided to update my portfolio site – nothing fancy, I just wanted to have a simple page where I can display a list of projects I’ve done in the past. I sketched out a few options before settling on a simple gallery: a main index page displays a list of my projects, each of which has its own detail page.

In accordance with mobile-first, I started by sketching out my gallery, a tall page that listed projects one after the other.  This layout will be used with viewports that are 320 pixels wide and smaller, the width of the iPhone in portrait. Note that while I used the widths of apple’s devices as guidance for where to establish new viewport sizes, I still tested on a variety of android devices to make sure it worked well at many screen sizes. At 320 pixels and below there isn’t much of a grid to speak of. Each element spans the full width of the page with a little bit of padding, and most elements are centered.

Next, I defined my grid system for scaling up. I am very fond of the proportions in the 960 grid system, so I borrowed their 12-column, 60 pixel wide layout. Note: I started off using ems for width, but quickly became frustrated with the distortions that a fluid grid created. I may revisit this in the future, but for now I prefer fixed-pixel grid units. As the browser viewport grows, I added more columns until the maximum of 12 columns is reached:

• 320 pixels and less: single column 100% width (iphone in portrait)
• 480 pixels and less: 6 columns of 60 pixels (iphone in landscape)
• 768 pixels and less: 9 columns of 60 pixels (ipad in portrait)
• 980 pixels and less: 12 columns of 60 pixels (ipad in landscape)

Here’s what my first site wireframes looked like:

I’m really happy with the predictability that the grid layout gave this design. Despite the significant size differences, the page maintains a consistent look and feel. The site structure seamlessly adapts to however a person wants to view it – check out the final results here.  I’ll write a follow-up post in the future that describes how I ultimately implemented this design.

A blog? Seriously?

Yes, seriously! I’ve had “write a blog on the internet” on my to-do list for about 5 years now, and I’m happy to tick off that box.

So, why a blog and why now? I’m not new to blogging in general, but up until now I’ve only published to IBM’s internal blogging system. I’ve found intranet blogging tremendously valuable.  I can share design concepts and get feedback on projects that aren’t ready to be shared outside IBM yet. It’s also limiting – I find that I only write about my work at IBM, and I’d like to write more generally about interaction design and current trends in the industry.

I’ll be posting case studies on some of my work at IBM and random design thoughts as I go. If you’re dying for more frequent updates, hit me up on twitter: @martymoo