donttouchme

Apple didn't invent this either

2012-01-30T09:11:00.005-06:00

So, just the other day I read this article how iMessage is killing SMS. It draws some rather startling conclusions from the use patterns of, well, himself and his friends. I may have to remember this as an example of not looking at actual market data.

After his charts, there's quotes like this:

At this point it’s clear that the graphs of text message usage on traditional carriers are going to do nothing but slope downward at this point. In fact, they’re running scared, with AT&T already instituting new plans that are more aggressively priced in order to close the gap.

Because: Apple didn't invent this. I don't mean they didn't invent SMS, but they didn't invent closed message networks. Which means we can look to the previous iterations and study them. I am sure the true fanboi has never heard of BBM but stop and go look it up. Then search around for articles like this one where it seems the closed nature of the network encourages saturated populations (e.g. disaffected youth) to use it more freely than open networks, even when violating the law. In fact, BBM is a key reason the business-oriented Blackberry had such popularity for so long among the youth market.

Apple also didn't invent killing SMS. There has been a general downward trend in SMS usage in very high internet-use countries for a couple years. This seems to be all about the use of IP-messaging services, and tying them together. For example, Twitter works just fine over an app interface, using the data channel instead of SMS. Same for whatever your messaging method of choice is, like Facebook.

The other day LukeW defended the Apple fanboi as "How long til the Apple "fanboy" label wears off & people realize they really do deliver insane results from amazing products?"

But it's not the joy at using the products, or even those who stand in line to get the newest one first, or any of that consumption behavior. No, posts like the above are why I still use the term, and especially for US-based tech writers (whether full time or just bloggers) and designers. Ignoring history in such a deeply involved manner just makes you look dumb, and ill-informed, and do a worse job at coming up with solutions.

I guarantee Apple knows all this, and more, and is doing it all on purpose and from a position of knowledge.

How many apps have you made?

2012-01-28T14:36:00.003-06:00

Looking for work (both employment and contract/freelance) something has started to become weirdly clear. When I talk to people working on their first mobile app – or even startups working on their first product, which will be mostly a mobile app – more often than not the first question is "what apps have you built?" Often, they ask this again after seeing my whole portfolio, and otherwise looking me up. Frighteningly often, they ask literally how many apps (for a particular platform, usually) I have made. As though quantity is more important than actual experience, skills or results.

And before you say the obvious, that they are just checking out your experience in their domain, let me stop you. No one else asks questions like this. Building a mobile website? Just as one example, they are almost always interested in services, paper, graphic design, desktop web, desktop apps, and mobile apps. As well as your experience in mobile web. Actually many of them are multi-channel so prefer experience in all these. They ask about the whole range, not just for mobile web examples.

But not the guys launching an all new free-standing app. What is it with app-centric people?

The dumbest of phones is still a hell of a computer

2012-01-22T11:56:00.012-06:00

The other day I saw one of those all-too common charts drawing conclusions about growth rates of various currently-cool devices. Actually, no need to be vague, this one:

And I start saying, mostly on Twitter, "where are the dumbphones," but even just wondered, where is Blackberry OS, or Psion/S60, or Windows CE/PocketPC/etc. Or even the PSP and other portable game devices? I want more info on every computing device.

This leads, eventually, to this response:

@lukew Luke Wroblewski

@shoobe01 at some point phones crossed the line and became computers. I think a draw the line later in time than you~

And the more I think about it, the more I don't get why. But I always try to make sense of my gut reaction. In pondering this, two threads of have emerged that keep nagging at me.

Technology

I've used a lot of crazy stuff in my day. Some because I am old enough that PCs when I was in college were rare, so I had to take screwdrivers (and sometimes, a soldering iron) to them to get them to work. But also because I was lucky enough to be around other devices. I got to use the Aspen Movie Map in grade school, for example, which is why I keep wondering where the hell my jetpack is, and find few things to be world-changingly cool; I already saw that stuff when I was ten years old. Now get around to launching it, please.

My dad was also what you'd today call an Information Worker. He was employed as a writer for various organizations, including newspapers, universities, the KC police department, and the Federal Reserve Bank. He was issued computers as they came into being, in the early 1980s. I actually used – for school papers and so on – things like the TRS-80 Model 100, a very early (but surprisingly small and useful) laptop.

It was presumably amazing, but as I said, I somehow expected all this stuff by then. It was a portable computer ten years before I was weird to have a [giant, desktop] computer in college at all. It had a built-in modem (though pre-Bell-breakup, it came with a snazzy acoustic coupler, not a phone jack) and so on. I still recall how wonky the audio-tape save/load of data was, and of course when it wasn't a CLI, it was 100% scroll-and-select, character display only, and of course monochrome.

In every measurable way, a low-end, free-with-contract, contemporary featurephone is miles more capable a computer than any TRS-80. Go ahead, complain about the limited capabilities of the device, or how hard it is to load J2ME applications. There are many thousands of them, many are free, and they don't come on an audio cassette. And for the record, the Model 100 could have up to 32 kb of RAM. The first phone I picked up from my pile, is the not-even-current Samsung SPH-M320. It has... well, they are pretty obtuse about handset specs, but it has 40 MB of "memory." Some use that for both storage and RAM. Some just keep the RAM obscure. Anyway, it certainly beats the TRS-80 for storage, because it had none.

Unlike many other computers that followed, the Model 100 came with that modem, so was aware it should be connected to others. When you add in the vastly higher-speed modern mobile network, the cloud-based functions of modern mobile handsets, location services and other telemetry and carrier-based info, the comparison continues to be off the charts in favor of the stupid little phone.

Okay, let's just stick to smartphones

I could certainly keep going with this. There are an awful lot of messaging-oriented featurephones that have QWERTY keypads, and a lot with touchscreens. But what about another key issue with this and many charts which pick and choose their data: Smartphones have been around for a long, long time.

But even if you focus on those, where are they? No matter how world changing you think iOS is, can you really say they invented the smartphone? I don't think so. What about Blackberry, or better yet the Psion > Symbian behemoth, which was still the largest selling smartphone OS in 2011. The first real smartphone was the Nokia 9210 Communicator, released in June 2001.

And before you write this off as some nerdy little niche device, they sold 2.1 million of these in 2002, before anyone knew what a smartphone even was. That would be a little line starting just below the Mac line, and ramping up massively, immediately, and staying up above all the others.

Users

For a long, long time I've been aware that users often don't even accurately perceive the difference between a featurephone and smartphone. Which is... what? In the industry, we tend to define it as "Named OS" and "Ability to load arbitrary native applications."

So? What magic does that offer up? Maybe some actual use rates can help us out here. ComScore (though I borrowed these figures from a recent post by Tomi Ahonen) tells us that actual people use (aside from voice):

SMS text messaging – 83% Europe/68% US

Camera – 58% Europe/53% US

Web browsing – 33% Europe/39% US

Apps – 28% Europe/34% US

Before you quote back any of your own numbers at me: Are you sure? If you say, for example, that 95% of anything is on one platform, I can confidently say you screwed up. This is far too fragmented a market, and when I dig into metrics I find that most folks have used some identifier that under-represents featurephones. Or, it recognizes them, but it takes a bit of messing with the results to realize it, and the Smartphone-or-Desktop mentality means all Other data is recorded on the graphs as "unknown desktop."

I've had problems finding aggregate data, but GetJar (which only has J2ME apps) has handled 2.3 BILLION downloads. So, don't say Apps at #4 above absolutely means Smartphone, either.

Okay, but people love smartphones. Well, more so in the industrialized west, but since you may only care what people in NYC and the Bay Area want, let's go with that. A TNS survey of North America, Europe and advanced Asian countries found that customers seeking smartphones based their decisions on:

Look & Feel

Brand of handset

Input method*

Model

Operating system

I don't care if you and your friends try to decide first between iOS and Android, your users don't. They might by anything. They often do own any number of things.

This whole thing of iOS/Android being tops is what, two years old? Smartphones as a whole go back less than ten years. we have no idea what will be happening in five years. Closing your eyes to the future, and to history is not helping.

This is not all academic

And that misrepresentation of data is a huge problem.

If you've stuck with me this far, you are pretty likely to wonder why it matters. And it's by no means a navel-gazing, internal argument.

If you assume that everyone important uses iOS, and grudgingly agree to later appeal to Android users, you are missing a HUGE percentage of the possible users. And if you justify this with bad metrics, because you think only smartphones matter, you don't even know you're missing out.

Expand your horizons, seek out real information and don't ignore data that messes with your world view.

Carnival of the Mobilists #257

2012-01-16T17:32:00.018-06:00

It's an oddly warm, sunny day here in Kansas, so despite the wintery season, a great time for a carnival!

The Carnival of the Mobilists is a weekly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well.

Several of the submissions this week were written before CES – which I sadly didn't get to go to this year. Disappointingly what with teasers and a lamentably predictable industry, hardly anything happened to invalidate anyone's claims. Next, we'll have to see what gets announced next month at MWC in Barelona. Until then, check out those who challenge your ideas and bring you the mobile thoughts you may have missed.

Bucking the Conventional Wisdom

James Rosewell, writing for TheFonecast.com asks Will the CES trend for larger screens lead to poorer mobile web sites?

“ could it be that larger displays are simply more popular because they’re closer in size to desktop and laptop computers, while consumers are struggling to use the web on smaller-screen devices because sites haven’t been tailored to fit? ”

I can see an argument that excessive, misdirected attention to one platform can cause you to miss the true nature of the market.

In response to a recent post by Flurry proving that apps reign supreme, Oren Levine (recently of Nokia) says Apps beat browsing? Not so fast

“ Really? I don’t think the data support this conclusion. Flurry’s numbers show that 49% of that app consumption is games, which do not involve “accessing information.” If you remove the game time from the app numbers, the result is 48 minutes per day for apps versus the 72 minutes for browsing. ”

This is the sort of analysis I like to see. Even if I don't agree with it (I do), numbers can be sliced different ways. It's good to see analysis that bucks the party line, sometimes.

Advertising and Marketing

James Coops of Moby Affiliates brings us a long post on The best mobile advertising networks 2012, listing the best choice for a very large list of different needs or markets.

“ Advertisers need to think carefully about what they’re trying to achieve with their mobile ad campaign and nail the fundamentals (CPA? CPC? Blind? Premium?) before they let themselves get beguiled by the ad networks’ invariably impressive claims and boasts. ”

Mobile advertising has to meet the needs of your product and region. You can't just use what is comfortable, cheap or has the best industry buzz if you want to get results.

The effectiveness of QR codes has bugged me for a while. Not that they are ineffective per. se. but that the proof is always from very narrowly focused research or from marketing intent stuff. Terence Eden is trying to answer some of these questions, looking at the Real QR Statistics from TfL. And, then a couple days later, More *Real* QR Statistics

“ It’s hard to assess just how successful these codes are. The numbers are low, no doubt about that. As I mentioned in my interview for Econsultancy, a company needs to perform proper A|B testing to see how many calls, email, or website visits they would have got without a QR code. ”

Peggy Anne Salz, among other things the Queen of the Carneys gathers up a vast amount of data to surmise that Kindle Fire might be a lot bigger deal than we've all expected, and predicts some of what might happen as it gains traction in Europe. Kindle Fire To Heat Up European Tablet Market; What Can Advertisers Expect?

“ "Clearly, the one-size-fits-all approach for digital content across TV, PC, smartphone and tablet does not work, and this has significant implications for content producers and advertisers." ”

That quote is not Peggy's, but from Bruce Hoang, group marketing director of the Orange Advertising Network, but I think it sums up a lot of design challenges, not just the possibility of saturation in the tablet space in Europe. This article is full of links to the original data or analysis, so if you have the time, I advise really getting into it.

Digital marketing specialist Tina de Souza, asks us all, Would you close your doors for business for 2 days out the week? Of course not, so why are you.

“ retailers without mobile optimised sites are losing out on nearly one-third of business based on new m-commerce research. Alex Kozloff, Senior Mobile Manager at the IAB, describes this as businesses effectively closing their doors for two days out of the week. ”

It's way past time to address every device users might use. Numbers like this make it easy to justify, so march on down to the VP of Marketing tomorrow morning and get some budget for that mobile-optimized version you've wanted to do.

The OS Wars

In a timely submission, from the depths of CES, Rodrigo Arantes asks Who, besides Microsoft, is interested on another mobile OS?. I like where Microsoft is going with this, and think innovation should be celebrated (fragmentation be damned) but he has good points about building a community and competing in this market.

“ The gorgeous Lumia 900 is the wrong answer to the real problem that is: Microsoft is designing its ecosystem for itself, not for those who should use it and make it full of value. ”

Well, the answer might be that the smartphone war is not over.

Hoi Sta tells us that Android and Apple have NOT won the smartphone war and there's a lot more at work, and a lot less stability than you'd think from the everyday mobile tech press.

“ The current incumbents (Apple & Android) are less than 5 years old! There is still plenty of time for change, and change has been happening fast. That’s an average of just over 4 years for each incumbent, but the trend suggests change is happening faster. ”

Actually, I'd like to quote about half this article. I'll refrain, but it does a great job of summarizing the reasons that we should constantly be aware of the changing market and not discount any OS, for a long, long time.

Disruption and the Future

Antoine RJ Wright brings us a short A Wearable Computing Equation

“ Smart glasses + an efficient, clipable-to-your-clothing computer + savy voice/gesture control interface + integration with all parts of your life that matters + decent price for the core (computer + 1 accessory) = wearable computing > mobile.

The only question I now have is when. Because the parts are certainly there to pull this off. ”

This is a question I ask a lot, of many different products. We can do so much more with what technology is in hand, today. If I can't have a jetpack, can I have my wearable computer now?

Ajit Jaokar at Open Gardens writes about the rest of the US market, and asks Do you ever hear of the spectrum/bandwidth crunch in Boise Idaho?

“ The Operators want bandwidth – so they paint a picture of a Bandwidth crunch. The analysts and the infrastructure providers want to please the operators to get more business. So, they also paint a spectre of impending doom. The whole industry speaks with one voice (for once!). Here’s why the bandwidth crunch may be a mirage... ”

I personally think there is a bit of a connectivity issue in the boondocks, and even used backhaul issues on vacation as an example in my book, but I think that might prove his point instead; no one can trust mobile enough for intensive operations, so no one does. I wonder what we should all be doing about it, though.

I am sad to say I've missed the discussion of French triple-play Free, but Volker Hirsch – whose day job is the Director of Business Development for RIM – brought me up to speed with some interesting thoughts. Be Free! How an ickle player changes an industry.

“ Now, the really cool thing is how they are doing this. Since Iliad owns those masses of fibre networks, they can efficiently operate this. Now, they apparently start equipping their set-top boxes with femtocels and reserve a sliver of each of the bandwidth of those for their mobile network. ”

If you asked me 15 years ago where mobile would be today, I would not have guessed we'd still be SIM-locked, contract-bound, and subject to a relatively few telco-operators. When even big-name MVNOs can't cut it in the US, something totally different is really interesting.

And finally, in this chock-full week of mobile blogging, Bruce Burke of Gulf Bay Consulting talks about how embedded cameras are the next disruptive force in mobile commerce, of all things. Picture Perfect - processing images in Generation-M

“ That’s right, you can use the connected or integrated camera on your desktop or laptop computer, or your mobile device with integrated camera, to process credit card transactions with no dongle, cradle or swiper hardware required. ”

Any time a technology moves from the obvious (camera = family snapshots!) to the unexpected, it's the very definition of a disruptive technology and I can't wait to see more.

And the Winner Is

For my post of the week, I have to choose the one that gave me the most trouble quoting. Hoi Sta's article Android and Apple have NOT won the smartphone war was maybe not revolutionary, but was such a well-assembled argument about the reality of the world it's hard to resist.

Tune in Next Week

Next week's Carnival (#258) will be curated by Martin Wilson and hosted at his Mobileweb Company. If you'd like to be included in Martin's wrap up of the week's mobile writing, be sure to submit your posts by the end of the day, Friday 20 January. Unlike me, Martin will get his out on time the next Monday.

If you would like to host an upcoming Carnival of the Mobilists, drop our leader, Peggy Anne Salz a line and she'll be happy to set you up.

Of PADDs and Paper

2012-01-09T17:44:00.004-06:00

The most-commonly pointed to antecedant of the post-PC tablet (the iPad) is the Star Trek PADD. Like these:

IMAGE

Yeah, if you are enough of a nerd you know this already, but bear with me. This is not a device, but a series of devices, of various sizes, with or without buttons and so on. But the typical one is all but an iPad as envisioned by futurists of the 1980s

They are apparently not connected, or not well-connected as there's a lot of giving away of the devices to give information away as well. PADD apparently stands for Personal Access Display Device. Hmm. Display, like in the sense of reading and then discussing with people. If they want to enter information, or perform calculations or something they tend to go to some sort of cumbersome console or laptop-looking thing.

They are apparently dirt cheap, as there's no reluctance to share them, and an apparently unlimited number. They are so common that sometimes you see people trying to absorb different facets of info, with several out at once. "Catching up on paperwork" can involve a gesture to the literal pile of 6-8 of them on your desk.

I started thinking about this again as I was driving the other day. I spent an inordinate amount of time peering at a small screen to figure out which tiny road to turn onto next. Before you get on me, navigation is generally exempted from "no mobile phones" laws. It's legal, but it's not a super-good idea. I normally solve this by printing a map. I've used a RAM mount and tablet, and even it is not perfect.

What I really want is interactive paper.

I also got to thinking about the occasional concept of a small device that has no mobile radio, but is more like a control head for the larger device in your purse or pocket. They have been so unsuccessful or experimental I cannot find one now, but it's easy to imagine. And then I thought, what if we reverse that a bit?

Instead of a tiny device that lets the mobile do the heavy lifting of radios and processor, what about a large device whose only reason to be large is to be large? I mean, to get the screen, but you avoid letting the size mean it's a multi-core powerhouse and has 14 radios and so on.

What if the way to make a PADD (cheap and available) is not praying for economies of scale and efficient manufacturing, but setting our sights somewhere else. Instead of an iPad emulator, let's focus on:
- Cheapest, sturdiest possible screen. This is the most expensive and most fragile component. Avoid that as much as you can.
- Very low power consumption.
- No particular reliance on processing, so as little chip s you can get. Similar for memory.
- Very little connectivity. No WiFi, no mobile radio, no GPS.
- Very little interactivity. A touchscreen, I suppose (price point!) but maybe zero buttons.

All with the goal of being a replacement for a piece of paper. In operation, you have a few of these around the house. I suspect most have corporate sponsorship so were given away with other content on them. They may have been literally free to you. You wave or tap your handset at the tablet, and it wirelessly (it has one radio, sure) grabs the data needed. Let's say it's driving instructions. Then the maps for the route, at all reasonable resolutions, are pre-fetched during good connections and idle time.

This tablet is a pure consumption device, and for the rare situations where you ask it for something, or scroll too far, it has to be in range of the paired mobile handset so it can borrow it's connection and processing to get the information.

Sure, that's all just one crazy thought, but I hope someone is thinking seriously about far-out ideas instead of incremental improvement and how to best copy the industry leader again.

Why I think WebOS died

2012-01-04T11:23:00.003-06:00

There have been a lot of articles on why webOS died of late. A bunch are quoting internal naysayers, and generally talking about how hard it is to start a new OS, etc.

But I actually used the hell out of webOS out of the gate. I like to try new things, but in this case another manufacturer wanted a solid take on the new system, so I (and some others at the agency) soaked up all the data we could (legally) get, and did a deep heuristic eval on the original Pre.

Then I kept carrying it around. It was damned good. I say, better than any first generation OS has any right to be, and good enough I didn't overly miss out on a quite narrow app selection or any other key limits.

What I think killed it was stagnation. Here's a quick look:

WebOS introduced with the Pre on Sprint (US) January 2009.

Device sells out the first weekend it's sold. By the end of 2009, they have at least 6.1% (comscore) smartphone marketshare. Which is pretty good for 11 months, on only one carrier.

April 2010, HP buys Palm.

Rejoicing. Some stuff HP was doing on the edges with home media PCs and touchscreen-everything (including some stuff I was sorta working with) made this make perfect sense to me. Then... nothing happens. At all. Oh sure, like 7 months later they say they'll integrate it into all their products (again, I totally, 100% get this) but they do effectively /nothing/ for a year.

Meanwhile, until the announcement they are killing the platform in mid 2011:

April - iPads go on sale
May - First 4G (okay, WiMax) handsets announced
June - iOS 4 and all-new iPhone 4
July - First Galaxy-S devices in the US
August - Droid 2 available
September - Blackberry Playbook (and QNX) announced
October - Windows Phones become available
December - Nexus S released with Gingerbread (Android 2.3)
January 2011 - Samsung launches Bada handsets (it's an OS)
February - Honeycomb (Android 3.0) on the Xoom; Mango (Windows Phone update) shown off

So, not just lots of new devices and OSs and updates to choose from, but very believable promises. That's why I used the milestones above; because those were big stories, often for months before their release. Yes, you could rightfully say QNX is going nowhere, or worry about moving from bbOS, but they released a new piece of shiny hardware you could fondle in airport electronics stores, five months after the last interesting news from HP/Palm.

Oh, but at least the webOS message kept being muddled, with promises of OS upgrades also withdrawn, for example. And in May 2010 Matias Duarte left Palm. What killed webOS was that there was no good reason to upgrade your phone, or for your friends to get one during that year-of-nothing-much. This is not a static market, and even a few months without news leaves you in the dust. Note that webOS didn't even bother precipitously dropping but just stagnated and slowly bled out.

And, what makes me sad, is that there is no real reason for this. I've been working in/with several Big Dumb Companies when they have a major reorganization or merger. And it's not that hard to keep working on the Big Important Projects. Sometimes all it takes is one person really jumping up and down and yelling about it, when the executives are off in executive retreats

Now, I don't exactly know what happened to WebOS. The little bit of internal stuff I do know is not something I am free to share. But it seems as an outsider that stupid corporate policies -- or rather, a lack of any -- killed this OS. For no good reason.

Carnival #255 & Design for Every Screen

2011-12-21T08:33:00.002-06:00

This week's Carnival of the Mobilists is hosted by Peggy Anne Salz at Mobile Groove. I'm happy to be included again with all the other smart designers, developers and mobile thinkers.

The Carnival is a now-monthly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well. In 2012 it's going back to weekly, so is a great way to catch up with what's been going on in mobile on those busy weeks when you cannot read the 1650 items that came through your RSS and Twitter feeds.

Steven Hoober combines personal experience, market reports and business observations in this post to explain the need for a broader approach to design. In his view, we need to design for every screen and think touch points, not devices. It’s an important message indeed, and one that developers should not ignore. How do we all get there from here? Read on and find out.

I have continued to refine this concept, and gave a presentation on it at MoDevEast a few weeks ago. You can see that at Slideshare. And, for even more detail on mobile-specific processes and patterns, be sure to check out my new O'Reilly book Designing Mobile Interfaces.

The Carnival is the product of individuals sorting through submissions and using their own brains to decide what is important and how they all relate to each other. It's not some bot-generated list, but that also means it needs people to do this work. If you want to host the Carnival on your (or your company's) blog, drop a line to Peggy Anne Salz about it. Hint: it brings a pretty good amount of traffic also.

Diagrams from Designing Mobile Interfaces

2011-12-09T11:19:00.003-06:00

For most of my design career I've kept files of good ideas. Actually, that's not true. Sometime in junior high I started keeping cool images from magazines and putting them in folders by category, in an old file cabinet I had in my bedroom. As soon as computers came, I started doing the same with cool digital imagery, and scanning some of those old clippings. Google image search, and being less of a graphic designer means I don't do this anymore really.

But I do gather process, and keep good track of all the things I draw myself. Process documentation turned into an entire book. Since at least 2006 I have designed in a specific scale, in a specific way, and gathered all the widgets into a document (and often, library file) for everyone on the team to use.

Since about 2009, I've been sharing my Mobile Design Elements document with not just teams, but the whole world. Long ago I lost track of how many times it's been downloaded, but a lot. The page where you can get it (and every other stencil and template I know of) is always the most visited one of my (professional) websites.

This is key reason I wrote a book. I am happy to share the knowledge I have, and with it already well-organized, it just wasn't that difficult to reorganize all the information I had already gathered. Okay, that was foolish. It still took /forever/ to get it done, but I think it would have been patently impossible if I wasn't already gathering this sort of information.

As we say in the preface to the book, very shortly into writing it, we faced a serious decision about how to illustrate the book. The all too typical answer for pattern libraries is to use screenshots. So, I tried that. Our trial pattern was the Carousel for several reasons. And the first thing I did was snag some examples, and put little green circles and red x's on them to indicate good and bad examples.

And... it didn't work that well. Not just to me, but as I showed it to Eric, and others, it wasn't clear what you were looking at. So, I added in the bullet lists to describe what is good and bad. But really quickly I figured out this wasn't that much better. Readers could still be confused, or draw the wrong conclusion about what makes it a good pattern. It might encourage rote copying of specific solutions, instead of approaching them as patterns.

And also, I was trying to solve a problem that I feel has already been solved. We all write up UI/IxD design specifications all the time. Why not wireframe the examples? I already had what I called a "mid-level" diagramming style, which I had used for essentially this exact purpose; when building IA diagrams, and having to depict modular elements in a system, this is enough detail

Sure, some of these are so simple they are almost painful. I actually have one that is a featureless blue rectangle! But that's all because I am trying to show off only what is most important about the pattern. If it's about the arrangement of icons, and the interaction between frames and other elements. The icons themselves will just clutter things up and confuse the issue so they are blue circles. Blue because there's a code to the colors, and blue is graphics. Yellow is available page items. Orange is in-focus. Gray is, well, grayed-out.

If it's about an icon itself, sure, I'll have an illustration showing those details. Here, how it can be overlaid with more information.

But mostly, they are screens. And later on in the book the patterns start building on each other, and getting more and more complex themselves. Many items are on each screen, as well as sometimes things like gesture (or here, pen) overlays to explain the input. But they are still as simple as can be to communicate the key parts of the pattern. Well, usually. The example above has a detailed annunciator row because... I forgot to remove it. But it is extraneous detail. Oops.

And we did after all include some screenshots and photos. We didn't avoid screenshots just because they were a pain to find and deal with. I ended up capturing over 1,500 images of devices, and their screens. And a huge number are photos of odd devices and featurephones. Just follow that link to the Flickr set for that hard-to-find screenshot.

Anyway, what I am doing today – aside from telling you all about this – is sharing that document with you. Not just reminding you of the Mobile Design Elements document, but I have also posted the document I used to draw all the diagrams for the book. Not just as a PDF to browse, but the actual Adobe InDesign CS4 file so you can copy and edit them and use it in your own drawings.

If anyone wonders if I have library files, Graffle templates or anything else: no. I work in InDesign, and I know a lot of others who do also. I get good download rates off InDesign. But, since it's freely shared (with attribution, read the CC disclosure on the document) you are free to convert it if you want to. People better at those other tools than me have done so in the past for my Mobile Design Elements.

And for those who don't know, you can also open PDFs in Illustrator, and can use PDF images directly in OmniGraffle (not place them, but open and edit in Graffle directly). If you need help or anything, ask. I also did export all these images as individual Ai files, so if someone thinks that they could use those instead, tell me and I'll zip them up also.

One caveat is that I'll be tweaking this a bit over the coming days. Well, maybe weeks, but hopefully just days. I am adding in the Figure numbers from the book, and otherwise cleaning it up a bit. But that is taking kinda forever, and it's 95% good, so instead of making everyone wait more, you can get it now.

If you didn't notice, there are two links above to directly download. Though I don't promise to remember to keep these up to date. It will always be posted in the same place as the other design stencils, you just go there for the latest copy.

Win a Copy of Designing Mobile Intefaces

2011-11-14T12:32:00.007-06:00

With the gradual release of my my year-long writing project, Designing Mobile Interfaces, I think it's about time for the customary giveaways to start.

I don't want random drawings, so when I asked for a relevant contest, France Rupert suggested something like this. Great plan, as I have scads of devices:

How many of these devices can you identify?

This image is used in the Preface to the book as an example of how many different types of devices we referred to when finding and codifying patterns. Oh, and I have a lot more than this. I just ran out of room to take the photo.

So, the contest is to identify as many of these as you can. Some are easy, as they have the model number written on the front. Some are quite challenging, as they do not, and are old and terribly obscure, or are not even phones so might be outside your comfort zone.

Submit the list of them them in order to me. What order? Well, use this image to tell:

Do the best you can. Not just, "guess as best you can," but I mean that if you submit "Samsung Galaxy" and you are tied with someone who submits "Samsung Galaxy S Captivate," (and is right) they win. Be as precise as possible.

I will accept both model numbers and marketing names. Both "Captivate" and "SGH-I897" are acceptable in the above example. Oh, and no I don't have one of those up there. That's no a freebie.

Send entries through this form here, unless you already have my email, or want to send it some other way. Regardless, be sure to give me some way to contact you, or your entry will be thrown away

Leave a blank if you don't know the answer to one, but do include each and every number. Here's an example line.

17. Samsung Galaxy S Captivate

I am not trying to be a pain, but if I get more than like a dozen entries, it's gonna take forever to stick them in the spreadsheet to find out who won.

Contest ends in, say, two weeks. That's 29 November 2011 for those without calendars.

Bonus: I also have a spare copy of the fairly new 2nd Edition of Jenifer Tidwell's Designing Interfaces. You get both that and my new book.

Fine print: I won't be sure of getting any print copies until the first week of December. You will get it mailed after that. If you want an eBook, I do not have one of those for Tidwell's book, and am not sure I can give away eBooks. Still awaiting word on how that works. I might make you take paper, anyway. People who are at my house regularly enough they can just look through the collection are exempt from winning. In the event of a tie, I'll dream up some way to declare a winner.

Design for Every Screen

2011-11-07T22:07:00.002-06:00

Ever since mobile became really, really cool when the iPhone came out and every designer could happily show off their mobile credentials by having the latest one, there has been an influx of great new ideas accompanied by pithy little catchphrases. I've been somewhere between suspicious and dismissive of many of them, sometimes fairly publicly.

For all the good it does. Here I am mentioned being perceived as agreeing with Mobile First alongside Luke Wroblewski and Scott Jenson, up on stage no less. I never really did.

But lately I've been presenting a bit, and otherwise talking to folks all over the place, and therefore thinking more about many of these topics. First is that I promise I've never just been deliberately contrary, but none of my specific arguments ever stuck that well. And second you should know that I do not just make assumptions, but try to get to root meanings in order to act on information and do my job better. Just check out my work or how long the book is for proof. You can't shut me up when I get on a topic.

I also get tangential. Back on topic, I think that I'm suspicious and not embracing of a lot of these catchprases largely because I have gotten into this field differently than some others. I did art and graphic design from the time I could pick up a pencil, but was engineering-focused from Jr. High onward. I did grant-funded aerospace research in High School. I was the first researcher in the water tunnel at Wichita State University. But when I got to college I sucked at statics & dynamics, and some of the math, so eventually had to leave the program and fell back to art. Learned a lot of good stuff about competitiveness, criticism and understanding design reasoning there, so it was good in the end. I did graphic design work before I even graduated, which immediately (1995) was followed by "can we make a website also" requests from clients. Over a couple jobs I moved from my previous understanding of holistic design to true interaction, human factors, HCI and the emerging fields of UX. I formed teams and we taught ourselves how to be good designers of interactive systems.

So, despite pretty much getting into mobile from the web design side, it always involved data being fed from old systems, terminals for customer care reps, or email, or mailers or magazines. Or often, several of these.

I've been designing for multiple devices forever, since at least the late 1990s. The same stuff in print, CD, TV, web. Envelopes to put the brochure into. Etc. For another currently-cool example, I've been doing little hacks to dynamically resize and reflow content to different browser windows for years – so much so I keep forgetting that it's now called "responsive design."

If you think any one screen, size or channel solves your problems, think again. Netflix has to have a TV UI, sure. But have you noticed the Wii has a browser? Or what if Google TV stops being terrible, or Apple does break into TV in a big way after all? You'll need a 10-foot UI version of your website, and it's no longer just a real big PC monitor; just Monday, a report that console games are the #1 way to get online content to the TV. You might need a TV UI version today. Or yet another app for yet another audience. Technology isn't done growing, and sticking to any one technology is as bad as any other.

I've started calling this – at first somewhat by accident – "design for every screen." As you read on you'll notice it's not quite true, so I admit it's my own clever phrase. But it's closer than a lot of others, so I'll stick with it.

Devices and Channels

Another one of those marketable bits of phrasing from the past year or so was deciding that mobile context is no longer interesting. So I'll admit right off we're closing in on what I always called context. But "mobile context" has itself become saddled with improper assumptions of its meaning. Instead of throwing it away, I think we need to resurrect it.

Partly, because I cannot think of a better word. But also because I've been using the phrase for at least a decade. I went and looked a few weeks ago, and indeed have design documents from 2001 talking about the context of use. These were about the difference between consumers, several types of account managers, and call center employees, each of which had different levels of knowledge, training, etc. For a desktop web interfaces. And some had different use contexts, on the road, in an office, on specific hardware we knew about.

Mobile just added one more context when (around this same timeframe) I started tacking on mobile interfaces to the account management portals. But the then it added dozens. Doctors are not financial analysts, even if they both live by SMS and BBM. The growing variability in use of mobiles made them just like the desktop web. Meaning, lots of them.

Sure, there are some special contexts, because you use them wherever you are, instead of at a workstation of any sort.

And, the variability is bigger than you think. How many touchpoints do you have with a typical service, or company? Paper and ebills, other mailers, websites, and that's all supporting, before I get to the actual service which might be on the web or an app or a set top box. And more all the time: I watch TV on the website for my satellite provider more (when traveling at least) than through the set-top DVR.

Let me get back to some specifics, so we can talk about real products instead pure philosophical arguments. In the mid-2000s, I spent a long time doing a series of billing and account management projects, basically centered around some web portals. But only centered there; lots of other access points existed:

Desktop consumer web

Mobile web

Mobile app

Store terminals

Call center terminals

Call center logging

Call center voice communication to the customer (scripts, etc.)

Kiosks

Printed bills

Bill inserts

Envelope printing

Emails

And probably a couple more I forgot.

When I look back at my project files, it turns out most projects I work on are multi-channel, even if not multi-device. If you are just making an app, it's hard to not have a website, optimized for both desktop and mobile. And you better think of how it will look in app store, and how it installs. And... so on.

Design for Every Input

How about design for every input? I spend a lot of time reminding everyone that it's not just touchscreen, but also scroll & select; even lots of touch devices have keyboards and the very large category of messagephones are just 10-key scroll-and-select devices when folded. If you pretend everything is touch only, then your app looks stupid when it won't work right with the keyboard out.

But did you remember other inputs? Take a video sharing service (like some I have worked on). Why make users go to the desktop web or download an app, just to upload? We added MMS and Email services. Send to a specific address, and it goes into your account. And, this worked great. These are popular services. Do I need to remind everyone that Twitter is an SMS-based service? How can you leverage other channels to allow user input?

If you are not following my logic here, it's just an extension of the previous thoughts that everything is slightly more complex than it appears at first. Even if you stick to the desktop, web is just one input/output channel. You send customers emails, and then they can respond. They can call you. They send back bills in paper, no matter how much you wish they wouldn't. This is all part of the experience and you better address it all at the same time.

Design for Every Screen

Generally, when I talk about these principles, everyone agrees. I come away from client meetings with a task to show some multi-channel scenarios, or permission to architect the system with device agnosticism, so we can discover the right channels organically. And that works fine.

But like a lot of my processes, it doesn't work so well when I task others to do the same thing in my stead. I'll even make those basic deliverables, and then move on to another project while just supervising further design development. And it still falls down. So, we need to come up with some methods by which design for every screen can be carried out.

Well, not really. Because they already exist. Pretty much every design methodology will work just fine. Process I have published work fine, but let's go more generic. How about some basic tenents of UCD. If you can find a definition that doesn't get all hung up on a channel (really, Usability.gov only websites need to be designed?) you will find some of the same principles I've been talking about:

Audience – Personas, and anything else you can use to determine

Purpose – Use scenarios and use cases to understand how the product will be used, what tasks and goals exist, and what features will be helpful to get there.

Context – Yup, we're back to contexts of use again. And, you'll see again that context is a fundamental to understanding the use of using any system, not just mobile.

The difference between a lot of practice with these processes, and what I want you to do is two-fold:

All answers are valid – Do not set constraints, or make false assumptions. Let the process lead you to audiences, purposes and contexts you might not have thought of.

Actually follow a design process – This is key. No one does a design process anymore. Even people who gather at monthly meetings to talk about how great process is, read books and chat about it, end up just sketching ideas immediately. And the sketches are in their domain; if you are a web designer you make a desktop website, if you are a mobile designer, you make an iPhone app. Always.

To reiterate: cut it out. Pop open books if you need to, but gather information, answer your basic questions and develop whatever else will help you. Even if quick and dirty I say you should always be putting problem statements, principles of design and personas up on the wall. At the least. And you can do this in about two hours if you need to. It's not something that has to take six weeks, or six months.

Design for Target Experiences:

There's a third facet you'll need to stick to also, but it's less about principles than communicating to clients, so I didn't include it in the list. You may have already figured it out, and are sneering at my rainbows-and-unicorns world where everything we want gets built. In reality, of course, there are time/people/money budgets, and only a few things get built. So, you are still only getting a website

At first. You, as the designer, need to keep saying "the first release will..." and then keep putting up IA diagrams of the target experience. This is a great phrase. Unlike "problem statement" or some other things that cause grief and need euphemisms, "target experience" goes over great for all levels of IT and business folks. We want to be here, but we also know that pragmatically, we can only go this far... today. Keep saying it like that. Be and act realistic about the whole thing and you'll be surprised how much you get snuck in.

And not in an evil sneaky way. "Sneak in" would be one of those phrases you do not use in front of the clients. What I mean is, go back and look at some of those inputs and channels above. Your product will have email, SMS, printed bills, customer care. Or at least a few of these. Nothing is a pure website. So when you design for every screen, you are not surprised by a sudden request to make the email messages not terrible, 3 months after launch. You designed that, along with all the right error messages, and an easy upload scheme, right from the start. If it's getting built anyway (like outbound email), then your design goes in on the first phase.

That is because this also works very well with a lot of product development and software development processes. They like plans. Agile, for example, actually has a backlog of features. You can simply fill up the next 18 months with features, immediately. You are not perceived as annoying and overbearing, but as a go-getter, trying to make the product as good as it can be. The first person to show up with a list of functional requirements (or Stories, or Features, or whatever) has more influence over the final output than is immediately obvious.

Design for Change

Of course, you will learn as you go along. And you will learn you were wrong. User tests, analytics, customer-satisfaction scores, close rates, will all tell the real picture. Your second phase will become less important, and something else pops up, for example. But you will look okay, as you've got a target experience. Which is just a target, you must be willing to shift to the data, and say that out loud.

And, you will not be surprised by this – at least not entirely. Because your multi-channel, IA-based target experience looked at everything. You've at least got a sketch and a set of bullet points. When research comes back with a recommendation that you are years behind the times, and you better do something better than Usable.net for your mobile site, you can pull that out and be helpful and speedy.

As long as you are not "told you" and all arrogant about that. There's a limit to how much you can trust my client-relationship advice.

Implement for Every Screen:

A key gap to getting a good, holistic experience still exists: the gulf of execution. No, not Don Norman’s gap between stimulus and understanding, but the difference between what you give design and what comes out of the development team. I'll come up with a good phrase to replace that, someday.

I know some of you develop their own code, already has a terrific relationship with their developers, or believes your process solves all. I’ve been there and say: Some day it won’t. Even if everything is wonderful, can it be better? Usually. Even if not enough to mess with, find out why it works so you can fix your next company.

For everyone else, there's hope. And not the passive hope that this next development process or corporate reorg fixes everything. They will embrace your principles, which for this stage we can define as:

Design holistically – Systems, not pages, not widgets, not buttons. Just like I've been saying, design extensible, system-agnostic architectures, and end-to-end experiences.

Develop good objectives – Tie to the enterprise, and the product owner, but develop objectives for the team to embrace, and which can be achieved by them, and by the product you are building today, and tomorrow.

Own your design – You can't just put a target design on the wall. You have to believe in what you give to them (without changing your mind halfway through the release), and you have to keep reminding everyone to implement the existing plan with each future release.

Get everyone to buy into it – You can't do it alone. Even if it means adjusting or even collaborating get a plan and design everyone can get behind. Not just live with, but actually believe in.

I've developed a few tactics over the years to help with this. Actually, a lot more than this, but these are the key ones. And they aren't a trick or a stretch. The design process I've been talking about, the process you have worked through to get the the implementation stage is very much in line with good software development. All this makes sense to implementation teams.

Don’t walk away – Always stick with the project through development, at least making yourself available for questions, rework, changes and testing. Ideally, become integrated into the team, and attend daily meetings, test planning, and so on. Plan on this from the start so your schedule and budget accounts for it.

Set goals for everyone – Those business and user goals you should have developed at the beginning of the project must be translated into actual, measurable metrics. Then, try to make sure they get measured. Push for these to be the project level measure of success for the whole organization, instead of cost savings, efficiency of developers, or other internal measures.

Make object-oriented designs – Sometimes this is just called “modular re-use,” or other things, as “object oriented” is a larger set of principles (it all originated in development) and might confuse development. But I like the sound of it. The core concept is the same: Instead of designing every detail for every state, and building by state or building hundreds of items to bolt together, a few dozen modules are built and re-used over and over in common templates. Easier on you, and easier on development if they work that way.

Practice polymorphism – Sorry, it's another of my troublesome words; this time, not bad, just meaningless to many people. But developers tend to love it. Essentially, variations of objects are still the same object. If there are several variations of an on-screen module you design, make sure you express them as variations of each other so these are clear. This is a polymorphic item. Of course, if there is only one variant (omnimorphism) then that should be explicitly stated as well. Always keep in mind efficiency and re-use.

One IA for all – As discussed at great length above, a single IA diagram will give everyone a single, simple concept to hang onto. Enough, that developers will stick it on the wall of their cube. This is the best you can hope for; most developers won't put design objectives or personas on the wall, but this isn't bad.

As I said, there are other tactics and facets to remember, but they start getting pretty detailed again, so are almost a side conversation. Don't forget branding, and to communicate in a single voice. Good design will automatically be accessible, multi-platform and easier to manage and implement. And so on. I suspect if you have a design/implementation tactic, I believe in it also, and just say: don't forget to add it to your checklist, and start thinking about it as early as possible.

I have used a lot of my own experiences above. But those, and the long time I have been in mobile (or doing these other things) is not even important. I have worked with others who had their first mobile experience while I watched, well into the everything-is-a-smartphone era. And if they have a similarly technical background, or a systems-thinking approach, they do just fine approaching the design not as mobile first, but appropriately, bottom-up, and with every interface and interaction the end user needs.

Anyone can, and should be designing for every screen, every input, every device, and every context.

Web to mobile - Testing how well it will work

2011-10-28T09:15:00.014-05:00

Lately at work, everyone's gotten back into actually doing the right thing and being multi-channel. At least a little. Like, "make sure it works on the iPad." Well, that's easy to me. There are several attributes to this, but a good, key one these days is touch target sizes.

I was about to send everyone this very nice, concise writeup of General Touch Interaction Guidelines from the appendix of Designing Mobile Interfaces. Then it occurred to me it's almost too concise. I still run into many more people who design to pixels instead of real, human scales, for example.

So, I wrote up a longer explanation of how to do some of this basic validation. And as usual when I develop something not totally secret, and which I haven't shared before, I blog about it.

Assuming you are validating a design that is not exclusively built for mobile capacitive-touch devices, there are three key things you need to check for:

Legibility and readability – Design for desktop tends to assume good lighting conditions, but that's not at all true even there, and gets worse on mobiles. Even indoors, glare and viewing angles will change more. Start in Photoshop, knocking back the output levels by 20%; first each end independently, then both together. It'll look washed out and awful, but if readable, you are probably okay. Then, of course, test comps in the actual environment you expect it to be used in.

Click actions – Less about testing than evaluating your design. Does anything work on hover? Is hover required? If so: fail. Hover actions are fine for extra information, but stop making hover flyout main menus. If you can't, then at least tweak the design, and test the production code to make sure they can work on click. Most touch interface browsers interpret the first click action on an area with no click behavior as a hover action, so your menus will open. But, this is as prone to bugs as anything; in a recent test I performed the existing markup worked flawlessly on a dozen platforms. But not on the iPad. Oops.

Double-click actions – Never put another button, to undo (or commit a catastrophic change) in the exact same place as the initial button or link. People accidentally double click. If you just have to, then have a brief (100-250 ms) lockout period where the second click won't do anything..

Touch target suitability – The rest of this article focuses on that.

Make a Plan

Before you actually start testing on devices, or with any in mind, take a look at the test plans you have in place for desktop. I'll bet they are not "make sure it works!" Probably more like "IE 6,7 on Windows 7," and so forth. Very specific ones. You need the same sort of specific plan for testing off desktop. I'll ask you to try to find out what your customers actually use, instead of just making sure it works on the executives' iPads, but there's only so much I can argue about that.

Regardless, you need to set up a routine, so results can be reproduced, between individuals and from one release to the next. Define it all, so everyone is on the same page.

What devices, exactly? Most devices have generations and variants. For handsets especially, there will be regional and carrier variations that matter. "iPhone" is not enough by a long shot.

What OS? If there are readily-available versions, like the regular updates to iOS, specify which of these you test for.

What browser? I have fully seventeen on my one Android. If you don't define it, someone will test on their favorite. Or, you might miss that 30% of your customers use a third party client. It happens.

Zoom? For tablets especially, does it have to work perfectly at default rate, or are customers expected to zoom in due to the type of content included.

Orientation? Similarly, don't assume a default orientation. Things look different in landscape and portrait. And if you are zoomed in, sometimes in unpredictable ways.

Viewing Images

The crux of this test methodology is viewing images on actual devices. If you are very on the ball, you can probably convert pixels to real world measurements in your drawing program, and might even be smart enough to remember to do several conversions. If so, you probably aren't reading this as you know (or think you know) what to test for. So enough of you.

For everyone else, or just to make sure you are accounting for device specifics, we're going to get raster images onto the screen. Specifically, you have to load it into the browser. For this latest project, we conveniently share everything in Basecamp. If not, then just shove them into a dark corner of your website and send a link, or something.

Be sure nothing gets scaled. If you use a photo posting tool, or something, then they often get scaled to fit the posting tool. Avoid that.

So, why the browser? I mean, they are all full-screen, right? Well... sorta. There are scrollbars that appear on move for some. There's chrome, at least for the top of the page. And even just render oddities. Yeah, I know it's a raster image, not rendering the html, but why screw around with it and use some image viewer instead. Get it into a browser.

Be sure to scale the image up or down to fit plausibly. Even if the raster image is correct, it may be centered or just not loaded right. Compare to typical sizes, or the current site, or something else to guide you. Get as close as you can to the actual size it should appear as in production.

Oh, yeah, and if you want to use prototypes, go ahead. I tend to say, use it after this as another validation step, but if you go straight to prototypes, do not leave them on the desktop and use math. Get them onto your targeted devices one way or the other.

Measuring Physical Sizes

Moving on, now what we're going to do is measure touch targets on the actual hardware. I like to do this with a circle template. Yes, old school, but that's me.

I actually carry one of these in my bag at all times, along with a pad of paper, a ruler, pens and pencils, etc. Officially for drawing, but also useful here. These are still readily available but since you only need a couple of circles, your decision on buying is more on convenience. I use this little circle/square/hex one partly as its small.

The circle we are going to use is the 3/8" one, or 10mm if you are metric. This is the size of pretty much everyone's fingers. I did some primary research of my own, and everyone has the same finger contact area. Seems to be that kids are less precise, which makes up for their smaller size.

When I say contact area, I am talking about the fact that the user has an elliptical contact patch. We use a circle as people don't have it oriented any particular way. Variations in individual physiology, as well as different ways of grasping and using make it hard to tell if the ellipse is oriented any particular angle. I found no correlation yet, so call it a circle.

Most devices will only accept input from the centroid of the contact area. In this way, you can tap on tiny, tiny targets still. But, as other items intrude into the target area, the chance of errors goes up. I've found that accuracy (CEP, if you wish) is close to the size of a finger. So, I've fudged the distinction on purpose.

You might ask why you don't just poke the design with your finger. Two reasons:

Interference – The device is touch sensitive, so you'll scoot it around. As long as you grab the edge of the template, it won't be sensed. It is dielectric, so if you touch the template on the screen, it will be sensed.

Occlusion – Your finger is not transparent. It's easier to see what is going on with the template.

Science – Actually, repeatability and regularity. Why rely on your finger when it is different from everyone else's? A perfectly-repeatable proxy is the way to go.

Passing and Failing

To test, what you do is overlay the template on every link, button and UI widget on the interface. In all states. If there's a pop-up, test that, and be sure to test in place, over the top of whatever it is likely to appear on, for example.

You will test for:

Size – The visible target should be at least as large as the 3/8" contact area in at least one axis.

Proximity – No other touch target should be within the 3/8" contact area at any point.

Overlaps – Like I said above. Will any transient condition items be able to click past themselves. Lists, pop-ups, etc. Make sure edge-adjacent selections are over blank spaces, or they are modal and require an unambiguous dismissal action.

Edges – As shown below, if you have something right up against the edge of the viewport, you can use a sort of Fitts' Law behavior to live with smaller targets. Unlike relative pointing devices (mouse, direction keys) it's not infinitely deep, but it can be functionally deeper than what is visible. This is ONLY for overlapping the bezel, not any other borders or edges, so is only so useful for web design, even on full-screen mobile browsers.

So, for example, this "View Product" link is pretty safe.

There are no unlabeled areas that are clickable, just links, and nothing else is adjacent to the center. Good link. Pass. Let's try these two iconic elements instead.

The big cart button is safe as houses. But that little delete icon is both very small, and rather too adjacent to other items. Does it fail? Well, it depends.

Legal – Does it pass the basic size test? If not...

Almost legal – Is it almost legal? I find that 20% smaller targets are fine for deliberate or secondary interactions. If not...

Adjacency – If it's too small, so what? Is there something else that is a click target within the full-size (or worse, the 20% reduced) circle? If so...

Consequences – If accidental activation of another link occurs, what will happen? Actually, you need to pay attention to this even for adjacent items when the circle is up to double the normal test size. Or, for any action on the page. People slip, or misunderstand, so check out the principles of cancel protection and otherwise avoid letting users make catastrophic actions easily.

Orientation or Zoom – For each test, is the user likely to zoom, or switch to landscape, and if so does this help? In the example below, the delete button in landscape is just big enough to pass the 20% reduction in size regardless of accidental click actions.

Here, the delete button passes okay at landscape. And all the actions have escape mechanisms. They simply open spaces, or load pop-ups. And accidentally pressing the trashcan loads an undo in the line item right there so it can be undone easily.

Oh, and one last thing. Check every widget. This scrollbar, for example, is a bit dicey. It is sometimes just fine, but sometime very close to the checkboxes. Which might not be bad, but it might be. Again, you have to know what is adjacent to it, so you can tell.

Fixing Your Design

This is all about being pragmatic. Ideally, you designed for all platforms up front, and serious errors require going back to the drawing board. But often, we don't have time. Or, the iPad access is just an offshoot of the desktop web, and you have no real time to address the changes.

You need to look at the last bullet list, and decide how important errors are. You need to think about all platforms, if you cannot make custom versions for each. Does spacing out for iPad, for example, make it stupid on the desktop? Can you just implement interactive changes to reduce catastrophic consequences, if not the actual click errors.

Ideally you will design for mobile, or multi-channel, from the ground up. If not now, then certainly for the next release. Start thinking like that by reading up on the principles of design, how to design for mobile first (or always). And get lots of specifics by grabbing a copy of Designing Mobile Interfaces or checking out the resources on the associated design wiki.

Carnival #253

2011-10-24T06:15:00.003-05:00

This week's Carnival of the Mobilists is hosted by global mobile strategist and author Tomi T Ahonen at Communities Dominate Brands. I'm happy to be included again with all the other smart designers, developers and mobile thinkers.

The Carnival is a now-monthly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well.

Talking about tracing... Steve and Alison Hoober on their blog have a very useful guide to showing smartphone-related hand gestures in guidebooks and tutorials. They have really put some thinking into it, to make the gestures intuitive and consistent.

Well, in all fairness, the best of these gesture libraries are not ours, but a collection of many others folks'. Be sure to check out the whole list of them, as well as many other Drawing Tools & Templates at the Wiki in support of Designing Mobile Interfaces, which should come out in just the next few weeks.

Next week the Carnival has no scheduled host. If you would like to host an upcoming Carnival of the Mobilists, drop Peggy Anne Salz a line.

Stop that desktop thinking

2011-10-22T12:26:00.008-05:00

Since all my employers are east coast, about six months ago I stopped changing my watch every time the plane landed (or took off... I never could decide which) and just leave it on Eastern Time.

And I am comfortable with this. I just have a part of me always out there, and then adjust the time in my brain. Not a big deal, really, as I do lots of stuff on 24 hour clocks and am adjusting the readout in my brain anyway. I also asked a friend who was formerly Air Force special operations, and he said when flying about the world, you just leave your watch to UTC, and know where you are.

But that's a watch. It's deliberately an old, mechanical item. Mine is specifically one of those that winds itself as you move about, so as cool as an iPod Shuffle watch would be, I don't have to worry about it failing to synch, running out of batteries, etc. Okay, now, tell me why my laptop is always set to Eastern Time. Better, why should I have to change it myself through a control panel? Why, if I do change it, do a series of applications yell at me to find out if I want to change the time zone within themselves, separately?

I think it's because of something I think I'll declare Desktop Thinking. Desktops are dumb. They are shiny and "easy to use" but are just a few generations from terminals, used to access the unfriendly mainframe, and there's still this same mentality. The user will perform operations, the machine will respond when it feels like it. The user requests information, or to begin a process, and the machine starts doing it. But not a moment beforehand. Embracing mobile, on the other hand, means you think about information the user needs, you don't ask for information you already have, and you don't throw away anything the customer entered or might need later on (within the constraints of privacy).

Google Calendar is one of those tools that (at least on the website) incredulously asks if you want to change the time zone. Apparently, they are of the mindset that changing time zones only accompanies selling your house and moving across the country. Whereas even this typical desktop website, just for one example, takes a stab at determining my position, and defaults the information to that region.

Which brings up, believe it or not, some thoughts on location I touch on in Designing Mobile Interfaces. How do I set my watch, or make sure that my laptop is in the right time zone (or that it's set right with Daylight Saving changes)? More often than not, I consult the clock on my mobile handset, of course.

Location only needs to be as accurate as it needs to be. If you want a weather report – or to know what time your meeting starts – there's no reason to turn on the GPS to find out where you are. Very rough location, often just to within a few dozen miles, is just fine.

But it needs to be there. Don't disable functions in favor of only offering the highest precision. If an approximation is good enough, or faster, use that.

This is some of the stuff I am talking about when I say that context matters. And when I say that it's not the same as user intent, or user goals or whatever else you might want to use to replace the notion of "context." I mean that the device should be intelligent. And as much as I like – say – Siri's way of being aware what you just did so the next task is more useful, I want it to do more. Something as simple as knowing what time zone I am in, and reacting appropriately to that is what you might call pre-emptively contextual. And now that I write it, that sounds great.

Mobile tends to do this. Sure. But only at the most surface level still. I think a lot of apps do this just because they get the time from the handset. But I still see Desktop Thinking during web and app development, even on mobile. The user will sign on. The user will pick a link. Even just: once the user clicks our icon and launches the app. And often I ask, why? Why can't we make a widget, or a notification that lets them launch the app when we tell them something neat has happened, or... anything that predicts and offers information at a glance, or helps the user when they didn't even know they needed it?

Think about not just your assigned silo, but how your user can get real benefit from the information, intelligence and processing you have available.

The three levels of authentication

2011-10-19T15:48:00.008-05:00

Aside from the chance to get rich and famous, I wrote Designing Mobile Interfaces basically because I think it's a good thing to share knowledge. Much of the writing on this blog is the same way.

But often, I forget when something is useful. Yesterday evening, someone copied me on a long email which was: a thing I wrote a couple months ago about some of the key IA principles behind authentication, authorization and so on. The deal is, I wrote it in like half an hour, off the top of my head. Because it's the tenth time I've had to write such a thing, since so many people do it wrong.

So, this is a perfect example of something to sanitize, and share. Instead of overly-editing to be chatty, it's pretty requirements-like. Ask if something is confusing or too briefly defined. Or, tell me if you just straight-up disagree.

These assume a website. Application authentication can be similar, but is not addressed here.

There are three levels of authentication, not two:

Anonymous
Identified (or Recognized)
Authenticated

And it is important that you never call the middle one "cookied," "zipped-in," "cart remembered" or anything either very specific, or based on the technology solution. The middle tier is as important as the other two.

Each level of authentication has multiple characteristics:

Presentation Authorization – A certain set of information (general, specific, or personalized) is displayed on the screen or can be printed. There is no direct method to change this level (such as hidden content with a link).
Transactional Authorization – A certain set of transactions (general, access-controlling, or liability-inducing)
Management Authorization – Most users can only manage their profile. Some can manage multiple profiles. Some (e.g. customer care) can perform certain functions over multiple profiles. These are further subdivided into having degrees of Presentation or Transactional Authorization for each of the other profiles they can view and/or manage. Even if not in scope at the moment, you must consider it during the design of the system

Anonymous:

A customer visiting your site, who has never visited before or is visiting on a computer without a cookie (such as a friend's or at the library) will not be identified, and receives only general content. There are other schemes aside from cookies, but they are most common, so assume that for planning purposes.

Links to various types of personal information or authenticated-customer services are displayed, and if selected will either:

Allow use, but will not save information. The kitchen planner today works like this, and intercepts for authentication on save or exit.
Inform the user they are only for customers, providing significant amounts of introductory content and a link to authenticate or register.
Intercept with an authentication dialogue, demanding credentials (or enticing to register) or allowing the request to be abandoned.

Depending on the type of information or capabilities of the service.

Identified:

The customer has visited the site before while authenticated, and the client computer can accept cookies. On this visit, Lowe's.com recognizes the cookie, matches it to a user profile, and presents complete customer information (minus the usual masking of values that should not be sent over the internet, such as passwords and credit card numbers).

The customer can perform simple transactions that do not induce access control changes or liability, and are not too destructive (without recovery). They may not change access-controlling or liability-inducing information. They may have limits on changes to personal information. For example, items will be able to be added to or removed from the Home Profile, but deleting the whole Home may not be allowed. The following is a sample set of transactional features that are not available to the Identified session:

Purchases
Change password, or recovery information
Change or add mailing address
Change or add contact information
Change or add payment methods

The method of restricting transactional access to payment information and authentication credentials may be most seamless to the UX if view access is also not provided, but this is not inherent in the rules.

Authenticated:

The customer has provided a username and password combination which is successfully recognized by the system. There are two methods to provide this:

The customer entered the site as an anonymous user, and either deliberately signs on, or attempts to access an unavailable transaction (such as checking out with purchases). They enter both a username and passcode.
The customer has entered the site and been automatically identified. When attempting to access an unavailable transaction (such as checking out) they are intercepted, and provide their passcode only. The username is pre-populated (or not displayed, but a proxy such as the customer nickname and avatar are displayed) during the request for additional credentials.

This may have happened due to an earlier transaction, and the session may continue to be active. Authentication does not have to be directly related to the service requiring this level of access control.

The customer then has complete authorization to view and transact with all portions of their profile as long as the session does not expire.

Access-controlling:

Any feature that, if maliciously modified within one session, could prevent access by the owner, and/or redirect information about access away from the owner. Changing of credentials or contact information, basically.

Liability-inducing:

Any feature that, if maliciously modified, could result in unauthorized financial transactions, or one that includes information that could lead to valid transactions being intercepted or otherwise repurposed.

Cross-Channel:

The same identifiers should be used in all channels. All websites, all applications, in store, at home. Rules may vary between the access points. For example, the mobile application (and website) should (probably) sign on with the same credentials, then retain the customer entirely authenticated, relying on the device's security.

Identification Management:

A cookie or similar key is placed on the customer's client machine. This is checked at each authenticated visit, and if no cookie is found a new one is created. No special first-use case must be developed.

Since this key is on the client, and sent in plaintext, it must be secure. Do not place any intelligence in the key. It should not be the customer's name, location, customer ID, Keyfob ID, MEID, time created, store, card number, SSN or any other characteristic. It should not even be a random or encoded value using any customer-identifying information as the seed. All too often, these are cracked, with bad PR if you are lucky. It should be an entirely arbitrary key value, and nothing else.

Make this key value as short as possible, to reduce bandwidth. Remember to not pad values for expected total sizes of the data store. The first users to register can have a key with the minimum secure/intepretable length, and then additional characters are added as the service grows.

The key is sent to an authentication management service when the customer enters the site, and is looked up in a table to associate the key to a customer. That customer then has that authorization level.

User Management of Identification:

It is usually best to simply set the cookie for all users. Those who do not like them will disable cookies across the board, or for our domain.

If there are concerns, then a method can be provided for the user to manage this:

A checkbox on the authentication dialogue (set to saving the cookie by default).
A setting in the user's profile.
Help documentation should be provided with as much information as possible, and links to privacy and security policies

Note that explicit signout is another way for customers to "Manage" their cookies, by clearing them at each session. However, this is a manual, one-time process.

Timeout:

Identified sessions do not time out in a manner visible to the customer. They may continue using the site in the Identified state forever.

When an Authenticated customer session times out, it seamlessly falls back to the Identified state. There is generally no need for notices, warnings or the presentation of the authentication dialogue. When the user next needs an Authentication-required feature, they transact this as usual, from the Identified state.

Due to the seamless switching, this can increase security and be beneficial to server balancing. Sessions can be much shorter, as short as 5-10 minutes, without serious problems. Some cases may need to have special exemptions. Checkout, for example, may need to be extended or exempted if the process routinely takes customers more than the otherwise-recommended timeout period.

Explicit Signout:

When the customer explicitly signs off, they will return to the Anonymous state. This state should be persistent, and the cookie cleared.

Failed Authentication:

If an already-identified customer fails to correctly enter their second credential (the passcode) enough times, they may either be locked out entirely, or revert back to the Identified state, and only be locked out of re-authenticating. This decision will have to be made by the team, and Security.

Any lockout should send a message out of channel to alert the customer of a possible attempt to break into their profile. Usually, this will just be an email, but the system should be built so it can send to SMS or use other channels as those notification capabilities are built.

I don't care, and neither should you

2011-10-13T07:38:00.006-05:00

With a (briefly, before I leave this job) new UX manager, I ran into one of my other terminology issues. I enjoy saying we solve "problems," which bugs a lot of business people, as it implies that there are problems! Which is true to me, but I often have to say "challenges" or "opportunities" or other (frankly) bullshit.

But today's special challenge phrase is "I don't care." What I mean is that "either of the two options presented can solve the stated problem equally well. I have no personal opinion."

Of course, what people hear is "I could give a crap about your stupid company and this pointless project, and am just phoning in my work on this one." Of course, I am aware of this, so never use it in front of clients; it's an internal term for the design team, which I usually remember to explain first. Usually.

Ideally, I'd have another term for this, so someone offer me one.

Because, I cannot just say that I have an opinion on everything. This speaks to the core of every issue I have with interactive design today. UX/HF/HCI/IA/IxD/Etc. has become such a populist thing that a lot of practitioners are untrained, or poorly-trained, and even if experienced are unread and do not get the basics. Sorry, but as far as I see it, it's true.

That leaves everyone to work their design the way everyone else nearby, in marketing and product development, seems to work their jobs: opinion, previous-experience, anecdote and whoever has the most political power.

But I base my design decisions on my understanding of the scientific underpinnings. See how we laid out Designing Mobile Interfaces (on the web also); the patterns are typical interactive design communication. This works, and this other thing doesn't, because people might get confused... But the beginning of each chapter (and a lot of information in the appendices) cover why this is true. Cognitive psychology and human physiology underlie all of this. If you don't understand these, or at least trust people who do understand them, then you are not pursuing UX from an informed, repeatable point of view, and are just drawing whatever seems pretty at the time.

This same philosophy is why we distrust market research like focus groups, and get strict about how we interpret usability research, surveys, and analytics.

So, when I present or see two or three or five options for a design, once the obvious issues have been pointed out, I sometimes have no opinion. I have no personal opinion, and it needs to be up to the marketing intent, branding, visual design, or we need to make sure that there is no other secret requirement (e.g. unexpressed future needs) that can drive us to one solution or the other. There are plenty of ways to decide on one or the other, but if two options are equally valid solutions from a UX point of view, either look harder, or feel free to have no formal opinion.

Communicating Gestures

2011-10-12T07:25:00.009-05:00

When I started working on gesture-driven systems, I made do with some terrible symbols and descriptions. Eventually, I evolved a few existing ones, made hands that made me happier, and codified some symbology (the circles for tap vs. hold, arrows) to be a system.

And I have been happy with it, using it on dozens of projects. Until yesterday, when France Rupert made me aware of this new, quite well-conceived system that P.J. Onori developed. I'll let him explain in detail but basically, he approached it from an iconic communications point of view.

To this end, it reminds me more of why I wanted gesture icons. For the way that I have always used keypresses or direction keys (along with focus areas) to communicate the reason for a state or screen change.

If there's anything missing from analysis of gestures, or development of icons to communicate them, it's a visible awareness that this is an evolution of interaction, and it's always happened. When I first drew my gestures, I first went to very old drawings I had used to describe how people open boxes, turn pages, cut things, or pick up phones. Which I used long before there were touchscreen handsets.

I am also excited by this sort of work because it means there's a lot of people using diagrams to design and communicate mobile interaction. I feel there's far too much talk about prototyping, even though there's lots of (justified) need to make specifications still. I feel the focus on prototyping sets aside centuries of designing by drawing as I sometimes call it.

P.J.'s discussion, and some responses, also made me aware there are several other gesture libraries I didn't know about, so I finally added a whole section to the Drawing Tools & Templates section of the wiki for the Designing Mobile Interfaces book. If you don't want to go there, here they all are, gathered up:

Gesture Icon System by P.J. Onori (someRandomDude), currently a prototype, but eventually vector art in all the likely platforms.

Gesture Icons by Ryan Lee, paid download, for multiple platforms. Includes some kinesthetic gestures. (PDF, Illustrator, EPS)

Touch Gesture Reference Guide by Luke Wroblewski. Set of stencils and other supporting documentation for understanding gesture. (PDF, EPS, OmniGraffle, Visio)

Open Source Gesture Library by GestureWorks. Usable icons plus posters and other documentation. (PNG, PDF, EPS plus Gesture Font Family in TTF/OTF)

GestureIcon Touch Pack by Ron George. Very abstracted icon set. (EPS, PNG, Illustrator)

Touchscreen Stencils distributed by Kicker Studio, drawn by Rachel Glaves for Dan Saffer's book ''Designing Gestural Interfaces''. (OmniGraffle, Illustrator, Photoshop, Visio, Fireworks, Axure).

Touch Notation by Matt Legend Gemmell, another very abstracted system. (Photoshop, Illustrator, OmniGraffle)

Mobile Design Templates by Steven Hoober, a few pages of this large library include gesture icons, on-screen and kinesthetic. Used in the book ''Designing Mobile Interfaces'' (PDF, InDesign is in section above).

If this isn't enough, I also have never been totally happy with voice or haptic input and output iconography. This is the sort of thing I have done, but it's not perfect either.

Now try showing orientation changes, or proximity to an RFID reader (or another device), or the type of haptic response. We can specify all this, but there's a lot to be said for innately understandable graphic libraries. As much as it disrupts my life, I look forward to more, and better solutions.

4ourth Mobile is a Thing Now

2011-10-06T21:03:00.005-05:00

Long before I had a day job, I freelanced. I did design work when I was in Junior High. Actually, I recall that first paid job (sure, my dad worked there) they weren't happy with the results. Probably worth thinking about more and writing a whole post about how early failures made me the type of conscientious designer I am today. Later.

I've made over half my income some years from freelance or contact work, and while it petered out in the past few years, when we all lost our jobs a year ago, making a virtual agency seemed a natural. I've been sorta calling the freelance work I do since then part of the 4ourth Mobile brand, and the Designing Mobile Interfaces book Eric and I are writing has a strong online presence at a wiki under that same site.

But I haven't really marketed it in any particular way. Well, now I probably should get on that.

Yeah, maybe this is old hat for everyone else, but I've never actually bothered to incorporate anything before. I just faked it, filed a Schedule C and made do. Accountant friends forced my hand here for tax reasons, but really it's a good idea.

So, consider this the official announcement: 4ourth Mobile is a thing. Call it a virtual mobile design agency. If you think well of one of our tweets, or blog post, or The Big Book of Mobile Design, contact us. We can do training, or design, or user research, or just chat about your needs and see if our concept of a mobile strategy is the same as yours.

We're even multi-national, and can travel, so whatever your needs, ask and we'll talk about it.

Sample page from Designing Mobile Interfaces

2011-09-29T08:31:00.005-05:00

We're all the way to QC1, which means Quality Check, as I get it. I think there's a QC2 in a couple more weeks.

It's tedious work, but also thrilling to see it not in Word, or on the web, but actually in a book format. Enjoy:

And don't forget to pre-order before it comes out in November. Now 560 pages, but Amazon shows much less than that. I suspect you will not be able to get it for $30 when it comes out.

The most interesting thing about the Kindle announcements

2011-09-28T18:50:00.006-05:00

I found Amazon's announcement Wednesday to be very interesting. Almost unexpected. And I don't mean the Fire or Silk parts. Or the pricing of the Fire.

What I found really interesting was this:

Yeah, just the line of new products. But that's it. A whole line of products. A new low-end, improvements to the e-Ink, removal of the keyboard (more on that later). Not just retaining the old models, and maybe lowering the price, just to appeal to cheapskates.

You'd think that based on rumor, and pretty much every other review or comment coming up to this, or today.

A key reason I like seeing stuff like this is that it continues to vindicate the scope of Designing Mobile Interfaces. A year ago, when Eric and I started writing it, there was lots of discussion about how much we'd focus on iOS. "Um, not really at all." So, also Android... And Blackberry?

No, there are plenty of those sorts of books. We made a mobile design book. For all of mobile. Check out this pattern on Keyboards & Keypads for one example.

In there we talk not just about the best way to make a touchscreen keyboard (and we don't just say "do what iOS does" but also hardware keyboards, also keypads and triple tap, and even scroll-and-select virtual keyboards. Wait, why does that sound familiar?

Not just because my PVR does it, or my GPS, or I examined a lot of products and it's just a way to do it, not that... Oh, yeah. Because the new low-end Kindle uses that exact system.

And why? Hell if I know. I don't work there. I'd guess that they found people don't type as much as expected. And it helps make the price point, and so on. They don't do this stuff randomly.

And that brings up the point you actually care about. If your mobile strategy is to make an iOS app, or you are updating your product to have a color touchscreen, and you abandoned the old way, you are probably doing it wrong.

Amazon is not good at everything, but they are pretty good at some stuff. And selling eReaders is one of those. I am not the sort of designer who takes everything Amazon (or Apple) does, and slavishly copies it. But Amazon is a mass-market success story, and with the Kindle they had amazing success with a pretty new class of product, which they are clearly trying to make available to everyone possible.

New technology doesn't always have to be expensive, new versions don't have to be cutting edge, and the low-end is a huge market. Are you focusing on the bigger market, or just what you think is cool?

If you like everything I said, and think your product needs some thinking like this, maybe we can work together. Go ahead and contact me about it.

Tiles, Widgets and Icons

2011-09-22T11:40:00.021-05:00

Ever since I read Itai Vonshak's tweet about John Dvorak's article on "the serious flaw" with Windows 8, I've been vaguely annoyed by this misunderstanding of how an interface should or could work.

Windows 8 is, conceptually, at the presentation level, an offshoot of concepts we've first seen in Windows Phone. And Windows Phone (like everything else in the world) has been evaluated (by tech columnists) as a straight-up iPhone competitor. I gather that Dvorak thinks some people sat in a room in Redmond and went "I've got it! We'll make all our icons square, and blue! That'll differentiate it from that darned iPhone. We'll show those meddling kids!"

I don't work for Microsoft, and didn't do any work on any of this UI. In fact, before we go further, I don't own one of these, and don't particularly have a warm place in my heart for Microsoft. But fair is fair, and I'm judging this on it's merits, as I see them. As soon as Windows Phone was announced (as I recall, even before we saw images) it was pretty clear that they were taking a quite different, not just putting their spin or skin on the "compete with Apple." I think it's a rather good approach.

If you design the system (any system, of any size) to be entirely about running applications, then your application discovery method better be solid. When Dvorak talks about how he recognizes icons, or accuses Microsoft of all but switching to a DOS CLI, this reveals his misunderstanding of how mobile (and some other clever systems) can work.

Instead of finding and running apps, you can be served information immediately and contextually. Skipping the bigger discussions of push messaging and contextual surfacing, Windows Phone (and I presume from the images, Windows 8) tiles are widgets (ask me later why this links to "icon"). Widgets, in this context, present little snippets of data, or even useful bits of data next to other bits of data. Immediately. Without having to explicitly launch them.

Aside from generally observing everything I can about mobile, I have a Windows Phone user right next to me at work. I asked him today to demonstrate, and he demonstrated exactly this use of it.

I can just open it up, and look at it, and scroll to get more information. If I need to know who did that, I look to the side and there they are.

And no, he's not a designer, or particularly a mobile guy, and I didn't set his phone up for him. I've never even touched it. Based on many other observations I have made of all sorts of mobile users, a lot of them use their devices this way. You don't drill into the app, or even launch it. You just un-sleep the screen and glance at it. Maybe, just maybe, you have to scroll a little ways. Or, I claim from all these, they want to.

I still feel the same way I did about Widgets in 2007 , and increasingly think they are not just a good thing to have available, but a key attribute, and may become (like Windows is now pushing towards) the one best way to get to information.

There are other platforms that have widgets. My Android handset is almost entirely widgets, using icons only when there is no good widget. There are related ways to work in this sort of mentality, like WebOS which leaves the application as a sort of widget/tile on the desktop; the set of them changes moment to moment, but they aren't just launched and then disappear when you go to launch another application. Not perfect (or even much alive) but another approach, certainly. I'd talk about Symbian, but that would stretch my "near-death OS examples" to the breaking point.

Forcing users to scan a grid of icons is, to me, not just a failure on mobile, but is a demonstrably secondary action in desktop systems. Think of the Applications folder on OSX, or the All Programs link in Windows. This is not the high use case, and is a simple fallback for when you need to get to something obscure, or which you cannot find otherwise.

And how to get around this? Search, launch bars, recently-used application lists, and other methods to allow the user to find the most likely applications. With a distinct move towards doing this automatically for users, instead of assuming they will set it up for themselves (because they won't).

Someone will probably see this as an assault on iOS. And I am fine with that. Aside from being comfortable with fanbois interpreting everything non-glowing as villainous, this is behavior I have observed; satisfaction does not always correspond to task completion, much less efficiency.

And it's not evolutionary. This is a twisting path. A lot of stuff much older than this let you prioritize better than just "what is on the first page of the app listing," like say S60:

Darn it, I did mention Symbian after all. Oh, well. But since we're comparing to Apple, let's talk about another common refrain against Windows Phone – that it's over-designed. In the sense that it's designed to look good to executives approving it, to focus groups, or is just a misguided visual designer's wet dream. There are a number of ways in which I disagree with this, and find it to clearly have been well thought out by some pretty clever UX designers and IxDs.

The first has even been pointed out by some who dislike it. The device has pretty notable, integrated teasers of additional function or content. Tiles are partly displayed on the edges, animations help communicate what the interface can do. Even that big dead space to the side is about leading you to change panels to the right.

Another key one (there is lots of hate) is about the density of information. Those big words bug everyone, because they are not efficient. Compare the number of characters, lines of info or anything else you want to almost any other device and it comes out behind. Or does it? When I think of a lot of the use of mobile, even though context doesn't matter anymore, I see a lot of glanceable use.

My co-worker, for example, will regularly use his phone on the way to a meeting. Large text and images as iconic representations helps him use this on the go. I have noted, a lot more than any of the devices I am using. I sometimes have to stop to read where the room is, on my high-density information display. While we're at it, those giant, wasteful black gutters between tiles, they seem to help reduce click errors (and improve confidence of clicking) in all environments.

I have seen the design of Windows Phone disparagingly described as being like poster art. Which I say is a good thing. Posters work.

A question I assume many of you will ask is: Why isn't Windows Phone the market share winner? Well, lots of the usual reasons. Marketing, price, distribution, hardware, networks and operators, and so on. By no means does the best device win. Everyone seems to now be comfortable with OSX devices selling in their non-dominant market, so think about that.

I'll tell you that a lot of these relatively niche devices (like WebOS or Windows Phone) are beloved by most users of them that I know, or have interviewed for research. They give them up due to unavailability, or lack of key apps or some other aspect outside the core interactive design paradigm.

But also, we may be getting there. Android is doing rather well, and if you were inclined to, you could say it's because they support widgets, and this flexibility of layout is at least part of the success. I actually cannot find a useful "reason I chose Android" study to say that, and it's possibly untrue, but everyone else lies about statistics to prove their point. So I say that Android wins because the idle screen is more flexible and can be more mobile-optimized (I actually /do/ talk to end users who say this is why they chose it).

And even more importantly, tomorrow is the future. Mobile, more than other technologies, changes all the time. And often in unexpected ways. On Thursday, a new head for HP. Is WebOS on the way back? Or this recent InfoWeek survey of mobile OSs (available at their site, but thru a subscription wall so the link may or may not be good) that shows Windows Phone perceived as just a tidge less useful to the IT professional than iOS.

The future doesn't even have to be a variation on what we have today. There are OSs on the market off in other corners of the world you might not have heard of. Speaking of Itai, his Else phone prototype was a shockingly amazing piece of design in every way; I see no reason something that radical cannot make it to market sometime and surprise us all. Or maybe the web will take over, and the device OS won't matter. Or… something else.

I have no idea what tomorrow will really bring. But it won't be more grids of icons.

For more on designing widgets, or just making those bog-standard lists and grids the best they can be, check out our forthcoming book Designing Mobile Interfaces. Pre-order from Amazon for a significant discount, or read the content online right now.

Interactive Criticism and the Cult of Clean Design

2011-09-14T11:44:00.006-05:00

This discussion of minimalist posters got me thinking of some of the design problems I have been encountering lately. And that got me to thinking that I have been seeing a variation of this for years and years.

Unlike much of the graphic arts scene, it seems that interactive design hasn't gotten over it's trend of simplicity and whitespace for their own sake. If anything it seems to get worse year after year.

While I won't quite blame Apple – and everyone else who follows that design ethos of spartan minimalism in everything – this is the design I am talking about.

But the problem isn't really that we're stuck in a design rut. We are, but it's much more that not everyone evaluates everything the same way, with the same depth. People use a cool new product (on their iPad), then come to work the next day and say we should make a product as clean and easy to use as this.

But "clean" and "easy to use" are different things. In the same way that "look and feel" are two different phrases (hence the "and").

"Clean" rapidly becomes misinterpreted as "low-featured."

"Easy to use" becomes misinterpreted as "easy for every single person in the world to use."

"Simple" turns into "simplistic," and we cut features not to get to core principles, but because they are visible. We cut features not with a knife, but with an axe.

And rapidly, any feature is worthy of being assailed not on it's merits, but on it's immediate visual appeal in a wireframe, or comp.

But it's a false argument. Anything, – anything – can be assailed as cluttered, complex, or any number of adjectives that are, really, meaningless.

There is no way to argue against "you don't want to confuse the user..." on it's merits, because there is no internal logic to this argument; it has no merits, really. I routinely want to challenge such arguments and bring us back to principles, or to the scientific underpinnings of the practice. "Hard for which users?" or "But this feature is required to meet objective 2…" or "But the research proved that 100% of the participants prefer…"

So maybe we can win the argument by counter-attacking their premise, and getting to the core of the issue like this.

At least on the face of it.

Because really, we're missing a key point by calling it a design issue. It's a communications issue, or maybe (as Alexandra Lange responded in the comments on that Design Obsever article), an issue of design criticism. I admit that I would not have made any of these connections without her article.

As practitioners of IxD, UI and UX, we try to make decisions based on provable knowledge. You could even characterize it as a scientific approach to design. But it's not always true. Opinions still abound in discussions amongst ourselves. About interpreting what actually happened in a test, or what situation we are really looking at, so what heuristic should be applied.

If you were to watch a design (or art) critique session, you might think it's just a conversation, but really this is a fairly formal construct, with rules that make it work to everyone's advantage. You cannot complain about a work without merit; "I don't like it" doesn't fly. You better have a good, reasoned argument as to what you don't like, in what manner you don't like it, and maybe even suggest a solution. It better address the intended audience, or the purpose of the object. Assuming use outside of this may be irrelevant.

As the creator, you better accept all criticism, and I don't mean passively; you have to engage in the conversation, to make sure everyone understands each other, and so group discussions can help reach consensus on the best course of action. Note that I didn't say "solution." One individual still ends up cutting the wood, or painting the line, or placing the pixel. Iterative critique gets it closer to the intended goals.

Mostly, you cannot perform design criticism alone, or as the only proper practitioner of it; everyone has to participate and follow the rules.

Interactive design doesn't have any of this. Sure, your studio might work fine. And I have absolutely been on teams – or led teams – that worked exactly like this and had terrific group design critiques (and terrific products came out the other end). But as a whole discipline we do not have a method of critique.

We argue, cajole, express opinion, refer to previous solutions, and our favorite products. We make deals, and end up splitting the difference so we can stop arguing and get to the next point.

We decry ornament (especially when we bow to the altar of Clean Design) and insist we evaluate based on interactivity and process. All while we draw comps and complain about crowding objects, and demand white space be added or everything align to the grid.

We carry out common practice, and build what is easy, instead of finding and defining what is truly, demonstrably best practice.

We do not share, or tell anyone else about our design solutions. Maybe not even the guy in the next pod, but almost never to the design community as a whole.

We design in isolation, take criticism as insults to our work, and believe there is design that cannot be improved upon.

We perceive openness to opinion, fuzzy concepts or acceptance of change as weakness. We are simply confused (and maybe assume it's a trick or insult) when a designer offers to change to an alternative design when a good point is raised by others.

And we cannot fathom why our clients do not respect interactive design and user experience as evidence-based, consistently-applied, professional fields, and express sorrow every time they insist we change something based on whim.

We need an ethos of design criticism.

Not a process. The existing ones for fine art and design work fine.

And we must not stop disagreeing with each other. We must not stifle creativity, or reduce iteration, or work more in isolation from fear or as a res

Of course you know that arguing with the client never really works. I said that up above because that's what I want to do, but another approach is needed.

So, if you agree, what next? Well, it's simple. Do this. Tomorrow. Okay, it's the end of the week. So, Monday. The next time you bring the team together, lay out the ground rules and tell everyone this is how we're going to talk to each other.

In several ways – but especially in becoming a seasoned practitioner of art and design criticism – going to art school was maybe the best education I could have gotten. I've been thinking for a long time we need to teach not just what you should know, but how to do it and how to do it with a team. Not every field of study or school does this. You can make sure to teach your junior designers the skills they need, and not just assume they will pick it up on the way.

And you can try to get the right feedback from everyone. When you walk to someone's desk, and they give feedback, ask them to justify it, very precisely. Nicely, but get to the heart of it.

Anyone can answer these questions if pushed to it. Not naturally, but they can. Even your clients. If you are told "why not more like how Amazon does it?" then pull up that part of Amazon, and ask in what manner this solves the need. Ask how this meets the goals of the product, ask questions you know that there are answers to, or which they will enjoy answering.

As much as it's been talked about, there is no certifying organization for IxD. As much as some people get to write books (now me!) and get followed by thousands of people every day, there is no one guru who can change the whole field. We all do it, every day, as we work with each other and improve interactive products.

If you like this idea, do it. If you have a better one, do that. But if anything ever bothers you about how our field works, talk about it, find a solution, and put it into practice. This is how we improve ourselves, and our little part of the world.

Context always matters

2011-09-12T20:24:00.013-05:00

It has become fashionable for a few months now to say that mobile is so ubiquitous context doesn't matter. I've even gotten comments from technical editors for the book Designing Mobile Interfaces to this effect. So, I've put some thought into it lately.

And it's true, people use their mobile devices at home, in the office, and other "not on the go" types of situations," an awful lot of the time (some surveys: 60%). However, there are a couple problems with saying "context doesn't matter." Because the manner in which people use things /always/ matters.

And in fairness, at least few of these folks are in fact referring to the way users always matter, but I argue that this is the exact same thing, and there's no reason to change the way we talk about things. More importantly, the old mobile context discussions never meant just "on the go" in the sense of "on the bus" or "walking down the street" to the exclusion of "in front of the TV."

A key reason I think context is still a good and important thing is that it's not just good and important for mobile. Personas are often the closest we tend to get for desktop design, but if you think hard about these, you'll find that some of yours include contextually-useful information. Library computers are different from laptops, which are different from the desktop at the office. Often, these are critically different in technical manners (work computers often do not allow installing plugins), but very often it's as simple as thinking about the degree of focus someone can pay to the task at hand.

I've designed a fair number of desktop apps or websites for Customer Care representatives, or Telecom Managers, or others in specific work environments. Long before I thought about mobile context, I put a lot of thought into context of use in this regard.

So, why do we spend so much time talking about context for mobile devices? Because they are even more portable than laptops, they can be carried to crazy places. But mostly because they are full of sensors. You can get a lot more information about individual use of a mobile than a desktop if you have access, and try.

Trying is a problem. A lot of mobile sites and apps just do their desktop thing, but smaller. Even if you have made a great game or app or site and it's perfectly usable by tapping on a tiny screen, does it work for the context of use. Sure, sometimes I refer to context the traditional way: does it work in glare or darkness. But think about the

Desktops (and if you haven't figured that out, laptops are the same) demand attention. If a common use of mobile handsets and tablets is "in front of the TV," then you probably don't want to be totally sucked into the mobile device. You might even need to be able to interact with others, and react at a reasonable speed to the conversation, or the action on the TV. Same for the dinner table, general chit-chat around the house, gardening, or anything else.

When I say mobile must be designed with context in mind, I mean that it has to work with people's lives. In that same introduction section where I refer to context explicitly, I also say:

Lives take precedence
Mobiles are contextual, here meaning they are used alongside people's actual lives. Desktops (and some and other devices) can suck people in so you can go ahead and issue alerts that blink in the corner of the screen, and they will be noticed. Mobiles are glanced at, used in gaps between conversation and driving and watching TV. They are even used to enhance these other experiences. So make sure they don't interrupt unless they have to. And if they have to, interrupt in a manner they will notice. A blinking LED, for example, is easily missed when a device is glanced at for a fraction of a second.

Sure, sure, you might still say I focused too much on distraction and driving. But have you see the task switching studies? Even when just on their mobile, users are interrupted by others, by new updates and by new thoughts of their own all the time (this link has some other great context of use numbers as well).

Just because the user is not walking down the street or at dinner, doesn't mean they cannot be distracted. If you are not designing to account for distraction and social context, you are putting up do not enter signs for your users.

All that said, context of use is only one facet of design. Check out my other seven Principles of Mobile Design. If you like them, or any of the other content up there you can pre-order the book Designing Mobile Interfaces from Amazon, for a pretty significant discount right now.

Admissibility & Mobile Networks: Security is a Lot More Than Passwords

2011-08-17T20:18:00.003-05:00

I am writing this because of the recent attention to mobile network "security" in the wake of the several phone "hacking" scandals. It probably should have been one of those topics in the appendix of the Designing Mobile Interfaces book, but it's been delivered and O'Reilly is actually asking us to cut the appendix down so the thing is only good for holding doors open, instead of anchoring boats.

For now, a blog post will do. Before we get into the details, some basics of security. First of all, security is not about preventing access, because straight-up, 100% prevention of pretty much anything is impossible. Any analogy will do, so take fire safety. You cannot build a fire-proof house. But you follow building codes, put in proper-sized breakers, replace worn power cords, don't keep piles of gasoline-soaked rags in the corner, put the family photos in a firesafe, and everyone is aware of where the exits are. You install smoke detectors. If you don't live in a reasonably dense area, you may want to have a remote alarm system. Together, these provide:

Reduction of risk - Do what is reasonable to prevent things catching on fire.

Reduction of exposure - If a fire starts, it should not spread too quickly; key systems are hardened or have backups and people can escape.

Reduced reaction time to incidents - You or your neighbors notice the screeching and smoke, or the fire department gets notified automatically, so arrives to stop the fire before it is too severe.

This is formally considered for things like fire safety. The burn-through time for a wall, or fire door is considered in the context of the structure, it's risk of fire, the type of fire, the response of the fire department, etc. Similar actions occur for physical security. Bank vaults are only so strong, as they have alarms, guards, can be seen from the street, and drilling or cutting will be heard. All you have to do is make sure the vault is hard enough to break into that someone will notice, and can react quickly enough to stop the bad guys.

Similar things for technical security, for the same reasons. Cost, and ease of day-to-day use. Reasonable locks, storing things in ways that cannot be exploited once the front door is broken (don't store passwords in plaintext), and baking in ways to be aware of breaches so you can fix them. A common one that I like is the out-of-channel notification. You make a liability-inducing (money changes hand) transaction, or access control (change your password) change via the website,and an email is sent out. The website is more likely to have been breached from several thousand miles away, and they probably don't have access to your email account, so you have a chance to notice, and react before much damage is done.

Moving closer to the topic, as I talked about several years ago there's a standard four tier security model that's been used for years and years:

Authentication: Who are you?

Authorization: What are you allowed to do?

Availability: Is the data accessible?

Authenticity: Is the data intact?

Which is very nice, and breaks things down well. You can already see that even conflating authentication and authorization is wrong and bad (we won't go into why, but if you are: look it up), and there's more it. That's the key to this post, btw. Security is more than just turning on the password by default, or reducing the session timeout so you enter the (you guessed it) password again.

Anyway, Dave Piscitello (an ICANN fellow, security consultant, and generally clever guy) asserts we need a fifth layer. I agree completely, though not everyone does and accepting it at face value has pitfalls, but let's not talk about that yet. Therefore, the kind of thing I do is print this, and stick it on the wall of my cubicle so I don't forget it:

Admissibility: Is the host device/channel valid and safe?

Authentication: Who are you?

Authorization: What are you allowed to do?

Availability: Is the data accessible?

Authenticity: Is the data intact?

For the most part, admissibility (well, good admissibility) means SSL or something similar. But mobile networks trump everything else. If you are a mobile operator, and the customer is using service on your network (not roaming, etc.) then you (more or less) own the whole experience.

Ignore privacy concerns. Say that you are a mobile operator, and the customer wants to check their minutes. They go to your website via their phone. As far as the customer is concerned, full internet connection, go to the world and check a website. But it's not. In fact, your network has to hand off to the internet at some point, and there's a lot of good reasons to check the DNS requests, and send them down different pipes. When a request for your webserver comes in, you just send it across the hall to that box.

So far, all that you get from this is reduced network traffic, and reduced latency to the user. But what else you can do is realize that you own the packet from the webserver to the pixels on the screen. You can, for example, identify the user and show basic information without authentication. No cookies required, first time they go there, the MEID (or other handset identifier) is used as the only key (authentication) to give this information (authorization).

Sure, sure, someone can gain physical control of the customer's device, maybe temporarily, so you might want to ask for a passcode for liability-inducing actions, like purchases or password changes. But for lower-priority items, for non-sensitive but personalized data, or when out-of-channel notifications can reduce the risk, identification by network and reasonable degrees of authorization are a good and useful thing.

So, let's bring it back to the security of voicemail systems. Voicemail is one of those that's provided by you, the mobile network operator. Since you own the whole chain, front-to-back, a pretty reasonable solution is to require a password (a good one, but that's a different article) for access from the home phone, while roaming or whatever, but just let the user in when they are dialing from inside your network.

Exposure seems minimal. It's voicemail, so is a bit cumbersome to use. You have to listen to it, it takes a certain amount of time to do this, or figure out the prompts to forward it, and there's a tiny bit of a trail. If your boyfriend takes a very long shower so you have time to listen to his voicemail, he's still maybe going to notice the MWI (message waiting indicator, indicating new voicemail) has been cleared, and there's no good way to reset it.

I see no serious pitfalls here, for /reasonable/ security. Remember, be reasonable. The service has to be easy to use, and most people provide decent physical access control of their devices. I am so confident in this assertion that I'll even admit I have been part of the decisionmaking for an operator to keep doing exactly this.

But we screwed up. No, not in retrospect, or because we mis-weighed the severity of getting into vmail systems. Nope, much more basic. It was an admissibility problem. See, voicemail systems are provided by third parties. And not the same third party that installs the rest of the mobile switchgear. Don't ask why (because I don't know) but they are. Always, as far as I know, but I could be wrong.

In at least some cases, maybe most and maybe all, they are also not particularly well integrated. To the point where they might not be housed at the giant corporate data center. And how do they determine when the call comes from inside the network? Well, at least sometimes, by caller ID.

I'll let that soak in for anyone who at all is sad they missed the phone phreaking days.

Yes, it's trivially easy to spoof caller ID... There, I just took 90 seconds out of writing this, googled some terms, and sent myself an SMS via a spoofing service (cause it was free; I would have had to pay to use the voice calling services).

Anyway, huge breakdown in the security chain. The only lesson being: keep asking questions, and get to the people who know how systems really work. Because using your network the right way is among the more neat things that mobiles can do. If you are just some other web or app provider, you can even get agreements with the operators (or others who broker such deals for you) to get some of this same behavior out of your service.

The lesson is not: more and longer passwords, as those are eminently crackable, and are pretty unfriendly to enter (more so on mobiles). Use the right security, but use it the right way.

Salt mine recollections

2011-08-08T12:14:00.004-05:00

In my old-timey RSS feed today was this article about going into the depths of a mine. Reminded me of my own trip to a mine. Sadly, long ago and there were secrets, so it wasn't a photo free-for-all anyway. But some recollections:

By the time I graduated, I was already working as a graphic designer for my dad's little agency. One client was a large distributor of belts and hoses and bearings and so on. We made a promotional magazine for them, and distributed it a few times a year for a while. I was the art director, and got to lay out the whole thing, do press-checks, design stuff, and sometimes go tour the facilities. I missed the chicken plant, and Lake City my did went to, but I got to tag along to some of the cool factories.

And, the salt mine in Hutchinson. I am disappointed to find that part of it is now a tourist attraction, but I visited when it was decidedly not, and I recall we went down to the bottom most level, so rather deeper than these guys.

The surface looked like any factory, or warehouse really. Not a lot going on, and just big piles of stuff, and storage buildings. A few shops, and a rather small building that is the offices, locker rooms and led to the minehead.

There wasn't much of a safety lecture, but we were required to wear a helmet, and keep a "self rescue unit" with us at all times. This was a little plastic box (on a belt) which apparently had a mask and CO scrubber, so we could stay alive a few days with minimal airflow. If you like to worry, then you'll love how they get you out in an accident. There are two large flat areas near the surface structures, one with a tractor shed next to it. The one area is a helipad, so they can land air ambulances. The other is for drilling to get you out. See, if there's a collapse, the elevator is apparently likely to go, so they need to drill you out. And to that end they have (are required to have, actually) a boring machine. Which is what's in the shed. How long does that take? Oh, a couple weeks probably.

The elevator would be a nightmare for anyone not excited about crowded spaces, noise or feeling safe. Because it's an afterthought. The elevator is really this heavy bucket, and we ride on a little cage stuck to the bottom of it. When does it go up and down? When they have to haul a load of salt up, and pretty much no other time.

That also means the cage is barely there, and there's fairly little underneath you. And nothing on the sides. Sure, railings, but no cage. You can stick your arm out and touch the walls. Which is the only time I got told to not do something. Went to touch the wall, while we were stopped (more to prove that it was open than to actually touch the wall) and was told that it's open, and we go real fast, and salt is abrasive, etc. so that's a good way to loose a hand.

The mine itself was pretty uninteresting after that. More alien than overtly impressive. Dead quiet, even with machinery running not very far away. White! Huge. Mostly unoccupied so just dark caverns, but occasionally there would be a light at the end of a room and you'd figure out it's a vehicle, or a string of lights, at least hundreds of yards away. And they carved all this out.

The archives were one of the more interesting stories. And, being not on our own we got to see them, more or less. Boring gray shelves in a room with a cage around it and a sign. They store all sorts of stuff, and notably the originals of all the Disney epics. See, there was film back then. Funnily, the only thing they will not accept for storage are film projectors. Really. Disney insisted on that, presumably because they don't trust anyone to not just thread up their movies.

If I find photos of it, I'll try to post them also. But I am not sure where to find them fifteen years later.

This has all happened before, and it will all happen again

2011-06-20T19:38:00.002-05:00

Pretty regularly, I read or read a discussion of how technology is forging new ground, either for good or ill. But either way, it's all new and therefore we have no idea how it will turn out, etc.

Except far too often that's not true. Maybe I look at things too broadly (e.g. I think bound paper things are relatively interactive), but I see lots and lots and lots of parallels throughout history.

One example that has stuck with me is the development of the spreadsheet (like Excel, but it very much wasn't the first one). There are a number of pundits that say not just that VisiCalc was the first killer app, but that it was developed from whole cloth. Nothing existed like it before. Except it did. Go look up how to use a ledger book. They're not even like slide rules or abacuses (abacaii?) and are still sold at, based on the variety, a pretty good clip.

Another is the ongoing discussion of the future of news media. The old-school reporting staff and well-curated model is, well, old and traditional. What ever will happen to us when this all new world of information gathered from anyone who wants to write up their version of events, from eyewitnesses, and so on? Well, maybe the same thing that happened in the early days of papers, when that's just where the content came from. They'd just print letters on the front page, and often multiple conflicting accounts with no overview or attempt to rectify it. What will the whole world be like when it's nothing but aggregators of individual articles like this?

And I'm not even just being a naysayer here. You can learn valuable lessons from these history lessons. Spreadsheets were designed to be computerized ledgers, adding a few shortcuts to increase accuracy and efficiency like calculation. But that has empowered them to be even more capable, in ways that could not have been predicted. News in the old days

More recently, I've been reading this history of the development of the Mac and considering how they came to these decisions on UI which we now see as being fundamental truths. And I often like to re-visit the early history of computing (later chapters are not as good) to remind myself of the difficulties they had in creating computers in the face of tabulating machines.

You did know tabulating machines were not computers, right? If not, get out and read some more. There's all sorts of good history out there, that tells you why things are the way they are, and which you can put to use when making design decisions about contemporary interactive products.

Now, back to writing my own -- hopefully sufficiently short and comprehendible -- history and explanation of the basics of mobile telephony as an appendix to the forthcoming book on Designing Mobile Interfaces.

Cisco is helping hotels block your mobile data

2011-06-12T10:16:00.002-05:00

Just yesterday I got home from a trip to go present at the Float Mobile Learning Symposium in Peoria. It was relatively nearby, and I don't see another vacation in my future, so I hauled the whole family with me and we made it one of our typical road trips, avoiding interstates at all costs.

Between them, someone was on the internet pretty much the whole trip there. And that was surprising, and pleasant. Even being all spread out, the US seems to be moving to a European/Scandinavian model of total access. The Clear aircard (falling back to Sprint, actually) was able to provide mostly rather good, and always passable internet. Really, 100% coverage, door to door. Verizon failed for the handsets, but oh well. I am sure they will get there also.

Yes, door to door. And when we get to the hotel, it failed. I spent a couple days ranting about how lame it was the internet failed in the largest city we'd been in since leaving home. I paid the $10 a day to get internet in the room (pretty lame internet at that), but then noticed that the Clearspot still worked in the car. In the parking lot. Of the hotel.

Wait a minute... So, I did some tests.

The results seem clear. It's not loss of signal, so should not be (purposeful or not) passive interference. It is pretty unlikely to be accidental interference in my opinion. And I find it interesting that the only place I have stayed at in years that still charges for internet has this behavior. Hmm...

Details of the testing below.

All speeds logged with speedtest.net Android application on Motorola Droid 2 Global (Verizon, in CDMA mode). Tests performed several times in each location, and averaged.

Additional testing performed with Clear (operating on Sprint 3G network) aircard and Sprint handsets via testing software on computer, as well as other speed testing protocols. Not included in averages, but similar results observed. Since these devices operate on different frequencies, that would seem to rule out interference as the culprit. I didn't bring any live SIMs, so couldn't try any of my GSM handsets.

There was no corresponding change in SNR, received power or the handset’s transmit power (indicating unusual power management). Latency was quite low for a mobile network (around 120 ms) and consistent for all tests, at all times. For the handsets, no change in voice quality or the vocoder level was observed. All effects were purely in the speed of mobile network traffic.

Cisco AP unplugged – A Cisco device was found under a table in the guest room. It is well-secured to the table, so the back (with FCC ID and so on could not be found) but it appears to be a Cisco Aironet® 1130AG Series wireless access point (e.g. a WiFi router). When it was unplugged (it used a single Ethernet cable, presuming with PoE) the in-room speeds immediately doubled, to broadly the same speed as any other in-hotel area, outside of a guest room.

Hallways, common areas, conference center – Numerous locations were tested. Speeds were around 10% higher on floors with no guest rooms. This speed was encountered even in places such as a fire stair; with cast concrete construction, no windows and heavy doors, it would normally be the worst place to attempt to get a signal, but still offered broadly the same signal, and twice the network speed of the guest room with it’s broad windows.

Bridge – There is a conference center across the street, with a second floor pedestrian bridge of glass wall construction. This offered only a slight increase in speed, with significant fluctuations during the test. These fluctuations were not encountered in-room.

Outside hotel – All areas outside the hotel, in areas up to 1 mile from the hotel, had broadly the same coverage and speed, varying from 1100 kb/s behind walls where signal was masked, to 1,600 kb/s in open areas or high ground. This includes standing against the hotel. Tests were performed against the wall of a common area with nothing but windows, and immediately then was switched to outside the same location. Three feet away, with only glass in between, there was no change in SNR or received power, but an immediate tripling of traffic speed.

Learning user-centric behaviors from appliances

2011-05-30T23:16:00.008-05:00

Our new dryer is quite new-fangled. Full of buttons and lights and displays and, so it says, sensors. It seems to be true. It dries the clothes to the proper moisture level, then stops. And, of course, beeps at us. A bit unpleasantly, I must say.

But what's really interesting is that this is not the end of what it does. If you don't pay attention to it, it'll start spinning periodically again. So the clothes stay all fluffy and any residual dampness is not sitting there festering. And yes, it reminds you occasionally (by beeping) that it's still done, and please why won't you come get the clothes out?

Sensors? Reminders? Even without the excessively-ubiquitous touchscreen, this reminds me a lot about interaction in the way I am always thinking about it.

While there's no exact equivalent, let's compare to generalized reminders. Alarm clocks are the dumbest of dumb. I have a really nice Sony one with quite sensible controls to set it, and have had hotel rooms with the giant LCD versions of the same. Still dumb as a box of rocks. They will beep all day if you let them, which seems clearly stupid. Anyone who doesn't wake up in a minute or two isn't going to. If you come up with cases where you're in another room briefly, and have to be reminded that the alarm has gone off, sure that's true. But constant beeping?

Mobiles try a little harder. They (generally) use network time servers to know what time it is, for starters, including daylight saving and time zone adjustments. Alarms of most any sort (and this is all for dumbphones, and not even very new) beep, but not constantly. They do keep beeping, and all too often they beep the same way as new emails, new SMS, etc. Alarm fatigue is common, so you run the risk of missing that it's time to go to the airport and fly home. Dismissing alarms is too easy, so often becomes the default "silence" behavior, and by the time any other activity is completed, you have forgotten about that reminder.

Desktops are generally worse than this. They are mostly not even aware if the sound is muted, and certainly have no control, so do a terrible job alerting. Most reminders I see require you to set a snooze time, so just sit there as a little window, minding themselves, and not doing a good job reminding you. It's easy to walk away from them.

Mobile, especially, can improve a lot. Their sensors, and control over the hardware, can be used in a much more user-centric manner. For all applications, and services, but notifications serves as a nice exemplar.

Alarm Fatigue - Don't use the same beep or buzz for every alarm. And don't just leave that up to the end user; most will leave the device in factory configuration, so it needs to come all set up with this sort of useful customization. Often, you can get away with simply "different" instead of worrying about specifically emotive tones. High priority items can use a rarely-made sound, as long as it can be localized to the user's device well, to attract attention when it might otherwise be dismissed. In some cases, a voice notification is better than a simple tone, though be conscious of privacy concerns.

Dismiss or Silence - And alerts will be dismissed. Between messages, emails and alarms, handsets demand attention dozens of times an hour. Often, you just want it to be quiet for a bit. Alarm silencing, and traditional (one click) sooze functions should be at least as easy as dismissing the alarm entirely. Key-only functions (or locked-screen gestures) should silence, not dismiss. Then when you can look at the device again, you will be reminded of the notification.

Reminding of Reminders - Other sorts of solutions can -- and should -- be developed to solve these sorts of problems, not just by applying patterns and heuristics, but by thinking entirely outside the box. Myself, I think about solutions like using accelerometers and checking your calendar. If you dismissed an alarm while in a scheduled meeting, then the phone was set down for a while, the device could easily surmise that you may have forgotten about that alarm you dismissed. It could then remind you a few minutes after you get up and start moving again.

While many of my appliances and consumer electronics are stupid, I am regularly surprised at how good the results of a well-focused effort can be. While systems of design, holistic views, principles and patterns are needed, remember that each app, service or bit of functionality is it's own little entity also. Satisfaction, and even delight can come from anywhere, even boring little things like an alarm.

For more on getting to new design, and not just falling into the heuristic solution, see me next week at the Float Mobile Learning Symposium.

This is what I sound like griping about pixels vs. boxes

2011-05-20T19:43:00.014-05:00

For those few who have forgotten to remove me from your feed list, the absence has been totally worth it. Writing (half of) a 460 page book on mobile design was very interesting, and hopefully will be something important and helpful to you all. Buy a copy when it comes out, presumably in a few months.

Last year I was on a panel with, among other people, Luke Wroblewski. He was "defending" his then-new concept of mobile first. I was supposed to be the naysayer. But it takes me a while to warm up to people and be abrasive, harsh and disagreeable, so I ended up looking like I agreed with him. Everyone else did, so it was a rather boring panel. We're sorry it wasn't exciting.

I did agree with the principles – which I'll get to eventually – but I didn't fully understand how much, or even really why I disagreed with the practice at the time. At the time, I thought I had a nice cynicism baked in, but in fact I'd worked in or with organizations that more or less bought into the concept of UX practitioners and let us do our jobs. Some encouraged it.

Since then, I've had to leave that job, and as it turns out that whole world. Not the design world, but the happy design world. Before I go further, I should mention to anyone who works with me, you may or may not know what I am talking about. I have a day job which is separate from my freelance clients, who don't know each other. Though it probably decreases my ability to network and sell, I respect client wishes and do not generally even imply who I am working for. I also have friends, and keep track of former co-workers, and talk to others about their new jobs. And with the writing I have been very much keeping up on the world of mobile (and other interactive) design. So if this sounds like you, and you are offended, there's probably someone worse, or at least it's a composite. Don't get in a huff about it.

It's like I never left

I'll hope we can all agree that the end goal is good, useful design for the end-user, and the way they work. But from there it all falls apart. Let's get right to the heart of the matter. A lot of people use this as the basic unit of design, for all interactive work:

I see it used by those who distribute involved raster PSD templates for designing on a specific device, or write up long explanations of how to use Fireworks for mobile design, or who push or promulgate pithy catchphrases like "mobile first," (or "CLI first") really. They often routinely conflate interaction and interface design, or just call themselves "designers" without distinction. Many work at companies who hire designer/developers, or cannot fathom what a designer does if not also writing code, or at least prototyping everything, as soon as possible.

Yes, I am enough of a taxonomist to know that generalizing results in generalizations. I don't much care about individual cases. But if you want to talk specifics, I have seen at least three well-meaning, otherwise mostly-useful repositories of information refer to 44 px as the right touch target size this year. If you are not horrified by that, turn in your HCI credentials. You may have noticed that people cannot be measured in pixels. So it was dumb a couple years ago when there were too many Apple fanboi designers. But now even iOS has multiple resolutions. Saying "44 px" without caveat, in 2011, should be tried in the International Criminal Courts at the Hague.

It all reminds me of 1999. That's when I started seriously – in front of clients – rejecting the concept of the "page fold" in web design. By way back then even the desktop was becoming too fluid or fragmented to pick a screen size for everyone that was the same. Anyone who starts with a single resolution for mobile is fooling themselves, and wasting opportunities.

Without over-emphasizing the point, designing in pixels is dumb. Anything that reinforces or just trys to improve designing in pixels is also dumb.

Note that I didn't say we don't need Photoshop. It's open alongside InDesign all day, every day. And I in no way said we don't need visual or graphic designers; I have an art degree, and have won awards for digital art and illustration, but it's not my day job today, and I need that sort of designer to collaborate with. I said "designing in pixels" is bad. Don't over-reach and miss the point.

So, what's your point?

My basic element of design is this:

I like words also. If I can get them, well-formatted bullet lists are nice, but if I have to just boxes and words will do nicely. Two pixels together are two pixels. But two boxes together are nested. or adjacent, or overlapping. They interact. They can move. One can conditionally disappear.

Don't even get me started on the possibilities offer up by three boxes. The mind boggles.

What size are they? It doesn't matter. Or: it depends. On rules we don't just assume, or constrain by declaring a resolution, but by determining some what size and what items stay on each page in which position as the design progresses into addressing different platforms, different devices, and different aspect ratios.

This is all based on every other type of design or drawing or illustration I have done or learned. You start with basics and move into details. You start with sketches and settle on aspect ratios, orientations and sizes. Details get filled in as it evolves.

So few artists start their work at full detail in one corner that it's generally studied as a condition. Whereas I have seen an awful lot of interface designers start by laying down a gradient bar at the top of the page, pick the color and type the title in, then proceed from there.

What catchy phrase can I use to remember this?

My mantra would be something like "do your job first." Yeah. I am not that great at catchphrases. But I still believe in it. Don't jump to final designs, and don't jump to even wireframing of any one platform and resolution. Let the process unfold.

Analyze existing products. Ask clients and customers, then build goals and objectives. Put Post-Its on the wall, then start drawing. With whiteboard markers, and sharpies. Eventually you get to make boxes and they evolve, and branch to the needed interfaces. Doing it all like this might even help you identify which devices and modes in which it should operate. And remember to design for people first.

I once was in a meeting at a Fortune 50, who had hired a respected and well-known design firm to do some interactive design. They brought some "mood boards." That's what they called them, but they were single images just ripped from magazines and blown up. Starting your design by copying the last thing you did, the standard OS template, or the coolest new thing, locks you into that first pretty picture in the same way, and everything will be a variant of it, instead of your own design.

Let IAs do IA, let Information Designers design the information, let IxDs design the interaction, and yes let the VizDs do everything they do to assure it's all tied together as a cohesive interface. Respect all the jobs, and don't fall for shortcuts, but do your job first, last, and always.

I wish we had a manifesto

If this strikes you as totally the opposite of the way you work, rest assured I am not just some nutjob screaming in the wilderness. I've worked with or for plenty of others who believe in this. There are whole, large, respected organizations who work like this. Ones you've heard of, and who are too cool to hire me.

But we all spend more time doing our work, or arguing with each other to get together and realize our similarities and write up a public, non-proprietary process to get noticed.

You, no matter who you are, probably believe at some level also. Ever done a whole design session with just sharpies and Post-Its? Ha! I caught you. Try that for a few more layers of design and see what happens.

You probably shouldn't listen to me

I mentioned up front that I can be abrasive and disagreeable. If you don't think so now, you haven't been reading closely enough. I get along with a lot of people well, but (I have been recently told) not always, not with everyone.

Don Draper (and his ilk on every TV show) gets away with a lot more than I can, or you probably can either when selling to the client/patient/judge/etc. The right idea doesn't always win out in the real world, so even if you are ready to join the revolution and start that manifesto, you need your day job still. Be ready to lie to keep the clients. I do this all the time. They want to see the home page, so we make one up, with gradients and icons and banner ads that are better integrated than they'll ever be in reality. Then we ignore it (rarely does anyone keep them around) and get back to developing the design the right way.

I am sure some people are bugged by the morality of this, but I certainly think the end user and the end deliverable is still more important than a short-term deliverable. I am willing to stretch the truth a little bit. It's in everyone's best interest.

Fresh mobile design elements, just in time for Spring!

2011-04-17T16:25:00.013-05:00

I almost can't believe it's been almost six months since my last update. I use this file almost every day. Which maybe is why I haven't gotten around to updating. I've been working a lot, working more (freelance in my "spare" time), writing a book for O'Reilly, and editing an entirely other book.

When that comes out, I'll also be sharing the file I've used to make all those illustrations. But for now, I've got a few updates all throughout the old, well-used Mobile Design Elements document itself. As always, you can grab these from the same wiki where I'm writing the book, on the Drawing Tools & Templates page, where I also put up every other template, stencil and UI guideline document or link I can find. Remember, it's a wiki, so add your own if you find one.

So, like I said, there are little changes all over. Mostly in the small components. But a few highlights:

I've added an iPhone 4. Keeping to the resolution scaling didn't work for the doc size, so I had to make it different. Keep in mind. Just noticed I didn't get an annunicator row into the 4... Oh well. Sure, there are lots of places that have iOS device stencils, but if you like mine, now you have one.

Compared to the smartphone fanbois, not everyone has this one. A featurephone. Specifically, a convertible one with 10-key one way, and a slide out keyboard. This is in outline mode only right now, but I will probably shade it someday, and will post that as well of course.

Speaking of annunciators, I am trying to not just add items, but to organize them. So, all the system status items I could think of (actually, which resulted from research for the relevant section of the book) are now ordered like a typical annunciator row, and options have been added as I encounter them.

Be sure to wander around and check out the rest. Pen input bits and pieces. More unscaled handsets for illustration. Lots of little icons and other pieces. A wholly new and fairly complete keyboard section, so you don't have to draw your own for quick comps. And more. Enjoy!

Now, off to more writing and drawing.

Anchors & Curators

2011-03-04T11:27:00.009-06:00

Curated content on the internet is all too much like the employee-picks shelf at the local bookstore (or video store). A selection, maybe even an interestingly thematic one, but just a collection of existing items. And presented with no other information to help you decide, but what you would find if simply searching on your own.

Consider instead what people with Curator on their business card actually do. They collect, investigate, verify, and organize. They then build exhibits of some items from the collection, in a manner that tells a story. They add their own content. Maps, brochures, labels. Often, it all works together to make the point, to reveal deeper truths about the collection, and to encourage the viewer to explore further on their own. Compare these two paintings, though 20 years apart, the similarities help point out how the artist has grown in the intervening time.

Or, consider the classic format of the national nightly news. Behind the scenes, the anchor is the Head of News. He sets the tone for the whole department, and makes key decisions about what and how it will be presented. Then as the on-air anchor he gives an intro to the story, frames not just the basic facts but the reason we care. If there's a graphic over his shoulder, it may well be a map, so you know where this is taking place. And then he hands off to a reporter who was on site, or at least pretends to be based on footage retrieved otherwise. And maybe, if it's a multi-faceted story, then you go to another reporter who gives another point of view; after the on-the-spot report, the reaction in Washington.

All this is all in relation to a number of posts* and discussions I've read and had with people about the point of online media. And it's coming up since I am being paid during the day to actually develop an IA for a very large product catalog, and integrate existing (magazine and other) content and personal details into one experience.

I have seen at least a little of most of the available experiences. I don't subscribe to them because I am un-thrilled with the consumable media available. I still read paper magazines, because even cut down to save on costs, They do a much better job than pretty much any digital version. Web and tablet versions seem to have lost the key point of sidebars or related stories, and just use paper paradigms instead of developing their own; or learning from education, museum information design and broadcast radio/TV media even.

If this seems like a subtle change, it's not. Go back to the examples, and look at how much internet content is served. I call most of that a subset of "portal theory." An article is reduced to a smaller version, on a category page. It can be reduced to a smaller-yet version, even a title-only for a higher level category, for cross-linking or for the (portal) home page. Instead, I am starting to think that I want to break that whole model, and use the intelligence of humans, not just to tag and categorize and group things, but to differently re-order, to choose what is presented and not just sort, and to not just crop but actually rewrite content to present it most relevantly to the context.

No, I don't have diagrams, or mockups for you. Yet. Maybe later.

The only impediment, as I see it, is people. Good, smart, dedicated people who can write have to be found, persuaded and paid. And too much focus is on technology solutions, and paying for software. We have the software and interaction nailed enough. Now it's time to bring people back into the job of presenting information. Give me a news aggregator with the voice of an anchor, and I'll listen.

But it could also be a great opportunity. To give a new type of voice -- or a reason to hope for the future -- to writers, and to the whole profession of journalism. If not this, then something like it simply must happen. Not to preserve a dying business, not just to make money in a new market, but to keep the public informed so we can all make decisions about the way we live.

* Now that I look for the links, way too many seem to be centered around Khoi Vinh. And he's a good voice in design and interactive publishing. But I swear others are talking about it also. And some rather interesting ones I can't quote.

** When searching for the links I ran across this, which I swear I didn't read before. It also has good points about curated computing. Very different ones, but the over use (or I say, mis-use) of the term "curated" is covered pretty well in there, if circuituously.

Does it Fax?

2011-02-18T07:51:00.004-06:00

This is an old phrase used in logo and brand design. It meant that you need to keep in mind how that 7 color process logo (looking at you, Apple Computer) looks not just one color, but when stretched, muddy and generally screwed up by fax. But it also became shorthand for keeping in mind how it works in anything sub-optimal. How does it look in newsprint? Or on TV?

Sadly, on places like the Brand New blog comments, it's now moved to a joke. "Who has a fax machine" they ask. I say, way too damned many people. All sorts of financial institutions still use them. But more importantly is the meaning behind it.

It used to be that every logo was designed as a one color exercise. Black on white. You made a shape, and made it perfect. You could (and should!) also make color choices, add gradients and decoration as appropriate, and generally design it as part of a system. The perception that everyone has a high resolution digital display has slipped into logo design being a single-point exercise. Its made to look good comfortably large on the computer. And that's it. Applications are maybe adding different type to the logo for the branches of the organization. Or by adding animations.

But I still ask, basically, "does it fax?" What's it look like on a badly calibrated monitor? How about tiny, on a phone screen, in glare? How about as a logo in the corner of a crappy TV screen? What about as a favicon? What if your client prints your tabloid documents letter sized, then photocopies them?

Does it look good then?

Brand is an often forgotten, but key part of developing relevant interactive design. Every part of the brand matters, and if you give me a crappy logo, or no guidelines for implementation, it's not going to work well. Online doesn't give you a pass for making good branding.

What the iPad is not quite doing (yet)

2011-02-01T19:05:00.009-06:00

Every designer I work with seems to think that the iPad is ubiquitous. It's not. No one in my neighborhood has one. My doctor does, but they keep it at home, as the living room convenience device.

Of course, something like half the people in the department I work in (as well as my previous co-workers, who I still keep in touch with) have an iPad, Galaxy Tab and/or eReader. Traveling through airports and spending time on planes, I see a lot more of them. And I've started seeing trends.

When the iPad was first rumored in it's final guise, there were numerous comparisons to the Star Trek PADD, or Alan Kay's Dynabook for the more learned and differently-nerdy.

These comparisons seemed apt at the time, and I still see them. But watching the use of the various tablety devices, Media Tablets and especially the iPad is not a paper notepad replacement. And it's not apparently even about to be.

Earlier last week, I was in an all hands meeting. About 200 people (and seriously at least 50 have tablets of some sort). Those that were even brought, were in bags, or under chairs. They were with the laptops, as something unsuitable to be used in a meeting.

And don't think this means that everyone was paying attention. Most people took notes. They just did it by pulling out a paper notebook or notepad, and writing with pen and paper.

Over the rest of the week I kept my head up more, and looked for other behaviors. Indeed, tablets are used in spare moments alone, or in small rooms. They are used a bit as ambient devices, are used to consume content or look things up when the main computer is occupied. A few people here use them as their primary email computer when they come to visit our team room. But they are never kept out during a meeting when the laptops go away.

I asked a few people why. Frankly, most of these people are /huge/ Apple fanbois. You can't ask them anything about the device and get a useful response. The first good one was from the person on our team with a Galaxy Tab. She was using it in the meeting... and she was just doing email. She said that typing with the virtual keyboard is too slow to take notes. I reluctantly got a few iPad owners to say the same thing.

I had been pulled into that meeting with minimal warning, so didn't have my tablet, or even a notepad. So I took notes on my phone. The hardware keyboard was the killer app here; I have failed to use my previous mobile handset, with an on-screen-only keyboard to do this. But in other meetings I have used my clunky tablet PC to great effect. Handwriting recognition is approaching handwriting speeds, and if you don't live-convert, it's even faster. There's no page flipping, etc. and you just write and draw what you want.

Apple might agree with this assessment. Over the weekend, a patent was found for a stylus for iPads and presumably other capacitive devices they come out with. I think the implementation looks dumb, and maybe is just to get the patent fairy on their side; an inductive tablet pickup (from Wacom could be easily fit behind the screen, and add pressure sensitivity to boot. But I digress. Even Apple has, at least in the back of their head, a concern that the iPad can reach a broader customer base, and be a creation tool, not just the oft-argued consumption tool it seems to be, despite arguments to the contrary.

There also seems to be something about the size and glowing-ness of the iPad that discourages use as attention of the outside world goes up. A fun observation I've made is waiting to board the airplane. There are a lot of people for any single flight, and pretty much all of them have computers, and a lot have tablets. What I'm seeing is:

Condition	In use or in-hand
No employees at the gate	Headsets	Laptop	iPad	eReader	Mobile	-
Gate agent arrives	-	Laptop	iPad	eReader	Mobile	-
Gate agent announces boarding soon	-	-	iPad	eReader	Mobile	-
Previous flight is unloading	-	-	-	eReader	Mobile	-
Waiting for your zone	-	-	-	-	Mobile	Boarding pass
Waiting to get your boarding pass scanned	-	-	-	-	-	Boarding pass

No. No one uses paper books or magazines, except on the plane itself.

Anyway, there seems to be a general worry that the iPad is too distracting, and too fragile. It gets put away not much after laptops. The relatively fewer Galaxy Tabs and Archos things I see are not much better. They last only another minute and a half.

There also /seems/ to be something about the standby nature of eReaders. I never see the idle screens on those; they are pulled out of bags with a page displayed, the people read them, flip pages, continue reading and just shove them away. Not enough data here, but I suspect there's something to be learned with this as well.

So, lest you say I am just anti-Apple (and I do get accused of that when I ask these question), I am not really. I just don't think that any device is perfect, cannot be improved upon, and cannot be competed with. Were I hired to build a media tablet, or software for one, my competition would be Moleskine, and other trendy notebooks.

Everything else is converging into mobile devices, one way or another, so I find it hard to believe that paper is not on our near horizon. The iPad, or Playbook or Xoom or anything else that's not just me-too can easily do a lot of this. I eagerly away the near future.

My Tablet

2011-01-29T17:29:00.012-06:00

Discussions of the best solution for any particular bit of technology all too often seem to center on what is the absolute best. Not what is conditionally best, best for an individual, or best now.

I strongly believe that it depends, a lot. And that there's lots of room to improve on everything. There are a few mobile devices, for example, that I have suggested without qualification. I can still come up with things wrong about them. In one recent case, I've been paid to do so, and came up with about two dozen issues I'd want fixed before launching. Not that it happened, but that's what I wrote up.

That's why I am seen as so cynical and griping about everything; there's always room to analyze and improve, or wish for improvement.

I also think it validates old ideas. I got a couple comments about why I bought a Palm IIIc, last week (11 year old PDA). The reason is, it goes in this box:

I have, for almost ten years now, been collecting everything I can in the mobile and small screen device arena. Sadly, I missed some good ones before I started formally collecting. And there are a lot of good ideas, or pure versions of design concepts that have become muddled over time. This also helps

But today, I want to talk about tablets. There are at least three things that can mean. I don't mean digitizer tablets (a la Wacom) though I use the hell out of those, and regularly have to demo and suggest them. But I do want to blur the lines between the other two, the PC Tablet and the Media Tablet.

The Media Tablet is an iPad. And all things like it. I have some issues with the definition and don't think much of them owning the space when "like an iPad" is the defining characteristic.

I'd rather see something more broken down by user needs, or as a device that solves those problems regardless of label, and open it up a bit. To me, this would conflate:

eReaders
Media Tablets
PC Tablets

I'd love to include tablets with other OSs, and have even played with the ModBook but these are very, very small percentages, so I think I'll ignore them.

So, let's take my solution to this. It's not just a Tablet PC, but a quite thick and heavy one, an Itronix DuoTouch IX325. Oh, and I should stop and mention that though I do not own an iPad, Kindle, Nook, Galaxy Tab or anything else in this range, I have used a lot of them. eReaders especially, I have borrowed from the office for a weekend. I've played with pre-production hardware for some items. Yes, I've worked on some products involving these, and have done a bit of legitimate research. I really feel I have enough experience short of spending two years and $5000 toting them around to tell what I like and don't like.

I went with the PC tablet mostly because I do not want to consume on a digital device nearly as much as I create or otherwise interact. And I certainly don't want to create with whatever nerdy little program, or crippled version of something I am eventually graced with. I like the ability to use the same old software, in much the same old way.

Sure, it has other good features for my lifestyle, like that it's waterproof and relatively indestructible. And has a high quality GPS built in. I do things on the side like make maps, and that's useful. But carrying it around and using it as a sort of laptop/eReader/iPad replacement has led me to find some things that it does which I find to be really, really good.

First, it's not perfect by a damned sight. The bad:

It's thick. Yes, like five times thicker than an iPad. Or is it? It doesn't need a case. Really, I carry it around loose, so even with the feet and hand strap it's only about twice as thick as an iPad it the case. And /everyone/carries their iPad in a case.
It's heavy. Again, about twice as heavy.

It should be expensive. I got mine off eBay and finagled to get it to work. But retail is around $4000. Sure, it's rugged, but that matters. Not sure what price point you could reach for a rugged device, but it has to be cheaper than this.
Battery is so so. They didn't go as far as they could with this. It's just a laptop really, so some mobile-phone designer input would have helped with power management. I can squeeze a bit over 4 hours out if I carefully turn down backlight all the time, but it's just at 2 hours without any care. This is not quite enough to be convenient.
Windows is not a mobile OS. Even with the precision of the pen, sometimes it's a bit hard to hit a tiny, desktop-like target. This is a constant reminder of how mobile is not just "cellphone" and how you need to change interfaces for mobile users.
It's still not a mobile OS. The input panel, and a few other bits and pieces are nice. But it has no quick and easy notification system. The lock screen is in no way an idle screen, so I can't tell battery or time, much less see anything else. It's everything that's bad about the non-contextuality of desktop computers.

But I am still carrying it around, happily, so why?

It has buttons. Kind of a lot of them. Modifiers cuts them down, so there's no dedicated volume or brightness, though I can get to them without a software panel. But what do I use most? Enter, then the scroll keys. I find myself using them very much like I do a desktop, which isn't bad. Type, select, etc. then whack the enter key to commit. No need for a simple, often-used control to require fussy precision to hit.
Retro-reflective. The screen works in sunlight. Not with brightness, but with a reflective backplane. The two input screens obscure it some, but pick up a very old phone and check it out. They could work in full sun with NO backlight. We need to get back to that, in all devices.
Touch AND pen. This one has a button combination to switch, but I like the digitizers that are clever enough to turn on touch when the pen is not present. Anyway, gives a great flexibility. Just poke with your finger for lots of typical uses, get the pen out for precision. And the pen is a pressure pen. Much better for handwriting, and it works with graphics programs.
Handwriting wins. The input panel is damned neat. Manual switch from writing, to letter entry, to a virtual keyboard. I use, about 99% of the time, the straight up handwriting recognition. In slow, clunky windows, this is so good I cannot believe it. I have written a fair bit of the book on it. It's fast, it can be done standing and walking, and it's not much more error prone than typing. I did some un-scientific studies, and really it's about as bad as when I just type. The difference is just in how easy it is to correct errors. A bit clunkier on the tablet, but that's a pure interaction design solution; I can think of a few ways to improve it with very little technical effort.
Its walkable. In several ways. It would be better if it was lighter, but the overall layout, the bezel shape, and this neat handle/strap thing on the back mean you can carry it with one hand and write with the other. And I mean, reliably, with no worry about dropping it. I went for a 2 mile run with it once, just holding by this handle. Sure, anyone could make an add-on strap like this. They should.
Rugged. Most of all, I cannot tell you how freeing this is, compared to the relative fragility of most of our electronics. My tablet has a handle, and nothing else. I just pick it up and carry it around. If it bumps into something, so what? I have been walking through the airport with my luggage, and one finger on the handle for the tablet while the device dangles away. Not everything needs to have a hard drive heater, or meet a milspec for water proofness, but /some/ ruggedness would be very nice for these devices we carry around all the time.

Some of these, like the carry straps and handles, could be done by third parties. Some are software; why not a handwriting panel for an Android tablet? Some are harder (rugged devices). But nothing is insurmountable.

One of the biggest surprises was how much a second computer-sized device has been nice. I had previously used it as a living room slouching machine, for some specialized woodsy stuff, etc. But now that I travel, it's my other screen. I use at least two computers, a TV and a phone at home. This fills some of those, surprisingly well. Yes, a Media Tablet could do much of this, and the wife gets by with an iPod Touch (and a Clearspot, in a cradle I sewed) for watching Netflix at the gym. But generally, another screen does have a place. Huh.

I don't really want everyone to start carrying around Windows Tablet PCs. It's got a downside for sure. But there's a lot more to the world than beating the top-dog in what is perceived to be the market space. What's slowly killing the old-school iPod? Mobiles (and a lot of Apple's other products, good for them).

I tend to believe that an n-killer is always the wrong approach, and getting back to principles is the right one. The iPad killer will, or at least could be, be something fairly different from the current flat-glass tablet in some important way. What else could a tablet could be? Almost anything.

That comfort is important

2011-01-18T14:40:00.005-06:00

“ ... The iPad bursts into life, its backlight on, the blinking “slide to unlock” label hinting at the direction of the motion it wants you to make. That rich, vibrant screen craves attention... It’s glowing rectangles all the way down: those backlit screens that suck your attention...

Perhaps the Kindle’s comfort is down to its single-use nature. After all, it knows it already has your attention – when you come to it, you pick it up with the act of reading already in mind.
That comfort is important to the Kindle’s intended purpose, though. This is a device that always seems content with itself. Just sitting there, not caring if you pick it up or not. Like a book. ”

Tom Armitage of Berg, on the difference between the iPad and the Kindle and their Asleep & Awake performance. This is Ubicomp to me.

After you are done, you are not done

2011-01-06T11:34:00.004-06:00

I keep running across people (as with this Agile training I am in) who think some sort of post-activity accountability is good, so improvements can be made. And they do it... how? No real process. There are a few "post-mortem" processes I've run across, but I don't love them, and they aren't adhered to well.

I also object to the term. Even if you managed to do a terrible job, and the project is dead, your team probably isn't. Your program isn't. This is all an ongoing process so you need to think of it that way. I like the "After Action Report" process. After an activity (it's from the US military, where you shoot people in "an action") you sit down and talk about it.

After Action Reviews are collaborative, inclusive assessments performed after a major activity or event. They can be performed at the end of a phase, etc. instead of waiting till the end of an entire project.

Ideally, everyone is involved, from every team on the project.

Tell everyone what the process is before you start. Show them this, and make them stick to it. The moderator must interrupt people if they don't follow the process. Which is:

Plan

What did you intend to happen?
End state, operational guidelines, timelines, everything else you need. Brief, but complete. Might take a couple minutes. For field exercises, maps and so on can be broken out. Use whatever documents are required, and be specific.
Should be given by whoever was in charge of the project, or currently is. Probably the PM.

Performance

What really happened?
The leadership (whoever did the Plan, and generally anyone else who could be considered a leader) does not talk. Or, if there are a lot of them and the input would be good at this phase, does not talk first.
Try to go around the table, and get everyone to provide input. Make sure to engage. Even if they say "it was said" then ask which one they would have said. It assures they feel engaged, and they might have misheard; they might have a slightly different point to make.
Compare to the Plan step. Looking for deltas here, and considering it like this helps make it more brief.
Improvements over the Plan are fine. Cover all deltas.
Do not say why anything happened. Just what happened.

Issues

Why did those things happen?
Everyone can talk. If leaders seem to be taking over, or anyone steps on someone else, stop it. One person talks, and the point is put up, and that's it. Minimal or no discussion, except if the person bringing up the issue says they are not sure why; then go to raising hands, and one person responds at a time. Keep this under control.
You can consolidate items in the Performance step to single issues.
Try not to bring up Issues that are not gaps in Performance.
Again, discuss positive changes.
Participants might disagree. Try to come to agreement, so you can move to the next phase.

Fixes

What could be done differently, and what the same, in the future?
Try to address each Issue in the above list. Try not to discuss Fixes for things not already discussed.
Classify each item as "Improve" or "Sustain."
Note that many Sustain items are small,; the point is to expand them to larger states sometimes.
Fixes should still not be personal; don't take people off projects, but provide training, provide more communications, things like that.
Everything must be actionable. Even Sustains. Assign a person (not a team, an individual). That individual must be there, and agree to it. Even if they can't fix, they can find the person who can fix it, and it's still their responsibility.
Ideally, arrange to follow up. Some method of keeping track of these so when the next project kicks off things have changed, and when the next AAR notes are entered, the moderator can say "hey, this happened last time? Why didn't you fix it yet?"

Even for informal reviews (conducted as needed, even after something as simple as a meeting) there must be a facilitator. Ideally, this person is uninvolved. At the least, they should not contribute themselves, except as a research moderator might in our other jobs; they may lead and incite conversation, but should not promote their own ideas.

Everything must be written down. Preferably, where everyone can see it. It is possible to

This should not be a griping session, but sticking to the process means that issues can be brought up that might have otherwise been perceived as an attack. You are not allowed to say "Joe wouldn't let us do x" because you have to say "We failed to perform activity x" and then some time later, you can explain why, and very often someone else will. Many times, in my experience, the person responsible will even do it for you. "Oh, I stopped that because…"

Not a terrible summary of the process:
http://www.suite101.com/content/how-the-us-army-after-action-review-improves-business-performance-a314771

There are many bad summaries. Don't be too annoyed if google is not that helpful.

Viewed by lots of people at exactly the same time

2010-12-23T06:51:00.005-06:00

“ ...with the rise of digital and catch-up television in the 2000s, the era of "linear viewing" was supposed to come to a definitive end. Just as we could create our own playlists on an iPod, we could now personalise an evening’s viewing...

Only it hasn’t happened. Saturday night event television like the X Factor and Strictly Come Dancing has revived the concept of live shows watched by whole families. True, the viewing figures are smaller than in the 1970s but in some ways the potential for collective involvement is greater because there are so many opportunities to comment and participate. Twitter, with its improvised invention of the hashtag to allow similar content to be searched and tracked, has allowed vast virtual communities to meet to discuss shows while they are being broadcast...

One of the defining qualities of TV remains that it can be viewed by lots of people at exactly the same time. ”

Author, columnist and cultural historian Joe Moran discussing the beloved, but somewhat exaggerated, history of the Christmas special. Right after reading a dozen glowing articles about how the iPad (et. al.) changes everything, I wonder how much the broadcast model really will change.

Working Agilely... With Agile? Whatever...

2010-12-01T09:00:00.005-06:00

I talk a lot about working with other teams, satisfying the business owners and making sure your work as a designer is consumable by implementation and test. But when I started typing a response to this question on a LinkedIn group, I realized I hadn't really gotten tactical enough in some of it.

The basic question is a good one, I have answered many times internally. "How should UX work within Agile development processes?"

The common refrain from other UXers is to follow Jakob Nielsen's suggestions on the matter. But I find that doesn't work well at all, actually.

I've worked on several dozen (large scale) serious Agile projects and have developed ways to make UX work within them.

First: The IT process gurus they hire are, not to put to fine a point on it, idiots. I have asked such pointed questions of them in kickoffs they were fired and never came back. (Yes, there are also good process guys, and I have actually worked with some to develop the processes below. But process consulting has grown too much in the past 10 years or so and will put anyone through a 2 week course. If you are a process guy who is offended by this you are not a good one, or you'd be annoyed at your many awful colleagues.)

The key problem is that everyone who loves Agile likes to conflate "iterative" and "incremental." Look it up. It's scary. What it means is that a LOT of projects are Agile in name only. They break up development into Sprints, they have their daily Scrum, etc. but the end result and the day to day work is the same as it always was: developers go off, write a piece of code for as long as it takes them, never come back and add to it again, and just toss everything over the wall to the next team. Waterfall in all but name.

But let's assume the process is practiced correctly and is not a bad choice. By the way Agile is practiced even correctly, design is rather left behind. The best that can usually be hoped for is something like this:

You can see Design phase, but they are for software design, and are far too late and constrained for user experience teams to influence the course of the work.

A common retort is to have UX help in the planning phases, and be deeply involved in the iterative design phases, but spend at least half their design time each week working on the next iteration (if iterations are longer than a week, just replace the word “week” as needed).

This is the version where UX gets to do their work 1 iteration ahead. It is clearly wrong. It never works in practice because you end up working on the current and next iteration. Not only is there not nearly enough time to do the work, but it leads to methods (by PM, IT, and you) of solving today's problems, and having no holistic view.

Really its... okay. I’ve done it, with measured success, but it’s not truly satisfactory.

In fact, when I worked previous model and evaluated success (when I talk about whether process works, I mean it; I actually do AARs and run stats on my projects so know when things work or don't), I eventually realized I had a bug in the data. The best part of the results were from the early planning I helped with.

In Agile, two things are pretty solid, from the original planning: the timeline, and the original plan itself. The list of features is completed in week zero, during that planning phase. Many software design documents are completed here, and are almost completely stuck to throughout the process. So, what’s wrong with just adding UX deliverables to this?

As it turns out, a few things. Even there, IT definition processes can get ahead of design and business needs. UX design needs to make their basic plan during the phase before this when business requirements are being developed (and even help make them). Then, additional details of interaction design, fixes, and guidance can be offered throughout the rest of the process.

So I added time to the process! No. I didn't. Agile is not a project plan, it's a development process. There's other work before Agile exists, and I just say you need to get involved up here. Yes, I reframed the question. Tricky, aren't I? Anyway, months earlier is ideal, but I'll take a week if that's all I can get.

Note that I’ve make UXD (and IxD) a whole new bar in the chart. That’s because the holistic view and the work on multiple tracks mean they work more at the PM or business owner level, and work with – but not within – several individual phases, all at the same time.

If you think this will be hard to sell, read up on the process again. If you approach it right, and use their terminology, and offer to help with Sprint 0 deliverable development, you can sneak this in, effectively. You aren't adding anything to the process, but are complying with the original Agile intent much more than by trying to shoehorn UX into each iteration. Process guys will sigh when you introduce yourself as the UX guy, then love that you are just gonna work in their process and not insist they add time or phases.

What about user testing?

Okay, one more thing is that you can still do iterative evaluations and fixes. But not as much as Nielsen's article would have you believe. Agile projects rarely push something usable with every iteration. If you attend the planning meetings, you can figure out which ones are big, can make friends with test and get access to the test site to run people, and try to get some feedback during the project.

What can you do with it? Well, I say not much. If it's more than minor, then you will want to change stuff that is architectural and that's planning or featureset stuff. That's hard to change on a dime (maybe XP can do it, but we're talking Agile). Usually, I just gather the data, analyze it, and only raise issues if they are critical enough I think it's worth arguing for more time. Otherwise, I go to the product owner and make sure we can have a second phase.

The closest this gets to ideal is that there are a handful of phases with unassigned features at the end, and whether it's after the initial launch or not, you can go off, make your revisions, and get them slotted into these last phases with the same team as a rapid maintenance release. This can work, but you have to know the process, and be able to talk the language to make it happen.

And in case you haven't figured that out, if you get in early enough, you can do the normal design process stuff, and take months to do competitive analysis, do needs research, come up with paper designs and A/B test them, or whatever makes you happy.

Regardless of the development process, I say the greatest benefit UX can provide is the moment after the project is a glimmer in the program manager's eye, or when the data comes in that implies a revision/improvement is needed. If integrated well, or engaged at the right time, UX has done a lot of it's work before any IT Dev process has even begun.

And I have successfully done this many, many times.

If those diagrams above are too small, you can get a PDF of them if you'd like.

The Worst Idea I've Heard of This Year

2010-11-25T08:41:00.004-06:00

I've seen some dumb apps, but replacing rarely-used, possibly-emergency paper has got to take the cake:

"It just might be the world's first paperless car: Hyundai Motor America will include an iPad - loaded with a digital version of the thick owner's manual - with the luxury sedan it plans to launch this fall..."

Read the rest of the rather short story.

The story continues to say this is "aimed to tap into the hype" over iPads, but wouldn't an actually useful solution be a good idea?

Now, I like PDFs, for example. I have several hundred manuals (my hobbies are technical) on my computer. But when I need to make sure I know how to use one in the dark and snow at 1am, I bring a paper copy.

Many cars, and I am sure this one, have digital displays built in. Many have mobile links. Providing the manual on this screen (when stopped, or only visible to the passenger) is totally reasonable. I can think of more interesting things than scheduling service appointments, but the concept of connecting to the home office, or otherwise tying to the outside world is solid.

This makes me insane, though. It looks precarious as hell, and tell me why on-screen help isn't a better solution? Or, maybe just fixing the interface so you don't need so much help. I wonder how many fatalities this will cause. (Yeah, I noticed they are such boneheads they couldn't even load up a screenshot of the app for the promo shots, either. Just pretend).

I'd be fine with going so far as to just dock the hype machine to the car and using COTS hardware like an iPad as the in-car screen.

But three years from now, when the car breaks down, and you are trying to figure out the fuse panel in the middle of the night, what are the chances your iPad is charged? Is even in the car? After an accident (when, yes, tow truck operators sometimes need information on how to unlock the transmission) what are the chances that the screen is not smashed? Etc.

An owners manual is, apparently, perceived as an extension of the purchase process, and something every person will sit and happily read when they get home. In fact, this is a massive failure of understanding users, use cases and context. In the US, owners manuals are help lines. Referred to like you call customer care when your bill is confusing. And that doesn't exactly scream "free iPad for everyone" to me.

21% of the Phones I See Are iPhones

2010-11-16T11:07:00.015-06:00

For some time now I've been hearing "everyone I see has an iPhone" from all sorts of folks in the mobile industry. I presume it's some sort of self select error from fanbois. And sadly, it seems almost everyone in the mobile industry is an overbearing fan of the iPhone. To the point that they are constantly surprised by baseline features of pretty much any other phone when I pull one out of my box of phones.

And they spend all their time with one iPhone people, marry other iPhone people, and seem to think it's a really simple world. A month ago, an example of those comments that annoyed me was:

"If you watch the phones people display in public, you really see only two in large numbers: iPhone and BlackBerry."

I am sure that can be parsed to be technically true, but I hear a lot of comments along these lines. And with a popular developer mentality of making products for yourself, then your friends, and users who matter will come as they may, I am saddened by this.

I have even heard non-technical (not mobile designers or developers, I mean) folks being given crap by their non-technical friends (same definition) for having an "old scool" phone, when it does perfectly good internet, email, etc. It's just not the latest favorite smartphone.

So, I was looking around one day exactly a month ago, and realized I am looking at all sorts of phones in people's hands. So, it's that simple. I started recording them. Every handset I even sorta could identify, I recorded. The methodology I used was:

It has to be already visible. No asking everyone in the room to pull out their phones. This gives the observed weighting that everyone seems interested in. There's some "that's what they use" thing that implies everyone else's phones are unimportant. I have actually had conversations where people dismissed sales numbers.
I discounted my family, and all work friends. And their immediate families.
If it's clearly a phone, it gets recorded. This makes for some vague labels on some of them. I can recognize a half dozen handsets at 100 paces. Others are "flip phone" at all but contact range. So, you'll see some oddly vague data. But this is to avoid my own bias on recognizing phones I have or use or read about all the time.
I started to record cameras, music players, etc. It got out of hand. Just let it be known that convergence is not as far as I would have thought. A LOT of people carry other devices, and almost everyone who wants to take photos brings dedicated cameras to events they know are gonna happen. Very, very little cameraphone use at school concerts. A few Kindles observed also, but no other readers, no iPads.
No demographics. Partly, to make it easy. I was typing these into my phone while doing other things. Partly because I don't have the capability to bother everyone to fill out a survey. I would worry about my own bias therefore, so didn't gather any.
Yes, it's local. Kansas City and nearby areas. If you think we're all rubes, blow me. Go ahead and design for your friends in the bay area, and stop reading now.
This is only 72 total devices. Take that as you will.

Some other observations I made, but which were not as well recorded: Every type of phone was seen being approximately equally used for everything. SMS, email, games, video playback, internet searches. On iPhone, Android, Blackberry and every stupid little message phone. More study of this would be nice, but it's even harder to tell what people are doing. This is based on when I could tell. Oh, and fairly few people talking. Less than 10% of the observed phones were seen because someone was talking on them. I didn't record it, but more like under 5%. Very few. Mobiles are typing and looking devices now.

All the data I used is available for you to mock and laugh at. Or, I guess, add to. If anyone likes this, go ahead and continue the experiment. Vector versions of the charts above can be downloaded as well.

I think most of this is clear, but one definition is sort of mine alone. The Message Phone the stupendously common QWERTY device, usually with a slide-out keyboard, and some controls (usually a full 10-key pad) when closed. Sure, other devices and even many smartphones share these features, but for here, I am calling it only featurephones. Note that these are not counting as touch, since it's impossible to tell that at a glance, but some huge percentage of them are indeed touch devices as well. They often are pretty neat, with nice keyboards, good haptic feedback, perfectly good screens, multi-day battery life, etc.

Note that iPhone and Android are neck and neck. And message phones slightly outsell those. Hmm... Oh, and check out that last one. Other devices outsells all others. Sure, it's a mishmash, but don't say any one thing is dominant when it's easy to make charts like this.

Anyway, as far as validity, I always say that crappy, cheaply-done research that broadly backs serious, heavy research is trustworthy. Nothing here is totally surprising and much hews exactly to known sales or use ratios, so I do tend to believe it.

So, what's this all mean? Simple. There are a LOT of devices out there, and people use them. Look at the data and see what is really going on. More importantly, look at real data and make sure you look at your own users, and your analytics the right way.

But what if 96% of your traffic is coming from iPhone? Well, I'd be suspicious of the analytics first of all. Seriously, I've seen this way more than once. If you sell anything but iPhone apps and get that sort of traffic, then first be suspicious and make sure you are getting the right information.

Convergence in My Living Room

2010-11-14T21:37:00.010-06:00

Not too unrelated to yesterday's post on multiple screens is convergence in the living room. Internet on TV-attached devices. And not just the web browser in your Wii.

This has been coming for a while, and like a lot of when-will-it-get-here technologies arrived, oh, some time ago. I've had Netflix in the living room for a year, and of course then there's that Wii browser. And what about all the networked gaming that's been going on for years and years.

This post is driven by two things that happened to me lately, playing with a Sony Google TV, and getting a new DVD player. The Google TV was... disappointing. And I saw it while shopping for a new DVD player because my previous, marginally-connected one died, and Best Buy decided to screw me on the warranty. So a few days later, a new cool one arrived in the mail. It was not just rather more connected (no browser, but lots of other neat stuff) but the services (apps, if you want) were all significantly better and easier to get to than the Google product. All this basically for free, instead of the premium (or all new box) for Google TV in your TV.

So, here's a 10 minute walkthrough of the best and worst connected services and some interesting interactions patterns, or anti-patterns.

Coupled with lots of chatter (with some of the phrasing I remember from information superhighway days) this has been on my mind. We're supposed to be seeing convergence in all sorts of devices, in all sorts of areas, and with some new products, and people like Netflix moving into into everything they can get into, the living room is the current frontier.

So, like I said, it's here. It's not all good. And not just because of the bad bits of the connectedness above, but because of fragmentation in the worst way. The PVR/DVR does some stuff. The DVD player does other stuff. The game station does some other stuff. The TV will soon do stuff. Annoyingly, much of this is the same stuff, and you have to choose which version of Netflix you might want to use today. Not to mention that consumer electronics and home A/V systems are terrible things to set up anyway.

My programmable smartypants remote is the only thing that makes a lot of the functionality tolerable. But that also took far too much time, and almost no one else I show any of this to, from calibrating my 7.1 surround sound, to getting that remote programmed, is willing to put up with the fuss. There are lots of marginally good-enough solutions, and as the always quotable Russell Davies said the other day "It turns out that homes are mostly full of solved problems. "

Most people will keep living with the easiest, quickest solution. And they might well just keep going to their computer or mobile. Unless this gets a lot better, it's not going to get any market traction. Except incidentally. Cameras in phones became default well before they were demanded. Don't get confused by just counting the number of Netflix-enabled devices in homes; look at how many people actually use these devices.

Oh, and since I've been writing up lots of design patterns, I always look at new cool products to get good ideas, and avoid bad ones. I just often can't talk about other things I get to see.

More on Context: Musing on Multiple Screens

2010-11-10T15:17:00.008-06:00

Aside from spending all my time looking for work (please hire me!) or writing in excessive detail about mobile design, I've been slowly noticing myself doing things like this:

I have a couple additional handsets that are active (thanks, various old clients), and I sometimes carry the extras around. And I find myself not so much switching to the coolest, newest one, but using all the tools I have available, often at the same time.

Yes, they now all multitask just fine, so why am I doing this? At first I thought it was just that I'd found something else to gripe about. The switching is bad. Or they don't link up well so I might as well be typing. But I don't think that's it.

Because when I started becoming conscious of this, I noticed doing it a lot more. And in all sorts of places. Like this.

For example, I'm watching something on the DVR with the family, and using the Sling-provided function to see what is on the DVR (to make sure the show we want is being recorded, to find out what we can watch next) without interrupting the viewing, and using the computer to read the IMdB page about the movie for other types of entertainment. And that's not even counting doing Facebook or Email or Twitter or blogging while watching TV. Very often, I am extending the experience with another device.

And yes, sometimes I do that with more than one handset, instead of a computer. But I am not sure it matters. A few others have been talking about use of multiple screens lately. Most notably, I'll mention these two posts by Russell Davies (no, not that one) on using multiple handsets, and ancillary screens. And I've known people for years who are similarly issued a work phone (perhaps a high-security one), and have a normal phone for the rest of their lives. And I haven't even gotten to iPods, in-car navigation, kiosks or those annoying video-playing screens on gas pumps.

But back to what it means: I am not sure. Working on it, but it helps to type things, and maybe you can contribute.

I am sorta thinking along two paths now. First, the "fourth screen" thing may not be what I think a lot of tech pundits seems to want ("Technology Y is Dead!"), which is generational improvements, but /additional/ types of interfaces. And they don't necessarily displace, but can be used in addition. Like my use of mobile and computer while watching TV.

The other is about context. Where, again, I think I work best with photos.

The desktop, as I've mentioned lately when discussing context, is about what happens on the big glowing rectangle. It can assume you are sitting right in front of it, and all the interaction happens in windows within the display rectangle (or, to me, two adjacent rectangles). Laptops are not much different, and still assume they are more important than the surroundings.

You don't carry a screen around with you out in the world, but can carry (or place, or mount) an arbitrary number of screens in the context in which you live; the whole world.

Previously, I had really considered context to be a screen bound to the viewport or device and strongly influenced by the way the user worked, and the environment they live in. Even though I have drawn pictures of the device in context, I wasn't quite getting that it literally lives in the context of the rest of the world.

So, I have yet to decide how this impacts how I might design a service. Certainly somehow, at least for entertainment and CE products. And probably some for everything else. If I come up with more, expect to see additional ranting, or topics in the book. I think there might be something to say about remote input as well.

To which I'll remind everyone: please visit, provide feedback and contribute to the mobile design patterns and information wiki at 4ourth Mobile.

Robovouchers That Get in Your Hair

2010-11-03T10:32:00.003-05:00

“ This seems like a potential darkside in waiting. Aside from all the surveillance concerns you've suddenly got objects that can swarm in three dimensions and might get cheap enough for the economics of spam to apply. Never mind walking past a Starbucks gets you a coffee voucher on your phone - we'll just soak the area with robovouchers that'll get in your hair until you buy a cappucino. ”

The design and experience Russell Davies with some vague thoughts on designing behaviour and robospam, and the right-around-the-corner world of robot helpers, or annoyances, as he plays with a Roomba, a Sony Rolly and a good cheap RC helicopter.

Working Together for Mobile 2.0 (or 4.0)

2010-10-21T13:56:00.008-05:00

Brian Fling's Mobile 2.0 thing is not quite a manifesto yet, and as he points out a lot in the document, has not even gotten the community traction that it needs, but is still something I mostly agree with. And, want to help with.

I think things are mostly trending better. Worse a few places, but mostly better. I am thrilled with new things like Mozilla's Open Web App Ecosystem, so much so I talked about how much we needed one a week before it was shown off.

Now, I'm gonna talk specifically to some of the points Brian makes in his document. And try to help with a couple of them.

A Mobile Web Coalition/Task Force:
All my attempts to create a Mobile Web Coalition has failed since sending this email out. The problem is that no one has the time to invest in attacking such a hard problem. I’ve attempted to get corporate sponsors, but everything is just keen to do their own thing.

I have always agreed, and now that I'm applying for jobs, and am reviewing and trying to share what I made, I am annoyed how many are NDA restricted. It reminds me of Kim Lenox's post lamenting the good design of the iPhone because we all had many of these ideas already.

And even aside from secret clients, I've worked for companies where you couldn't discuss anything. I once got smacked down for discussing on a UX forum information about the team that had been published in Business Week. This is all the antithesis of scientific exploration; we can't get far, much less consistent, without sharing, and collaborating.

What am I doing to help?
For several years now, I've been gathering up my mobile design elements (and other stuff, like touch guidelines, and type info) as a document, and sharing it with everyone as Mobile Design Elements. It includes a lot of components from deadly-secret projects, just pulled out of context and categorized so you can't figure out secret things. You can go get it from a page on my wiki there, where I share it alongside everyone else's stencils and templates. Use it as you see fit, share again, modify, etc.

Mobile Web Resource Site:
Since the book came out last year it has sold pretty well, but I’ve still made no money from it, and all mobile inquiries that O’Reilly gets have been going to other authors. Looking back I would have been better off making all the text of the book free and public... but that is another story.

I agree we need one. I've been adding to a wiki of mobile resources for years under the Little Springs auspices. But no one else much did. And that is probably dead now anyway.

What am I doing to help?
I am one of those guys that O'Reilly is sending inquiries to. And (with Eric Berkman and some of our former interns) have been working on it pretty seriously for a month or so. It's just a patterns book, and it's general mobile, not just web, but I am trying to make it useful and well-researched.

And most of all, part of our agreement with O'Reilly includes letting us put all the content on a wiki. So, I started a new one, and have added the whole outline, a dozen patterns (more every day) and a bunch of other resources:
http://www.4ourth.com/wiki

Please help. Or, don't contribute, but do feel free to use it so we at least all have the same language we work off. Since I am trying to write a book, and there's a deadline, try to be respectful of the info, and accept when we are jerks and cut off discussion in order to lock at least a version of a pattern, so we can move on.

But do please help. I want this to be a community effort, so want to hear from you guys even if I disagree.

And if you wondered about the name, it's mostly short and cool, but also because I think "2.0" is over used as hell. And if I think about it, I think we're in mobile 4.0. Explained slightly more at the home page for the whole site if you really care.

Mobile web zengarden:

I think even the desktop web is still missing the permanency and credibility of print design by having no big awards shows, or exhibit spaces. Mobile is far worse, due to the even speedier and broader variability of the devices. I am not sure the CSS ZenGarden approach is the way to go for this (and I'd like to see one less web-specific) but something is needed to let everyone see, to get good ideas (and preferably with implementation tricks shared also) and maybe a way to judge or rate for suitability, somehow.

Mobile 2.0 CSS Framework:

I know way too little about this one, so will leave it to others. I do worry a little about a major facet being so focused on the web. And not because I like apps. I like... everything. What about principles OS developers can follow? What about tools to encourage development of services, like SMS and location? Oh, and what about js libraries? And other plugin technologies, even for web alone?

I quoted Umair Haque in the final chapter of my book in his call for the Next Industrial Revolution and I’ll quote him again here...

There are days I almost hoping for someone to plot from their secret volcano base and take over the industry – even with something sorta crappy or restrictive – just so there's a single experience. Not just a single browser, but so interop becomes not an issue, and I can get location from the handset to the web, and... so forth. Way, way, way, too much stuff is locked out or restricted because of perceived quarterly returns, and I think everyone would be better off working together on standards.

Clearly, none of us are CEOs and going to be able to go out on a limb (at least one strong enough the board won't fire us) and make this happen at any one company, much less across a whole chunk of the industry. So we need to start working, together, towards the goals Brian laid out. To work together, to gather ideas, to share them, to have goals as a community. And to talk about all these as a single community, so we speak the same language and start working together, instead of against each other.

Carnival #241

2010-10-19T10:07:00.003-05:00

This week's Carnival of the Mobilists is hosted by mobile strategist and marketer Martin Wilson of indigo 102. I'm happy to be included again with all the other smart designers, developers and mobile thinkers.

The Carnival is a weekly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well.

Context, or NOT…

Mobile context – As a road sign. Steven Hoober, Urges to think about users and think contextually. Mobile ‘Context’ is ever present in the ambitions of many when designing mobile applications, websites , interfaces and even phones. But somehow, it never gets really understood by many.

Next week the Carnival has no scheduled host. If you would like to host an upcoming Carnival of the Mobilists, drop Peggy Anne Salz a line.

ALREADY Seeing Significant Mobile Traffic

2010-10-15T17:52:00.003-05:00

“ It used to be that us mobile folks like myself had to convince someone with a website to build a mobile version in the hope that they could then tempt some traffic their way. However, it’s a much easier discussion to have when the publisher is ALREADY seeing significant mobile traffic, and they just need to make the decision about how to serve it better. ”

The increasingly quotable Mike Rowehl in Thank You Twitter and Facebook, about how we've finally passed some tipping points in corporate mindshare; the chicken & egg proposition is over, and seeing traffic come from mobile (via, especially, twitter and facebook) makes them want to optimize mobile sites and build mobile apps.

Mobile Context - As a Road Sign

2010-10-14T14:55:00.004-05:00

Okay, I think this went poorly. But I am too lazy to try again, and no one else wants to take the videos again either. Poor camerawork is from the 14 year old down the street, and I periodically look like I have Parkinson's or something, because... I have no idea why.

A transcript, edited to make it a bit more sensible, is below the video, if you hate video (like I do) or just can't stand to watch any more after a while, but want to know where I am going with this.

Context is something we talk about a lot when designing mobile applications, websites, interfaces, services and even phones. But somehow, it never gets really understood by a lot of people. They say "what do you mean by context?" And we end up explaining it to blank stares, and using lots of examples.

I think this is because everyone is still used to the desktop. Context on the desktop computer means this window is on top, and this other one is sort of underneath that first one. But that's all it means. Because the rest of the time I am just sitting here, in a comfy chair, facing my computer. There's lighting, you are indoors, the screen is at eye level, arm's distance away, there's a full keyboard centered below it, and a pointing device off to the side.

A lot of people talk about mobile being "little glowing rectangles." But I think that frames the whole discussion wrong, because "little" isn't the key aspect of the device. And "rectangles" makes it too similar to the desktop, which is just a bunch of smallish rectangles (windows) inside a big one (the screen). What's different about mobile is the environment. I can be walking down the street, having dinner with friends, riding in a car. Or watching TV, and I keep wondering "who is that guy?" and instead of not knowing, or referring to a book, or going and getting on the computer, I can just pull out the mobile handset and look up this, or any other type of information, any time I want to.

Mobile is contextual, in the sense that it works all the time, wherever you are, within your social environments, within the structure of the rest of your life.

The reason context is important is that it's what we live in all the time. Walking down the street, or driving to get a new license plate for your car. Putting aside your phone for a moment, you can understand context with analogies to other, actual interactions with the world. Like driving down the street, trying to understand traffic signs.

Very near my house is a County building, where they do lots of stuff. Vote, get public health services, day care, crime lab, etc. And most people know it as the place where you go to get your new license plates, and pay the taxes for that each year. Most people who live in the area come here, but maybe once or twice a year.

They come down the little street that passes by it, and as they approach it rings a bell. They can see the building, and they see a nice wide driveway to a parking lot. When they pull in, they see this:

Actually, one on either side of the driveway. Off to the side is another that warns "Sheriff's Department Parking Only!" But how does anyone driving down the road know that. Because it was not placed usefully for the context of Driving Down the Road. The sign is aligned with the driveway, and is almost totally invisible (edge on) to people driving down the road.

If you aren't thinking about mobile design the same way, you are going to do the same thing. You are just putting up road signs in useless places also. It's easy to break up projects into pieces, and inherit process. It's easy to design for the way products are developed or built, or the way the old business process or legacy datastore gives the information to you. Or even just because you are designing it on a desktop computer, in that environment.

And if you do this, you can easily forget about things like lighting conditions. Or the fact that minimum touch targets are only for sitting still, and people walking or in a bus have wobbling and vibration to fight with. You have consider the way people will actually use not just mobiles, but your mobile product specifically. Failing to do this will cause errors, frustration, and eventually people will stop using it.

Sure, draw on the desktop, and use emulators and simulators to get the gist of things. But try your products out in real life. Bring paper mockups outside if you have to. Try competing products. But put them on phones and take them home, on the bus, and onto the street. Try them in the sun, in the dark before you go to bed. Take the bus or train for a change.

Think about your users. Think contextually.

Carnival #240

2010-10-13T12:42:00.006-05:00

This week's Carnival of the Mobilists is hosted by Eric Chanat MobileSlate. I'll happy to be included with all the other smart designers, developers and mobile thinkers.

The Carnival is a weekly collection of the Web’s best writing on mobile and wireless, hosted and collected by a different site each week. If you are already reading our blog, or anything else mobile, you should add this collection to your subscription list as well.

Steven Hoober writes this week about What Mobile Convergence Means.

my key takeaway for designers (and product developers, and marketers, and everyone else really) is to make your mobile services decently useful, pretty darn usable, and really, really easy to find.

Next week the Carnival will be hosted by Martin Wilson at indigo 102 so give them a visit.

Web App Store

2010-10-08T13:00:00.004-05:00

I am gonna eventually post more a (mostly enthusiastic) response to Brian Fling's Mobile 2.0 thingy, eventually.

I'd actually like to support it directly, and will, but need to work out technical and legal bugs first. Working on it, every moment I am not applying for work. I promise.

But for now, I had this thought. At Design for Mobile, and I think a few times since then, I heard someone say "why aren't web apps in the App Store?" I don't know who said it first. Someone tell me and I'll edit this to credit them.

It's a truly great point. And I was just thinking, we don't even need to just dream this. Or lobby Apple, and Google, and RIM, and MS (et. al.) to do this. As long as we're willing to start with free things especially, anyone could just make an app (let's say) called "Web Apps Catalog."

One of these for each platform that anyone wants to make it for. Get it into the App Store, Marketplace or other catalog for each platform. And then it would work like the native catalog. Only sites expressly passing [some quality level] on that platform will be allowed in. There are ratings and descriptions and so on. Selecting one gives you the choice of just going there in the browser, or adding an icon to the app list/home screen.

In the example, I've thrown up the IMDb icon, because they don't seem to think mobiles get all information. I de-installed the app, and have to jump through hoops to use the desktop site on my handset. Yeah, desktop site isn't the best answer for our ideal world of webapps, but it's a good example (I think) of how a webapp is a good alternative to an installed app.

Easy, fun, and I think a rather adequate starting point for pushing the value of mobile web apps, on an app-hyping world. Of course, I have no idea how to make it, so someone do that for me. Okay?

Facebook is Huge. No, SMS Is. No...

2010-10-06T08:58:00.005-05:00

Periodically, the XKCD comic posts these giant diagrams, of real things or virtual ones. Like this, which represents the relative size and relationship of all online communities as physical lands:

Which is cool, and wow the size of Facebook sure is huge. (And yes, some of the info is a swag, but it's all plausible). Anyway, then I looked in the corner.

And if that's impressive, check out how much more information voice over mobile ("Cell phones") carries.

And don't forget people just talking to each other.

An Equivalent Amount of Annoyance

2010-10-06T08:40:00.003-05:00

“ First, the point of a developer device program is to lower the activation energy necessary for a developer to put something together for your platform. Meaning, if you’re offering a program to get me a $500 device to encourage me to make something of value on that platform, you can’t just replace that $500 with an equivalent amount of annoyance. ”

Mike Rowehl discussing Developer Device Programs, and how so many OEMs (but specifically Nokia today) are bad at promoting development on their handsets or OSs.

F8 and Be There - What Mobile Convergence Means

2010-10-05T19:00:00.016-05:00

I only took so many notes, but I /think/ it was Josh Clark who said at Design for Mobile 2010 the other week something along the lines of "the best notepad is the one you have with you." And went on this for a while, then I left the room to solve some other crisis, I am sure. I also don't think it was this presentation but that one's pretty good also. So read it.

I was wrong. Jason Grigsby wrote to say it was his presentation. Which I cannot find, but all of his are good, so go browse some of them: http://www.slideshare.net/grigs

My busyness trying to run the conference – among other reasons – is why I am just now writing about this. I probably missed the good bit. And I had to let it stew a bit, and wait for my brain to get back into designer-mode. But it immediately reminded me of some stuff. And that stuff reminded me of... something. Which I think I have a handle on now.

My dad was a photojournalist (then a PR guy, notably for the KC, MO police department, and so on. But that's not important now). He raised me right, photography-wise, which is why I am always the photographer (such as at d4m2010). I have, for example, no lenscaps.

Before there were "Auto" settings on the dials, photographers referred to their exposure settings as "aperature at speed." F5.6 at 125th. And so on. A story he relayed to me, and which I heard later in many similar ways, is that the cub reporter is sent out to cover, oh something. He asks the competing, but friendly old coot next to him how he should be shooting this particular news event, which will happen at any moment. The reply is "F8 and be there."

Now, the key of this isn't that F8 is the right exposure for everything (though it's not bad for outdoors, with reasonably slow film), but the "be there" part of things.

The above is a diagram I drew for another presentation. If too small, grab the PDF. I drew it two years ago, actually, so it is predicting the future in this diagram. If anything it understates the convergence. For example, sales of dedicated MP3 players (the thickness of that green line) should be shrinking even more, as even larger numbers are finally to the general mobile devices with embedded players.

But what does it mean? Not just convergence in general, which could confusingly mean anything. Does it mean devices are confusing? Does it mean that sales of other items will be cannibalized? More importantly, what do I do about it?

Well, what Josh's comment made me realize is what this means. It's that we need to design for these everyday cases. A key context is "convenience." Can everyday users be aware of, find, and use all those add-ons, and add value to their lives (and stickyness to your device, os, app or site) as a result of it? Contextually, the mobile can be a notepad, a camera, a game, a message center, a music player... No, that's wrong. At any one moment, for any particular user, it can be the notepad, the camera, the game, the message center, the music player. The one and only version that matters, at that moment.

I carry... okay, most of this stuff every time I leave the house, and still end up using my phone as a flashlight, or to take notes, and am sad I can't pay bills with it. If it had a folding knife, I'd be set. If I was making my own choice of device for maximum productivity (vs. being a full time mobile nerd), I would probably pick one with a darned good camera, because I care most about that. So one key tactic is that you can design devices that are particularly good for a market. Photography, music, messaging. These exist. Eventually we'll see a game phone that sticks. But phones are no longer phones. They became general purpose computers some time back. And I don't mean the CS definition but the utility definition. The mobile device (you can't call it a phone anymore) is suitable, or satisfactory, for a large set of needs.

Indeed, it's satisfactory for an arbitrarily large set of needs. And a key attribute of smartphones (with their installable apps) or practically any connected device (with the web) is that it's infinitely customizable, and changes moment to moment. Mobile phones, even into the text messaging era, were among the most pure appliances that maybe we'll ever see. Now they have turned into anything devices (and merged with other appliances, like PDAs and GPS), the convergence chart means any task a person can do, that is at it's heart information-centric will be subsumed into the greater mobile experience. Sensors mean that lots of not-pure-information tasks will begin to merge with this also.

And if that sounds like the robot apocalypse, it's not. Quite. Remember, this is still satisfaction, not always delight. Not always perfection, or professional-grade, or the most efficient way to do the work, or even the most satisfying experience. It's the good-enough device, because it's always with you. There will always be a market for pen salesmen, and professional cameras.

So my key takeaway for designers (and product developers, and marketers, and everyone else really) is to make your mobile services decently useful, pretty darn usable, and really, really easy to find. If your MP3 player or payment scheme is buried under menus and legal agreements every time it starts (like GPS often is), customers will just keep carrying an iPod or wallet anyway. It becomes functionally un-converged, and you missed out. Or, they buy someone else's device that is converged enough.

I also think it's important everyone (at least at work) stop saying "cellphone." Do everything you can to get your mind wrapped around the world we already live in. It's not tomorrow, but has already been going on for years. While telephony is still a key killer app, it's an app. Literally software that can sometimes be replaced with another – just one application among many. The device in your pocket is no longer a phone with add ons, but a general purpose computer that fits in your pocket. The future is here. And it's mobile.

Designing Device Documentation - My D4M 2010 Presentation

2010-09-30T14:27:00.006-05:00

I presented last week at Design for Mobile 2010 in Chicago. For various reasons, I did it with no slides, and no projector. Well, I used a projector, but no computer. Put everything in the Elmo camera, from phones to specifications to a couple pages that are frankly slides, and pointed at stuff and walked around the room.

Which was great. I think. I enjoyed it at least. But there's now a problem with no slides. Which is: No slides. I don't know how to share it. I guess we should have captured it live with the magic silver box, but we didn't. So, I did have notes, and one of the documents was already shared and I added just a few pages to it, so, I guess I can share most of the stuff I brought with you after all.

The document with the operator overlay specifications, the design objectives and so on, is HandsetSpec-2010sept15.pdf. It's about 2 mb, so brace yourself. If you really need the InDesign file, ask me and I can point you to it.

Sadly, even redacted I think the eReader work is a bit secret. So, pretend I didn't show any of you. You can't have that part.

The notes are on this prettily-formatted PDF, Device-Design-Deliverables.pdf but I'll also just stick directly in text here. I made them in a simple text editor as it was, anyway:

0) TITLE: Designing Device Design Deliverables

Color cover sheet on Elmo.

1) Who is here?

I want this to be interactive, so don't mind me if I wander, and feel free to yell out if I say something confusing. And I'll start with a survey: Why aren't you all learning about iPads? I mean, Apple is gonna take over the world, right?

Seriously, I want to make sure I am talking about stuff relevant to your jobs, so raise your hand if you design devices or device interface directly?

How about if you work with or for an operator/carrier on their home deck, or other customization?

Who else is left? ... why do you care about this?

DISCUSS

2) Designing Device UIs

I think this topic is important for everyone.

Because we are all designing device UIs. And that's not just overdoing the semantics -- Really thinking about interactive design holistically, contextually, means each little app is device design. Your product can change the user's perception of their whole interaction with the device. So your app or widget or site better be mobile (and when possible comply with the device design paradigms) or you are ruining the device UI.

So, you better understand what the device's native UI means.

3) Design, or Modifying Design

And, you should know what "Native" even means. For example, what I call overlays.

Have two RAZRs.
The black one is a world phone, straight from Motorola's secret volcano factory, exactly as they intended it. The red one is a Sprint phone my dad used for years. Basically the same model, but... three softkeys, etc. Different UI.
And for those that say featurephones don't matter, there are 2.1 BILLION of them out there. Vs. 620 MM smartphones (and only 80 MM iphones).

3a) Yes, Even for Smartphones

Have Hero, Galaxy and other Samsung, at least.
Same for smartphones. Look at the array of android devices I have here. Not the hardware, but the UI changes. Some with variations as the OS marches on, but some with OEM customization, or with Operator demands.

4) Design and Documentation

But I want to talk more about documentation than devices themselves, or design of the devices.

I have always believed there is a strong relationship between design and documentation. There's no such thing as internal (in your mind) design. A design is only valuable if it can be put on paper.

In a meaningful manner. For specifications, there's another key attribute of this. A design is not valuable unless you can communicate it to other people.

5) Converting Document Specs

About 18 months ago we got a project from a large national operator to, basically, fix their featurephone device specification. Since then we've done the same for a series of smartphones for the same people, and have written device design specs from scratch for a tablet/reader device, and so on.

I turned a lot of my previous documentation best practices into actual codified postulated on that first operator project, and confirmed them since then. Since it's /semi/ recent, as well as easy to disguise, so I'll be using it for most of this discussion.

Original device spec (redacted) with KA&A.
This was the original, historical, specification for a particular state of a handset UI. A requirement or two, and often /pages/ of tables outlining... really not very much. This is a "Key Assignments & Actions" table, covering what each hardware key and what each on-screen key, do in the particular state.

But these tables were /rife/ with errors. And most errors were inconsistencies. Needless extra confusion to the end user, and if executed needless extra work for developers. Early in this project it was obvious these had to go. It took a bit to decide what format to settle on, but eventually I settled on this:

Printout of new KA&A drawing, both in the requirements and the intro one.
The vast bulk of these Key Assignments are the same across the whole interface. So, they are defined on this page up front. "Up" moves up, when there's a list or array, for example.

When you look at a requirement, there's a little compressed version which refers to it (at the bottom) and the little colored keys are the /exceptions/ to the default states.

What I've already started doing is discussing some general principles of design -- you should make up design objectives for each project, but these are general design and documentation principles.

6) First two design principles

Printout of design principles.
CLEAR – Remove ambiguity and the ability to interpret documentation in multiple ways.
CONSISTENT – Terminology and document style should be employed consistently for all requirements and documents.

7) Rest of the Design Principles

Let me explain the rest of these principles, as they apply to this same Key Assignments chart. I could use another example, but this will shorten things, and it's a pretty good example of the process.

EXTENSIBLE - Use systems, such as permanent requirement numbering, that will not expire rapidly, and do not need to change as documents are added, removed, merged, or modified.
It doesn't matter if you add or remove a key, or even if the method moves towards on-screen display. A version of this exists for softkeys. If you don't think that, say, the menu on Android is functionally a softkey, think again.

ACCURATE - Review for accuracy, but also design a process that encourages accurate documentation.

AVOIDS DUPLICATION - Design a system of writing, organizing, and storing requirements that avoids or eliminates stating requirements in multiple locations, eliminating inconsistency due to out-of-synch updates.
Remember how I said most of these tables were just repeating the default state?

REFERENCES - All references to other documents, other requirements and related tables, figures, or examples will be explicitly referenced in a consistent, repeatable, and discoverable manner.
This diagram refers back to the default conditions. And the same chart is used in other documents (the behavior of cameras is in a special document, for example) but the default conditions stay one place, in teh core document.

8) Document Consumers

But how did I get specifically to this style, or even decide these are the key principles of design documentation? By considering the consumer. Not the traditional consumer, not the end user, but the /document/ consumer.

Here, mostly the developer. Now, where are they?
Do they speak English as a first language?
Do they work on your products full time?
Are they new, or experienced?
Do they use your documents, or have their own requirements management system?
Where are they located?
Can you talk to them?
How do they receive the deliverables?

These are just some of the questions I actually asked. Because over the years I've developed a lot of heuristics. I understand all sorts of user types. But sometimes a new one comes up. And frankly this is a user we hadn't really examined, even though we worked with them. So, we did research. Sat down with them and found out how their process works, at several different manufacturers.

Then just like working with different types of people, made a best-guess median consumable. With the principles above, but also tactical and operational details like:

Images to side of text.

Dual coding (pictures and words -- most use both, but some see pictures better, some see words better).

Flow chart of section front.

Glanceable documents (Pictures again help, but also diagrams for the introduction, and clear titles on each page for scanning and finding).

Piecemeal consumption (Do not assume anyone starts at page 1 and reads to the end. Even been in meetings where development mangers literally ripped a document at the staple and gave pages and sections to his team. No one gets the whole document).

9) Componetized Design

Reader IA/Components.
You are probably bored of my key assignment chart. So, let's talk briefly about another example, not just of documentation but where design was influenced by the documentation.

Months and months into the design of the software for this reader/tablet device, we got down to some of the "boring" parts, and I had to go add battery levels, and wifi connection settings and so on. And the first cut done (by the other designers mostly) was the sort of default. A whole bar at the top of the screen with icons for everything. But it bugged me.

Not just from a page design point of view. After a few days work I realized I was being bothered by the documentation of it. The document had been built to support the componentized, re-usable view of the device UI, to encourage developers to build it that way, as well as to encourage all the design teams to keep existing components in mind.

Reader Notification with Some Settings Open.
So I realized that by adding a component we had violated this principle of the design. Even though we had executed as a "common practice," in this case it was not a "best practice." I looked fresh at the whole structure of the design and found it fit seamlessly into this notification system already built for social aspects of the service.

Reader LED settings.
Much the same happened when LED settings were developed. You know, the colored light that keeps you awake at night while your phone is charging. Besides considering context like that, I just considered how the system was already designed, and tried to slot it into an existing document structure, even though it was at first glance well outside the scope of the on-screen IA.

By considering it as part of the overall design, it became part of the overall experience. And this device doesn't have a light that blinks randomly, and you wonder what ever orange means that is different from green. On-screen behaviors are coupled to them, so it's immediately understandable.

10) Conclusion

Scientific discovery has to be reproducible, so anyone else can use the same procedure, and get the same results. John M. Barry wrote that it also has to be extensible, so others can build on it.

I hope that we're now to the point where Interaction and UX design are becoming repeatable, and even scientific. I hope that the sort of work on design, documentation and process I've shown today can be valuable to you as something not just reproducible for your work, but something you can extend, modify and improve upon to make all sorts of products better and better.

11) Questions? Comments?

Tailfins & Chrome

2010-09-30T13:44:00.004-05:00

For several years now, I've been enjoying mobile design as an exercise in streamlined, contextually-relevant design. Sure, it's also pretty or emotive, but that's for marketing. To get people in the door, or make their first few experiences matter.

And then I saw a handful of OSs last week at Design for Mobile 2010 in Chicago. Or, more importantly, I saw the reaction of the designers and developers. I saw the attendance of various sessions. And my reaction is that right now it doesn't matter how useful something is, but how cool and new and exciting it appears to be.

Just look at the above image. The 1949 Ford is a technical marvel. Even the frame is innovative. This ad talks about the braking most of all, but covers all sorts of additional features. The Cadillac of the same era (the 1948, actually) is entirely show and bluster. Yes, those are tailfins, the first ones we'd see of a long line of them.

Now, the '49 Ford sold great. Because it was a terrific car, really a modern car in every way. But very, very soon the whole style looked dated. And I'll note Ford never did adopt the tailfin thing, and sold just fine despite this, throughout the crazy tailfin era.

I sorta think Nokia is Ford in this tale. S^3 (and the stellar hardware) is shiny enough to please anyone, gets the work done, and is rock solid. But it doesn't apply a brand name to the display. It doesn't have animated squares on the idle screen. Etc. It also does keep selling (Nokia still by a wide margin the largest smartphone seller, worldwide), but does anyone talk about it? Naw. Not really.

Who got the attention at the conference last week? Windows Phone 7. Else, which is pretty cool. An Android tablet someone was carrying around for work. iPad and iPhone strategies, and Apple didn't even show up themselves. Hell, even a pre-release Android I had got grabbed for some ooh and ahh time.

In case you assume I am only being cynical, I am not. I am partly disappointed and cynical, but I can work with that. What it means to me is that my ideal OS is clearly not functionally the ideal thing to bring to market. If you hired me to design a new OS, or browser interface, I would know that it has to have something totally off the wall, just to have a hook for everyone to latch onto.

It also means I have some hope for the future. No, it's not that everyone buys cars today based on their specifications. But in the 1960s, people also bought VWs. And after this was the muscle car era, where specs (and the appearance of having high spec) was critical. So... things will change, and my biggest takeaway is recognizing this trend. And that the mobile market is advanced enough it has trends. Not just winners and copycats, but market-wide consumer-level trends, which are worth exploiting, or understanding so you can try to undermine them.

Sorry for the template

2010-09-30T13:43:00.002-05:00

Redoing my site, and the new template doesn't immediately apply well to blogger. Since there is too much else to do now, I just picked one that wasn't too offensive so it's readable.

I'll fix it later, especially if someone reminds me.

Wednesday at Design for Mobile 2010

2010-09-30T11:02:00.000-05:00

Nancy Proctor started out the day for us by talking about the challenges of using mobile technologies in the museum space. Today, museums are both choosing and being forced into figuring out how to take themselves into the future. Nancy's argument was that just relying on technology will not let them get there. Instead, a modern museum must understand what it has, and do everything possible to understand what their audience wants.

After a break, Scott Jenson came back and focused his speech on the coming zombie apocalypse. The question he posed to the audience was: why can't we take the mess we have now, and the chaos that the mobile space is about to become, and build something to make the little pieces understand each other? With the cost of chips rapidly dropping, mobile devices are going to be everywhere, and the potential will be limitless. At that point, the device you have might not matter; instead, your choice will be based on what apps it has, and how well it integrates with everything else you're already doing.

Carol Taylor Mobile Web – Devolution or Evolution?

Josh Clark in his talk titled: iPad Design Headaches: Take Two Tablets, Call Me in the Morning took us through a tour of the massive trial and error being attempted on the iPad. Designers are being given this new object and have been asked to figure out how to use it best, but are sometimes not given the time to actually do it well. Everything from Greedy Pixel Syndrome to FrankenInterfaces are the result. Lessons can be learned from what came before, both of what you should and should not do, especially with something as dynamic as the iPad.

Steven Hoober, Designing Device Specifications

After lunch Kevin Arthur, in How do you evaluate gestures for your system?, talked about a very in-depth research study showing Synaptic's work on gestures. In between results of the study and suggestions on running studies like it, he gave a little bit of insight into how computers understood gestures. As useful as gestures are and as powerful as they can be, gestures have to be taught, since they don't have any affordances.

In Between Here and There: Navigation Design for Mobile Ryan Unger described the 3-minute rule: users need to take little bites from mobile phones in order to appreciate them. He stressed the importance of searching outside of your comfort zone for new ideas. By crumpling up old ideas people are able to redefine what they thought was possible.

Dan Mauney then took a look at a study done to figure out which gestures people actually use in his talk entitled What gestures do people actually use?. His international study asked people about which gestures they associate with which actions; and he tried to see if a pattern of use could be built from that study. In an age where touchscreens and gestures are going to be everywhere, understanding what those gestures need to be is even more important.

Tim Deluca-Smith explained how consumers tend to remain price sensitive and will forgo features for price. In his talk titled Do Smartphone Users Need to be Smart?, he came to the conclusion that this Is most likely because users do not understand the quality of such devices.

After our break that was sponsored by Artisan Talent, Nika Smith from Blink Interactive talked about a study she did, focusing on the usability of different smartphone keyboards. The two devices she centered on were the iPhone and the Blackberry, then had those users test out the Evo 4G and the new ShapeWriter keyboard. Some of the results were what people would expect from our devices, but the surprises showed why these kinds of studies should be done.

In Designing a billion dollar user experience Karlyn Neel explained how users want to feel smart for the decisions they make. The new eBay app exercised constraint and displays information in an easy, efficient, and simple UI so consumers can easily understand it. She shared many of their design principles and the use cases they set out for the app and the stories of their failures and how and why they got to the end product.

Corey Pressman wrapped up the day with the talk World Class: Global Mobile Textbook Strategy which was about the future of textbooks on mobiles. He started with the first mobile, ubiquitous technology: stone tools; then connected that to what's happening in the field of mobile devices. On top, Corey layered a call to action, trying to do everything possible to bring an ecosystem of information to the next billion mobiles.

We ended the day with some drinks, entertainment and socializing with the fine folks from Motorola at their event: Mixing. Mingling. Motorola..

Tuesday at Design for Mobile 2010

2010-09-21T11:01:00.000-05:00

The first full day of talks at Design For Mobile 2010 kicked off early with Jonathan Brill giving a talk entitled Future of Mobile UX. In it Jonathan explored the potential of UI/UX in mobile using various concept videos as discussion fodder. He explained how mobile 3D screens show promise but the trick comes in trying to interact with something that doesn’t exist.

After a break Michael Horn from Northwestern University started things back up with Emerging Interactive Technology and the Museum Experience. He explained how users can get caught up in device capabilities and forget to think about the interaction with the content. This is a technology pitfall. Informal learning may be exciting and engaging, but it can be overly scripted and exclude other people. Information should be displayed in a way people can understand.

Next up was Luke Wroblewski, who explained in his talk, Designing Mobile Forms, that although users use their phones often, and enjoy them, it is a bad idea to use them to collect forms. Different ways to make input easier include changing screen size, optimizing for a linear input instead of jumping around, and choosing immediate reveals in text fields instead of surprising users.

Along side Luke's talk, we a discussion of app stores lead by Markus Grupp from Rogers. In App Euphoria to App Exhaustion: Reconsidering the App Store User Experience Markus detailed the differences and shortcomings of the different app stores and how users respond to them. Interesting points included how app usage rates (which decays over time) as well as reasons why users didn't buy apps. He went on to talk about ways in which the app stores are broken, and what we could see that would help fix the problems.

Lunch followed this, where we gave away goodies from our sponsors. Be sure to come the next couple of days with your red raffle ticket from the conference bags for your chance to win some schwag!

After getting some lunch, attendees settled into one of two sessions. There was Frank Bentley who gave his talk Building Mobile Experiences: Testing rapid functional prototypes in real contexts of use. He showed us an insider's view of the Motorola's testing lab. 'Lab' may be the wrong word though, since they don't believe in lab testing. Instead, they focus on working prototypes, and testing in the field. Frank takes this approach since letting engineers and designers loose on interesting problems brings in great information. The sooner you have that data, the easier it is to change your course.

Up against Frank was Jason Grigsby with Web vs. App vs. Hybrid in a packed room. Jason approached this heated topic by telling the story of a decision they made at Cloud Four — should they become an all-native development shop? There are advantages to going all web and to going all Native. If you need great performance or are building something like a game, native is the answer. If your budget is limited, go web app. But really, it's much less black and white and is more a spectrum of solutions? As Jason said, his answer to the question "Native or Web?" is "Yes." Oftentimes a hybrid approach is best.

In The Future of Cloud Service Integration in Mobile Devices Josh Campbell and Elisa Vargas jointly talked about MotoBlur, and the future of cloud integration. There are a lot of things that the cloud can do well, and a few things that it can't; the trick is in figuring out what those strengths and weaknesses are. Most of those weaknesses can be handled by caching important data locally, and MotoBlur was designed to take advantage of exactly that.

Ian Homer in his talk UI Development for Multi-channel Web went over a method of implementing web apps that are customized to the devices you choose. After deciding the classes for the various devices, you start with a baseline and then lay over enhancements that suit the device you will be serving the content to. For example: say you want different nav for the iPhone version of the site than you do for the one that gets served to a RAZR—you could do that. Ian's company, Bemoko, has implemented this approach in their product BemokoLive.

After the afternoon break, in Designing Resourceful Mobile E-Commerce Search Greg Nudelman put forward an excellent argument on why we should kill all the lawyers... or at least why we should understand just how much information and wasted time our mobile users are willing to handle. Search is also very important, and app makers should know that “Zero search results is not an error, its a natural effect in a system that deals with users.”

Finally, in Why and when to design for mobile first a panel of experts (Luke Wroblewski, Steven Hoober, and Scott Jenson) moderated by Barbara Ballard. Most of the discussion was a lively argument for Mobile First, and why mobile browsers have a strong chance of overtaking and leaving the desktop web in their dust. There was also a lot of discussion on what leading competitors and mobile companies are doing with their mobile experiences (both for better, and for worse).

Why can't you use the cool stuff you already have?

2010-09-07T05:57:00.000-05:00

“
...why can't work keep up? Why are you forced to use an unfamiliar, and sometimes outdated, operating system? Why do you need a second laptop, maybe an older and clunkier one? Why do you need a second cell phone with a new interface, or a BlackBerry, when your phone already does e-mail? Or a second BlackBerry tied to corporate e-mail? Why can't you use the cool stuff you already have?...

...security is on the losing end of this argument, and the sooner it realizes that, the better.
”

Trying to solve the wrong problem

2010-09-01T11:33:00.000-05:00

“
The problem is that every company out there that’s addressing this opportunity, from Sony to Samsung to even Apple, is actually trying to solve the wrong problem. None of them are really asking how they can fix the living room problem. Rather, they’re focusing on establishing their brand in the living room, positing completely unrealistic scenarios in which a consumer buys only, say, Samsung-branded components (e.g., its absurdly useless WiseLink protocol) without acknowledging the reality that the components of most home theaters make for a decidedly heterogeneous world.
”

Khoi Vinh on Subtraction discussing how Apple Blinks in the Living Room by pursuing a strategy of pushing it's brand into an existing space, instead of cooperating, or making things truly simpler. The problems of the interactive second screen are similar to those of the fourth.

Influencing the Requirements Process - Designing Documentation, Part 2

2010-08-26T11:32:00.000-05:00

Specifications are hard. There are a lot of conflicting needs, and the complexity of the documents might be more severe than the product you are specifying. Aside from designing products or interactions or interfaces, I spend a lot of time designing the documents themselves. A happy ending to this sort of process is detailed in last week's post on Designing Requirements Documentation.

Which might bring up the question: What type of specification? Design documentation, which is most of what we do (well, by hours – most actual documents by count are proposals and emails and so forth) took a long time to settle on, but it has evolved into something pretty specific and which works very well to communicate to everyone on the entire project team. There have been several evolutions, many mandated by technology alone; I used to do everything as a single sheet which functioned as sitemap and flowchart and detailed page/state layout. But when I had to work with more remote teams getting 36" x 10' pieces of paper to them was more difficult and had to change to something else.

But complete technical specifications are still something else. There are also content specifications, style guides, and lots of other documents. But today let's talk about the general technical specification, that developers use to build or modify software or presentational code to meet your design needs. Integration of technical specs with design has always been an issue. I've spent a lot of time messing with my deliverables to make them comply, or revising them to be pasted into the appendix of an IT specification. All of which is fairly unsatisfying and never helps much.

It is also important to believe that design documentation is good, important, valid work. We spend a lot of time buried in IT process, and I have to fight even people here at Little Springs to make them believe that our work and our method of work is valid. Sure, you can use IT requirements documents to do your work, but that's not their intent, and there are better ways to do it.

After a lot of work imposing myself and my team into the development process with our own documentation, way back around 2002 – while working at Sprint, I got to work my design documentation directly into the technical specification. At the time, Sprint IT used something called Application Design Documents, and I was able to persuade them that the UX team could do the best, most efficient job of making some of the document.

Note that the text and tables are in the IT format, specifying the behavior of each widget in a specific manner. And the screenshots (I prefer other methods, but this is what they could handle at the time) are placed in a process-compliant manner, but there are just about 20 times as many as usual. I also did a lot of the writing, or at least editing, of the specifications, so when it was done both the IT analyst and the whole UX team agreed on the behavior of each and every feature.

This product, both by design and implementation, was a high-water mark in ease of use in my career. Web-initiated SMS with millions of uses a day, without a help system and hardly any error messages, with impossible uptimes and no measurable customer complaints. Almost unheard of for a mobile telecom operator, at least in the US. And although it took forever to create the document, some of this was simply getting everyone involved used to the new process, and we saved a lot of time correcting errors and explaining stuff in development.

But then that dream died. After a few months of work, a big fire-everyone-for-IT-outsourcing binge left disappointingly few software designers and analysts in house. I had to start all my relationships over and reconsider how all deliverables would work with random, far-away teams using them. So for the next few years I made do by improving my design documents, communicating with project teams as much as possible, and actually writing requirement documents when I could.

Writing requirements

Which became a key task I tried to accomplish. If the UX team got engaged early enough (which is always a problem) I pushed to review and approve the requirements. Then I found out no one wants to write them, so simply volunteering gave the UX team lots of additional authority.

A key reason I like working on requirements is that they are often poorly done. For example, Business Requirements and Functional Requirements are too often conflated. A BR document is very, very high level. It contains the goals of the project, and rarely more than a couple dozen, or that's a sign you either wrote them wrong or the project is too big to be completed. Some Business Requirements you might read are:

System shall have the ability to allow user to enter a street address and geocode it to a dynamic map displaying coverage and signal strength.

System shall have the ability to drill down from a national map perspective if no address on file for user (i.e. in-front of log-in).

System shall have the ability to allow user to enter only a ZIP code and geocode it to a displayed map.

System shall have the ability to allow user to enter an intersection and geocode it to a displayed map.

System shall have the ability to allow user to enter a City/State combination and geocode it to a displayed map.

Etc.

But this is dead wrong. System? And so very many. That's a set of Functional Requirements, and not a well-written set at that. But all is not lost. Assuming that the marketing and product people like these, you can redo them as actual requirements. A typical, well-written Business Requirement could read:

Allow customers to find coverage for a specific area in multiple ways: by entering a general location, a specific street address, an intersection, two locations, etc.

And this covers all those bad requirements above, and then some. Cases you don't think of at the beginning of the project are still in scope. A half dozen more like this and you have a project.

Functional requirements

A Functional Requirement on the other hand provides specifics of technical, logical, or presentational behavior. These are also boring, so often don't get enough attention. Oh, they have to be written to proceed through the IT process, but no one wants to do it, so they get poorly written. If you want to make sure the product gets built right, and that the implementation teams are doing what you designed, just insert yourself in the process.

Good Functional Requirements look like this:

FR-40 From within the Wired Web unified messaging access portal, a function will be provided for customers to move SMS messages between folders, (e.g., Inbox, Outbox, Spam).

Better written Functional Requirements help a lot. Some notes about requirement writing were in the earlier blog entry, so I won't repeat them here. But they better not all start "System shall" or "Ability to." Even if it's nerdy, academic, and technical, with otherwise annoying neutral-voice characteristics, use good english, first and foremost. The above requirement is written the way I like them all to be. First, the condition or state From within. Then, who can do it, here the customer, but the system may automatically do things at certain times or when certain conditions occur. And then, what happens. Pretty generally. An example of the folders are given, but there's not a requirement for each folder, and a comprehensive list is not given.

Not just because this would be cumbersome, but because it would be wrong. Remember, there are other documents and other requirements. The structure of the folders here is likely described in some architectural specification. So as part of this writing, be sure to understand the scope of the document, and how it works with the many other documents that are part of the IT process upon which you have imposed yourself.

The product is more important than you are

And after all that, it is a bit thankless. Your name will probably not be on the document as an author, and everyone will credit the analyst, who may not credit you. That's fine. Often, it's preferable, since UX is viewed with dark suspicion by parts of the organization.

Even as a vendor, we pretty often deliver work in someone else's template (or, have to create one that looks like the client's brand).

Getting the product right is most important; work on how your team is perceived later. Which is probably a good topic for another post in the future.

While I won't be hosting a process workshop at this year's Design for Mobile conference, there's plenty more to learn about mobile design, technology, strategy, research and implementation. Still some space available, so join us in Chicago next month.

Designing Requirements Documentation

2010-08-17T11:34:00.000-05:00

About 14 months ago, [a large mobile operator] came to us with an interesting project for mobile handset UI. There was practically no mandate to design the interaction itself, in any way. Instead, we were asked to take a muddled mess of poorly-updated Word documents, a compliance spreadsheet branched from it a couple years before, and a pile of notes, and make... something, that would be a better specification for OEMs to implement the operator UI on their handsets.

All their handsets (first, featurephones, but various smartphones followed as secondary projects). It's not just paperwork, but a pretty big deal, and influences a lot of hardware, so many millions of users. And in that, it's actually a quite honorable design job. If there's a design, and it's good (or good enough) but is not being implemented correctly or consistently, then a key job for a UX person is to get it implemented, right, and well.

I for one take design seriously. Everything around the office, and even the office itself, are designed experiences. Poor proposals don't get us work, and poor specifications don't get our work implemented correctly. Designing documentation, even when just overhead, is ongoing and valid work I spend a lot of time on. See the mobile design elements, freely shared, for a hint how much we pay attention to this.

The openness of this specific request gave me great freedom to maneuver. We designed both a document and a whole new document format. And we took that "design" step pretty seriously. The first step was weeks of interviews. First with the operator – and with several teams from the operator. Then, with the OEMs. As an example, here are the people that we directly interviewed:

Handset OEM product managers

Handset OEM compliance managers

Operator vendor managers

Operator development managers

Operator UXD interaction designers

Operator UXD graphic designers

Operator quality assurance staff

Remember, organizations are not monolithic, so teams from inside an organization may have totally different opinions or totally different ways of using a product. I knew this, which is why we set up so many interviews. And I was still surprised at how much variation we found, even with teams who work together every day.

For the OEMs, we sadly did not get access to all of them, nor to the document consumers directly. Like on a lot of B2B projects, there's politics and it can be hard to get to the right folks. But we got enough useful information by really prying and asking uncomfortable questions and absolutely promising not to share the direct answers with the operator. To encourage this sharing, there was no video record, just notes. And because of that, a backup note taker to make sure we got it all.

Then, we analyzed, and came up with some design principles. Which we had to combine with what the client team at the operator thought they wanted, and careful consideration of how each team perceived themselves. We didn't get far communicating changes to the overall process, strategy or organization. Though I got all excited about this, in retrospect that was dumb, or had to be approached very differently and more carefully.

So we dropped some of those issues (along with some great ideas for making it all a database) to focus on the print-style documentation and came up with these design objectives:

Clarity – Remove ambiguity and the ability to interpret documentation in multiple ways.

Consistency – Terminology and document style should be employed consistently for all requirements and documents.

Extensibility – Use systems, such as permanent requirement numbering, that will not expire rapidly, and do not need to change as documents are added, removed, merged, or modified.

Accuracy – Review for accuracy, but also design a process that encourages accurate documentation.

Avoid duplication – Design a system of writing, organizing, and storing requirements that avoids or eliminates stating requirements in multiple locations, eliminating inconsistency due to out-of-synch updates.

Reference – All references to other documents, other requirements and related tables, figures, or
examples will be explicitly referenced in a consistent, repeatable, and discoverable manner.

Which is indeed derived from the research, but could also be guessed from heuristics if I had paid better attention to the many documents I have made, for many different types of implementation teams – although it was nice to have the proof in front of me when discussing with the client. A lot of the specification methodology was in fact already in my head from writing BRs, FRs, and deleveloping design documents over the years. And, as I have mentioned for some of these blog posts in the past, I just had to write it all down.

For example, every item is numbered. And the numbers are internally meaningless. We use a Google Spreadsheet which everyone on the Little Springs team has access to (this is not it, just a sample). You just increment that value in the shared spreadsheet by one, and type the number in the requirement spreadsheet. The outline-format (e.g. "Requirement 15.2.3.1") is fraught with peril, and violates a lot of permanence and repeatability needs. It took a while to get everyone on this, but it's fundamentally the right way to do it.

And once you have permanent, consistent numbers, you can do other useful things. Like have notes and figures that hang off the side. In the final spec they are tied with nice neat lines. But no matter what happens to format, you can't lose them because they carry that number. And... oh, dozens of other format and process tricks I won't burden you with. Here's what the final spec looked like:

This is a sanitized version with no references to the operator. The real one was delivered with their branding, because that's also a key to communications with the OEMs. It happens for a fair number of our clients. Again, the project is more important that we are.

We also spent a lot of time analyzing and re-writing the specs themselves. A totally consistent method of writing was developed. There's far too much to include here, but some samples from the "Guide for Writers of Requirements" (not distributed to the document consumers) include:

Condition, Event, Result – Requirements should be written as full sentences, in the following format: Condition, Event, Result. Like this:

From any text entry screen, pressing the [FUNCTION] key twice will "Lock" the key and afford the continuous entry of secondary keys (hereby referred to as "Function Lock").

Here the condition is "from any text entry screen" the action is "pressing the key" and the result is all that about locking, and allowing continuous entry. Note that several preconditions, several actions, and/or several results may be expressed within a single requirement.

Define, then Expand – Requirements are written in groups, where the title, any explanatory notes and (often) the first few requirements will define the group, or define the function or tool or set of behaviors the group is about. All the subsidiary requirements expand on this core definition with specific behaviors, processes, and display details.

Free-Standing – Regardless of the grouping, each one should be free standing. The condition statement especially should set the full conditions. Never just say "on that screen..." or otherwise assume a context based on grouping with other requirements. Always give full names for each location, action, and item referenced.

And terms were standardized. "Handset" for example became the one and only term. Never "device," "phone" or anything else that strikes your fancy. Note the [Function] key reference in the sample above; square brackets mean a hardware button. These standardized terms and notations were then included in the introduction, with an explanation that the OEM implementation team could look up any term by simply searching for it.

We did a lot of card-sorting sorts of work. At once point we printed out each and every requirement. This was before we re-wrote them all and combined the dupes and errors, so we had around 9,000 little slips of paper. Which we stuck to walls in order to create categories and groups and sub-groups. Pretty much all categories from the previous document were discarded and rebuilt with this method. Which, in the interests of secrecy, we apparently did not photograph. Which makes me terribly sad now. It took up a pretty good percentage of the glass walls in the office at the time and was quite impressive.

And this covered the bulk of the work well. But even with re-structuring the document, it didn't hold together just perfectly. And, there were lots and lots of flow charts in the original operator documents. Like, almost 100 of them. Which really didn't do anything for me. No one else was bothered by it really, but like I said, we're designing a document and I didn't want the document to be just passable, workmanlike or good. As with anything I design, I wanted to take the opportunity to make something great. And here I sorta had the time to do so.

So, I began to focus on a systematic approach to diagramming with the hope of wrapping the flow charts back into the requirement text and making it all work together. I pulled a whiteboard over to my desk, scribbled boxes, and pondered things a lot. I also failed to take photos of this, so can only talk so much about the process.

Fundamentally, I realized that there wasn't that much going on in each section we'd created. I mean, the dialer shown in this sample (if you haven't noticed, click on the images to get a PDF of a few pages of this document) only consists of a dozen subsections, and a hundred and some odd requirements. If you go for that 2002 style of screenshots, depicting each and every state, it's dozens, or hundreds. Actually, I did some back-of-the-napkin math on this problem, and for some fairly small subset of information, it's actually like 200,000 variations.

No one is gonna draw that, much less maintain it. And no one can absorb this information and build a useful system from it. Which is a key issue with all specifications. Technical systems are so complex you can assume they are essentially infinitely, undefinably complex. So, you better come up with a better way. I solved this in two ways.

First, with modularity. I didn't explain them at the time, but in the gutter between the two columns in the spec page above, note those little drawings. They refer to these fundamental, reusable components that were pervasively applied. Many existed in principle, some we had to make up. And then we made all the drawings, in a specific style which you can find in the Mobile Design Elements document as "Mid-Level" diagrams. Because I couldn't come up with a better name.

These are shorthand for the basic module, which could be as simple as "a scrolling list" or even in-page widgets like a type of contact list entry. Any variations of the list fundamentals are covered in that spec point and don't need to be addressed when you talk about the address book. Most everything else is just data; the title of the page, what goes in each element. And soon you can define an entire chunk of the interface with a single drawing in a flow chart. (Oh, and note the little gray reference labels below the re-usable module above. Even that has components it refers to. Nest reusability for even greater efficiency of documentation and to encourage code reuse.)

So, I did. The flow chart above is as simplifed as it can be, but covers each and every path that can be taken. Really. And if you want more detail, that's what the bars at the top are for. They provide an easy way to find more information. Try it out. Look at that flow chart above. That very first box in the chart, "Dialer first entry" has a thick blue line which goes all the way up to a bar labeled "1280 Dialing a Voice Call." Scroll down in the document a few pages and you'll find a section (actually, a subsection) with the same title and number. And under that are a stack of requirements detailing how this function works.

Note that the 1280 bar links to the first three boxes. So, even though there are dozens of functions, they all collapse into these few states. The details are within these basic view states and don't need to be on the flow chart.

I did this exact thing for each section. Dozens of diagrams were reduced to about eight (I haven't counted lately, but it's not many) at the front of each major section, serving as a guide for those who like visuals, and as another way of viewing the data (a flow chart).

And, wrapping around to something I have always valued in my design documents, as a checkpoint that the design works. I think documentation should not just communicate the idea, but help the designer, whether it be UX or software or systems or database design. Making up these flow charts exposed a number of issues; impossible conditions or endless loops or undefined states. All of which we filled in.

And since it's all designed to be easy to understand (the client has essentially a more explicit version of this essay), anyone revising it in the future can use this, even if they don't know that's the intent. When they add a feature, they hopefully go back and add it to the flow chart and if it doesn't fit in there... well they ought to notice that and work it all out. A self-correcting system.

I can't ask a lot more of any of my work than that it do good, help someone, and last for a reasonable amount of time.

In case you want even more about this, there's a follow-on about working with requirements documentation and I am now presenting a session on basically this topic at the Design for Mobile 2010 conference>. Even if you don't want to see me, there's plenty more to learn about mobile design, technology, strategy, research and implementation. Still some space available, so join us in Chicago next month.

The Net Neutrality Debate Should Focus on the Actual Problem

2010-08-16T11:32:00.000-05:00

The latest news about net neutrality wheeling and dealing came up in the friday meetings here at Little Springs. While I have no idea what the ultimate goals of most of the big players are, I can certainly guess. And I think it's all going the wrong direction, and even those marching outside Google HQ are arguing the wrong point.

And what's bugging me is that even the fairly interesting articles and commentary about this issue pretty frequently miss key points. There are terms of art being used which are not being understood. So, we spent a little bit of time explaining what is basically going on, and how the telecom industry works. In the U.S. this is more about telecom law and regulation than business and way more than about end user needs, so it'll vary by country.

So, some of the key definitions to understand this. If you don't get the point, or want more information, search for these terms and read up on your own.

PSTN– Public Switched Telephone Network. Only wireline carriers, and originally circuit-switched carriers, are like this. AT&T, the Bell System, and now the split up RBOCs (Regional Bell Operating Companies) and their mostly stillborn CLECs (Competitive Local Exchange Carrier) competitors. Oh, and the various IXCs (Interexchange Carrier) also, both the LD-only AT&T and new long distance companies like Sprint.

MNO – Mobile Network Operator. Similar for satellite and others. These connect to the PSTN, but are separate from it. They are private networks, like the PBX of big companies. Though you think your desk phone or mobile phone is a phone, it's not. It's a private terminal on a private network that interconnects to the PSTN. Different rules apply. Generally, interconnection is to and through the PSTN. Meaning, if you make a call from your Verizon mobile to a T-mobile phone, the call goes through the PSTN, even though it doesn't terminate there. Generally.

Common Carrier – A legal term, that applies to any generally available (public) service for transporting goods, people or information. An airline is a common carrier, as is UPS (and Disney World, actually). The RBOCs, CLECs and IXCs are common carriers. Your MNO is not a common carrier, nor is your ISP, and they have all fought a lot to avoid that labelling. To be a common carrier means you have to provide access to everyone (unless they are axe murderers) at non-discrininatory price points, and so on.

Quality of Service – Almost always just referred to as QoS, so I will also. Wireline telecom services provide guaranteed "quality" of service to certain users. The fire department is a good example. Even when there's a disaster, and the network is swamped, they can pick up the phone in the fire station, and get a dial tone, and call anyone they want. Even if that involves kicking someone else off their call, or interrupting an ongoing call for who they are calling. That is a very high QoS level. There are others in between. Most are for public safety and so on. Certain private networks implement many levels, some of which you pay for. Mobile generally doesn't have QoS (which also makes them useless to public safety in disasters, and is why they are all buying new digital radio systems) but it is built into many of the specs, so they could if they wanted to. This one really gets lost in the shuffle. I have seen blogs referring to "quality of services" when they clearly are discussing the Quality of Service aspects of telecom. Be careful when writing, or reading.

My gut reaction has been on the side of the information-should-be-free people. It's a good argument. But then I started talking out loud about stuff like interoperability, and addressed what QoS meant, and realized I really want something much, much bigger.

As I see it, the corporate goals are all about chasing next quarter profit, and getting record growth. I am not sure what a real revenue model would be for the new telecoms, but there needs to be something more sustainable (think along the lines of SMS getting tiny interconnect fees...forever). The FCC is better than most agencies as far as thinking systematically, but the government in general is doing something similar, and trying to solve what is perceived as today's crisis.

And I see a lot of those general arguments coming from the network operator sides: Mobile is different because it's bigger. Because it's constrained in bandwith, etc. I have one inappropriate word for that. A whole field of math to control traffic arose from setting up wireline networks. And lots of the rules (like QoS) are based on congestion issues. Nothing should be legislated based on the state of a technology today. Even 10 years from now I cannot imagine what the networks and usage patterns will be. Without a real solution, we'll be debating this every five years for the rest of time.

What I want would not be a pile of new legislation or rule-making. It would be simple. A method is proscribed for the FCC (probably) to determine that a type of interconnected telecommunications device is a common carrier. They then have to abide by the Telecommunications Act of 1996. Part 202 (a) states:

It shall be unlawful for any common carrier to make any unjust or unreasonable discrimination in charges, practices, classifications, regulations, facilities, or services for or in connection with like communication service, directly or indirectly, by any means or device, or to make or give any undue or unreasonable preference or advantage to any particular person, class of persons, or locality, or to subject any particular person, class of persons, or locality to any undue or unreasonable prejudice or disadvantage.

That's easy. Apply those rules evenly to everyone, and every type of communications, voice or data. Old timey dialup internet service on the PSTN had to be provided totally equally to everyone, and at similar prices. There were court cases. This was solid. And I fail to see why taking the electricity out of the wires, or using packet switching changes anything.

There may need to be some other changes to telecom law, to allow interconnects, compensation and so on (e.g. probably also the long distance provisions) to be applied to these new, non-wireline common carriers. But that doesn't worry me.

And it very much proves my point. In 1996 this law was passed to actually try to rationalize the wireline telephone industry which changed entirely in 1983 with the AT&T breakup. By 1996, there were enough mobile phones that phone booths were already disappearing. Now, not 16 years from now, is the time to change the U.S. telephone industry to embrace mobile.

The 1996 law was the first totally encompassing telecom law in the US since the original Communcations Act of 1934. Now, not in 2058 – after another 62 years have passed, is the time to change the U.S. telephone industry to embrace all these new communications methods.

Not just for consumer protection, but to make mobile, and all types of data services a fully qualified player in the communications world.

My Mobile Mantra: People First

2010-08-09T11:34:00.000-05:00

Mobile is not iPhone or iPad or N8. It's not Bada or Symbian or WebOS. Mobile is not Opera Mini, or Skyfire or Netfront. Mobile is not sliders or clamshells, QWERTY or 12-key. Mobile is not touch, or multi-touch. Mobile is not Foursquare, or Facebook, or MySpace. Mobile is not Twitter. Mobile is not MMS, or BBM, or SMS. Mobile is not resolution or GPS, or front-facing-cameras. Mobile is not CDMA or GMRS, WiMax or LTE.

Mobile is not successful due to amazing marketing, or great pricing, or because it's fashionable. It's not even successful because it offers new capabilities to everyone, although it also does that.

Mobile is an unspeakable success because it lets people be people. As obvious as it seems, we're no longer tethered to wireline phones, or movie theaters and TVs, or pinball arcades, or typewriters, photocopiers and desktop computers.

Mobile works because it lets people work the way they want to, and the way they always have. Mobile lets people be mobile, and read what they want, and watch what they want, and take photos of their vacation, and share their thoughts with their friends, their family or no one in particular.

Designing for mobile – and I say now designing for anything – is an exercise in designing for people. Sure, it's always been a great idea to consider users; but not just how they interact with a machine, or a website. If you step back and look at the way people really work, and want to work (or play, or share, or create...) then you are on the right track.

Whether the product that comes out of this is (or works on) a large chunk of iron, a wheeled vehicle, a desktop computer, a website or a mobile handset – or many of the above all at once, is of no particular significance. When you consider people, and their context, and address it right, that is what I consider designing with a mobile mindset.

Certainly do not get locked in and decide before anything else to design a desktop website, but also don't design for mobile first. Design for people first.

I think this will be my position at 5pm on 21 September when I talk about "Why and when to design for mobile first" with Scott Jenson, Barbara Ballard, Luke Wroblewski, and Alan Tifford at Design for Mobile 2010. Come see us and join in.

My Mobile Mantra: People First

2010-08-09T11:14:00.000-05:00

Mobile is not successful due to amazing marketing, or great pricing, or because it's fashionable. It's not even successful because it offers new capabilities to everyone, although it also does that.

Certainly do not get locked in and decide before anything else to design a desktop website, but also don't design for mobile first. Design for people first.