I joined IBM as part of my university co-op program in 1996 and have since worked in North Carolina, Hursley Park (in the UK), San Jose, Boston, and New York City in my 15 year tenure here. I’ve had tons of amazing experiences at IBM: I’ve designed everything from administration consoles to chat clients; travelled the world; published 3 research papers and had 4 issued patents. Most of all I’ve had a chance to work some really amazing folks from all over the world. It is therefore that I have some mixed feelings to say that as of Tuesday, Nov 22 I will be leaving IBM.

On Monday, Nov 28 (Cyber Monday for all you nerds out there) I am starting as an interaction designer at Google in New York City. I’m crazy excited about the opportunity to work at Google – I’ll be working on consumer products that millions of people will use (a big change from having my work be seen by only employees of big businesses). I’ll miss working at IBM, but I’m looking forward to my new job at Google!

A recent trend in UI design is to use “sticky” navigation headers where a website’s navigation stays visible as you scroll down the page. Sticky headers can be a useful addition to a website, but they can easily become an annoying mess. The recent reaction to the Google Reader redesign has really brought sticky headers and wasted space into renewed focus. I’d like to break down the good and the bad of sticky headers.

Context-sensitive sticky headers can be wonderful

Gmail and menupages.com both provide excellent context-sensitive sticky headers. In gmail’s “new preview” theme, the action buttons stick at the top of the page, making it easy to reply / delete or label messages as I scroll down the page. Menupages smartly displays a restaurant’s phone number at the top of a page while scrolling down the menu for that restaurant.

Sticky headers should be as small as possible

The taller the sticky header, the more annoying it is. Good sticky headers are compact and don’t draw attention to themselves.

Sticky headers are intrusive

When I scroll down a webpage, I’m used to all the content scrolling with me. When part of the page stays visible it is distracting: my attention is drawn upward when my focus should be on the new content I’m bringing into view. This can be especially bad with sites that use animated transitions to collapse down a banner (I’m looking at you, IBM.com). Remember: the focus should be on your content, not on your navigation.

Sticky headers block content

Every pixel taken up by a sticky header is a pixel that could be showing content instead. Is the trade-off worth it? Remember, many users will be using smaller sized screens or may have nightmarish toolbar clutter in their browser already. What’s more important: your site’s navigation or the content (and ads!) your site is serving up? Google Plus has an innovative approach to this: they make the header sticky or not depending on how big your browser is (or, relatively speaking, how important your pixels are given the overall size of your screen).

Sticky headers can be helpful

1-click access to important features from anywhere on the page can be a compelling argument. Both Facebook and Twitter pull this off nicely: they have compact, useful headers that are generally useful. Coincidentally, both of these sites have extremely long, “infinite scroll” pages, so the sticky header prevents a lot of scrolling back and forth.

Here is some practical advice for when to employ sticky headers on a website. I strongly advise designers to think very hard before actually using sticky headers in a site; there are more reasons to NOT use a sticky header than there are to use one.

Good reasons for using a sticky header:

The header provides information that is critically important anywhere on the page
Examples: Facebook, new gmail theme

The page is an “infinite scroll” that goes on forever and getting to the top of the page may require a lot of scrolling.
Example: Twitter

Bad reasons for using a sticky header:

Branding & Site Navigation. Your website logo is not important enough to have it cover up content and advertisements. People come to your page for content, not navigation.Examples: Techcrunch, TheVerge, IBM.com

Consistency. This is the trap I think Google Reader has fallen into. Sticky headers should not be used just to make the site structure more consistent with, say, maps or other apps. I’ve long been a believer in context trumping consistency, and in this case Google Reader’s sticky header is a big failure. It’s too big and it doesn’t provide genuinely useful controls. I actually think a tiny header with action buttons may have been OK, but as it is, the content itself is sacrificed for navigational consistency, never a good trade-off.Examples: Google Reader

I get asked “should designers code?” more often than I feel like I should. The answer is yes. If you are an interaction designer, you should make interactive things. And if you design for the web, you should know web technology: html, css, and basic javascript. No one expects a designer to make a fully-functioning application, but you should be able to make a prototype that you can click through and evaluate. Learning basic markup and HTML is not as complicated as you think it is, and there are countless support materials for designers who want to learn how to use basic javascript.

Martymoo of All Trades

I don’t think this means that specialization is a bad thing, but being well versed in interaction design / HCI skills, basic graphic design, and basic prototyping will make you a better designer regardless of where your full-time focus is.

The follow-up question I always get after giving this response is “how do I get better at x?” The answer to this is deceptively simple: you get better at something by doing it over and over. My experience running the NYC marathon is the best practical example of this: if you run a little more every week, you’ll eventually run a marathon. You have to make time to pursue personal projects, and in that act as lead designer, visual designer, and implementer (my current project du jour is Stepchart, which is ever so slowly advancing). Even if you don’t finish you’ll learn far more than just trying out tutorials, and it will be fun because you’re actually doing something rather than just learning about it.

So designers: go forth and code! It will make you a better designer, and it’s not SO hard.

Small floating panels that appear when you hover over an item (popup cards) give users instant access to information without leaving their current page. Pop-up cards have become a pretty common interaction pattern on desktop web browsers, sometimes successfully (for example, LinkedIn has a pretty decent profile card that pops up on hover) and some are nearly universally reviled (for example, vibrant media’s “landmine” hover ads). In general I think pop-up cards are OK when used thoughtfully, but can easily become confusing and distracting to users. The ultimate tip-off that hover cards have usability problems is that they often have close controls on them: anything that is triggered by a hover should not require its own set of controls to be managed.

I have stronger opinions when it comes to mobile devices, however. Pop-up cards rarely make sense in a mobile context. Here’s why:

On a mobile device, there is no hover gesture.
People either tap something or they don’t. Until we have some sort of crazy optical recognition (I stare hard a person’s name to see their business card!) there is only one real gesture: tapping.

Who needs a middle man?
On a mobile device, it’s generally just as efficient to take you to a new page as it is to display a layered card on top of your current interface. Profile pages in mobile UIs essentially function as business cards: don’t display a pop-up card, just navigate directly to the profile.

Managing pop-up cards on mobile is frustrating.
Dismissing a pop-up card is a pain on mobile – users may inadvertently tap another link while trying to dismiss a card, and android users may try to use their physical back-button to dismiss the card (which would navigate them back an entire page in the mobile browser).

The bottom line: not all desktop patterns make sense on mobile devices, and pop-up cards are definitely one of them. I’m hoping to revisit this in a little while to address pop-up cards and tablets. I am pretty sure they should still be avoided, but it’s possible that they might make sense given the larger screen size available.

I prototype my designs in HTML as much as possible, but drawing in Photoshop is usually a precursor to digging into markup. I love looking through other designers’ photoshop files. Sometimes I’m overawed by the elaborate structures that people build with layer groups and precisely named layers. Sometimes I’m appalled that people can even function in photoshop: I’ve worked with amazing designers who don’t apparently name or group their photoshop layers at all.

I don’t know how people live like this.

I’m in the middle – I organize my photoshop files with a flat system of layer groups. I prefer broad, shallow organizational structures over narrow and deep ones: scrolling through a list is easier for me than digging through a big tree of nested layer groups. I make one layer set per “page” of the application or site I’m designing, and only add sub-groups to those layers if absolutely necessary. I try to name all my layers, but in the heat of the moment I’ll often wind up with a ton of “layer name copy 56″ that I need to rename at the end of a project.

My Photoshop files are all structured pretty much like this

A colleauge just sent me a file that has blown my mind a little – he follows a similar structure to me, but has added in visual cues for photoshop file workflow. He uses layer colors for this, a feature I’ve glanced at but never once used. It is simple and seems very effective: red layers for guides, yellow layers for in-progress, and green layers for “done”. This seems like a very nice way to work – you can scan through the file and quickly see what you should work on without resorting to external checklists.

It seems so obvious! Does everyone do this?

So I ask you, designers of the world: how do you organize your photoshop files? Is there some better method that I’m not aware of?

IBM is starting to put together a large number of apps for Android and iOS, and one thing you’ll find when producing native apps is that you produce a virtual mountain of graphics for each app: homescreen icons, notification icons, launch screens, market artwork, and on and on and on. I’ve made some photoshop templates to make producing these icons easier, but sometimes it’s hard to keep track of all tiny pieces-parts involved in submitting an app to the various app stores.

A Photoshop File for Android App Icons – HDPI, MDPI, LDPI, Oh my!

I recently spent some time making an activity template using IBM Connections to make it easier to keep track of all these assets. Activities and activity templates are one of the least-used but most useful features in IBM Connections. It lets you assemble a reusable, collaborative checklist that you can make a new copy of and share with people or a community. Each time I start a new app, BAM, I make a new activity from the template and I’m good to go. The template includes links to photoshop templates and official documentation from Apple and Google, so anyone within IBM is able to pick up the checklist and run with it.

I’d link directly to the template here, but sadly it’s only available inside IBM’s intranet for now. If there’s enough interest, I may rebuild it for use on LotusLive or IBM Greenhouse. In the meantime, look on and despair at the size of this checklist:

It frustrates me when a design problem with an obvious solution (at low cost!) isn’t fixed. This brings me to toilets. In particular, restaurant toilets. No, not the grotty public toilets at McDonald’s that you use only as a last-resort; I’m talking about toilets at upscale restaurants all over New York City. Even more particularly, restaurants that have individual bathrooms (as opposed to a big bathroom with two or more stalls in it).

This weekend I was at Le Monde for brunch, a nice french restaurant near my apartment. I went into the bathroom and was washing my son’s hands when someone started rattling the bathroom handle and banging on the door. It’s such a universally uncomfortable feeling – you are trapped in a tiny room with a toilet and someone else is urgently trying to get in. The best I can ever muster is to awkwardly shout out “I’m in here” or something equally inane. The thing that frustrates me is that there is an obvious solution to this problem, one that airplanes and busses have used for years:

The “occupied” sign is a modern masterpiece. It is linked with the door’s lock, so it takes advantage of what people are doing already (locking the bathroom door as soon as they go in). My only guess is that restaurants think it’s tacky to have an “occupied” indicator on a toilet, but that tiny sign would make for a much more pleasant overall restaurant bathroom experience. All you restauranteurs out there take note: put these on your bathroom doors!

I’ve seen a lot of design comps for iPhone, Android, and iPad apps that all suffer from the same problem: they were designed on a desktop monitor and weren’t reviewed on an actual device. This is an understandable issue for people new to mobile design. When making desktop web sites, photoshop offers a nice 1:1 view of what your app will actually look like. Mobile devices are a different beast, though. Devices tend to have tighter pixel density which means that items on the device look much smaller than they do when viewing them at 100% on your desktop.

Can you see me now?

Photoshop Lies!

As an example, look at the Twitter app for the iPad. On device, the user interface is easy to read and feels nicely balanced. Take a screenshot from the device and open it up on your desktop and the same screen has a dramatically different aspect: the type feels horsey and out of proportion. By the same measure, an illustration that looks perfect in Photoshop can prove difficult to read when viewed on the actual device.

Emulators Lie!

Worse than photoshop are the device emulators. The android emulator is the worst – while developing an app, I got into a comfortable bubble using the emulator to make sure that all the UI pieces were coming together. The problem is that the resolution shown on the emulator is vastly different than on actual devices, and what looks great on emulators winds up impossibly small in real life. Don’t trust that something is too big while using the emulator- try it out on a variety of devices to make sure.

Testing a mobile website in Chrome is not testing at all!

My biggest pet peeve is when someone builds a mobile website exclusively testing on Chrome or Safari. Sure, they both use the same webkit engine that most modern phones use, but using a desktop browser to test a mobile site will lead to heartache in the end. Desktop browsers are very useful for debugging, but it’s too easy to get lulled into smaller tap-targets and over-dense screens. Things that perform great on chrome on a top-of-the-line desktop machine often perform terribly on mobile devices, and elements that seem to position perfectly on a desktop browser can get all out of alignment when switching between portrait and landscape orientation. Keep testing on many different devices to make sure your mobile site is striking the right balance!

Practical solutions to viewing work on-device

Testing on devices can make for a more disruptive workflow, but there are some simple tricks that can help you work more efficiently:

Save ful-screen PNG images and view them on the device photo gallery.
It’s easy to do and very effective for android, iOS and blackberry and gives you 100% fidelity for sizing purposes. The downside is that you wind up saving tons of in-progress comp images, which can be annoying.

Use an app to get live previews on-device.
If you’re using a mac and developing for iOS check out Liveview. It’s an app that lets you get live previews from photoshop (or anything on your desktop) onto your device. Best of all, it’s free!

If you’re building a web app, test it on the device browser.
No excuses! If you want to test things before deploying on the internet, install a local web server (I use MAMP for my mac, but XAMPP will do the same) so you can look at your work on a real device.

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.

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!

Links

Follow

About

I'm Marty Moore and this is my blog. I am the design lead for mobile software development at IBM Collaboration Solutions. The opinions posted on this site are my own, and do not represent IBM. I wrote this wordpress theme by hand using Coda. I started with the excellent HTML 5 Boilerplate by Paul Irish & co. I used Compass to write the CSS, jQuery for javascript.