April « 2010 « Little Springs Design. 2001

Archive for April, 2010

introduction to location based services (and not just GPS)

Monday, April 26th, 2010

Entirely aside from my tactical land navigation and GPS training efforts, I have been working on or with location based services for mobiles since around 1999. I have this pretty well baked into my brain, but not everyone does, and so it's a topic I had to expound about with some of the new guys lately.

Being complex enough (and changing over time) that I actually messed up part of it off the top of my head the other day, it's certainly too much for everyone to just listen to, so I decided it was a good thing to sit and write in some detail. I'll also be posting it to the D4M mobile design wiki when done, and will presumably remember to update it periodically.

Edit: This has been modified and posted to the wiki at this location. So, if you disagree (for example, because you are reading this years later) go there and edit the page to make it more accurate and up to date.

The most important thing is to never, ever, ever conflate "GPS" with "location." After that, it's best to dive straight into the individual technologies. I like to break down location services by (approximately) least to most precise:

Cell

Mobile telephony is based on communications and handoff between cells, each of which is (generally) controlled by a single tower with multiple antennas. The tower location is well-known, and its ID is attached to the CDR, so it can be detected.

This is a fallback, when other things are not available. Better technologies are generally not available when roaming, and the data is not or cannot (technology or politics) shared at more precision with your home network or because you are from another operator.

Precision will vary widely by the size of the cell, and there is no (good, universally-accepted) method to determine and communicate precision and accuracy. My rule of thumb – and something similar is generally used by devices – is a circle 3000 yds (m) across.

Sector

Recall that each tower has multiple antennas. Those three (or four, rarely anything else, depends on the carrier) antennas point different directions. Each of those is an independent mobile radio sector; just like signals are handed off between cells, they are handed off between sectors, and the data is generally known to the handset and can sometimes be shared with services or providers. However, since the direction the sector faces is really only known to the company that installed it, and the network operator, they are the only ones that can use the data well.

Precision will vary widely by the size of the cell, and by the antennas used, the number on the cell, the down-angle, and so on. There are some semi-useful ways of determining precision and accuracy for a single read, but they are not univerally implemented and there is no way to send the data to the information providers (e.g. the map program). My rule of thumb – and something similar is generally used by devices – is a circle 1200 yds (m) across, co-located with the radio centroid of the sector. Yes, sectors are not circles, but it's also hard to communicate shape and orientation, so this works.

Triangulation

Generally, triangulation is the practice of determining the location of a point by measuring the angle and/or distance from several known locations. More points give more precision. It can get more complex when you try to find points in 3D space, but all mobile triangulation systems I have known assume the earth is locally perfectly flat, and simply find the location on the geoid. Methods of triangulating get really complex and vary by network type and equipment available; multilateration and signal interpolation are some of those. The math can get pretty harrowing.

Precision varies mostly by the number of sectors being used, the distance between them and so on. Though I cannot recall what it is, I believe there is a method of communicating to services employing it an approximation of the precision available. In any remotely built-up area, where it most often has enough sectors to work, a circle 50 yds (m) across is typical. I have seen 12 yd precision, with good accuracy.

GPS Telemetry

The Global Positioning System consists of a ground based control system, a series of satellites and any number of anonymous receivers. So, reading that alone dismisses many misconceptions; its one-way, it's a system, and the signal is from satellites and has nothing to do with mobile networks.

Telemetry means data sent from a remote (usually mobile) site like a rocket, back to base. Here, it means the device figures out where it is by listening to the satellites, then tells the network or website or whatever where it is.

Ignoring SA GPS can give precision to... well, fractions of an inch at least. But those are big, car-expensive devices used for special surveying and so on. Portable, hand-held receivers like those in mobile handsets can generally be assumed to give precision of 20-50 ft.

There are other systems, like Galileo, GLONASS, and COMPASS but none of these are really fully-active, and there are few or no receivers in mobiles as yet. In theory, eventually, using multiple unrelated systems will give better accuracy yet, and give better coverage when in touchy situations like in dense cities.

WAAS

GPS uses radios, and the atmosphere and earth are imperfect and mess with them. WAAS is a satellite based augmentation system based in North America (others exist in the rest of the world, but are less well-established) that sends additional signals via another set of satellites to allow GPS receivers to adjust for those inaccuracies. I know of no mobile phones that have a WAAS receiver, but it's there.

AGPS

Assisted GPS requires the use of mobile networks, so only works when in data communication range. The cell tower has its own GPS (which many use anyway to get precise time codes), probably with a WAAS receiver. This provides a bit more precision, assures it of more accuracy, but mostly helps speed up cold or warm starts. Briefly, for a GPS to work, the receiver has to download data about all the satellites before it can calculate the position. AGPS caches this info for the phone, and sends over just the relevant bits, cutting minutes to a second or two. Which helps.

This is a reason you may not see WAAS, and might see some benefits from other GNSS (say, GLONASS) before they bother getting receivers into the handsets.

These generally give precision, even in dense areas and on the move of 10 ft or better. I have seen 2 ft indicated precision and have no reason to doubt it.

AGPS is not generally selectable as a separate service; when the user chooses to turn on or off "GPS," and has a network connection (and an AGPS compliant phone, etc.) they get the advantages of AGPS.

WLANs & PANs

Local networks like WiFi and Bluetooth are not exactly more precise, but I stuck them at the bottom of this list because they are local, and can add another layer of location, so could increase precision. They can also be used instead of other technologies when there is no GPS signal, or a bad mobile signal so triangulation cannot be used.

Both of these currently use the "cell" (or network identifier) and triangulation methods described above. There are no sectors, and no universally-adopted AGPS system that I am aware of. Naturally, a handset getting good GPS data can send that telemetry to anyone over any network, including WiFi, but that's not what we're talking about here.

They are both relatively more rare, and often are supported by third party software or individual services, and are not universally implemented on the handset. I have no reliable numbers on the real-world precision, but tests of WiFi triangulation alone have gone down to inches. On the other hand, poor network identification has led to placing users on the wrong continent. There's room to improve here.

Ask

People often know where they are. If you cannot get any location, or there's a reason they might want to over-ride it (even as simple as the data is bad) let them enter a location. If you do this, allow lots of methods. Only accepting ZIP or postal code is not useful for e.g. travellers, who do not generally know the ZIP where they are.

All the above is pretty well known by network engineers, and chip-makers and various low-level handset software guys. But it is often missed a bit by various software implementations (and certainly by marketing). All too often GPS is navigation, such that turning it off kills all location services.

Happily, Android seems pretty good about this, and just gives poorer precision when you turn the GPS off, but it does allow location services to work.

Which brings up a good point. Precision vs. accuracy is often also messed up, whether its confusing the two terms or just not communicating well. A quick primer: precision is the number of decimal places you measure something to; accuracy is how correct it is. The less accurate you think your measurement is, the less precisely you should report it.

This image sums up what should be happening, but for more ranting about this start with this older post on GPS.

Following straight on from precision and accuracy is appropriateness of information. I believe that the biggest problem with turn-by-turn directions is that they assume perfect location precision, and say "you have arrived" instead of "it's the big, white building on the north side of the street," because maybe it's 30 yards behind you, or 50 in front.

The other problem with driving directions is bad data. If your map might be wrong, or imprecise or inaccurate (and they all might be) then think about this when planning the interaction. Don't assume your data is perfect, and give contextually-helpful information. Let users note problems, and do something with the problem reports.

Speaking of data (though it rambles, this thing just writes itself), where does that map data come from? Well, it depends. On my handheld GPS unit, most in-car units and some handsets now, it's in the device. But too many people (including designers) are so used to mobile phone maps they think GPS is AGPS, and only works when you can get network location, network maps, etc. Wrong. And a bad assumption. Why don't people want to know where they are when coverage is spotty or non-existent? Well, if your service or app has that use case, carry through on it.

And one last hint is to not confuse location with navigation. Turn-by-turn directions is not the end-all be-all of LBS. I don't know what is, and neither do you. Location is an enabling technology (or set of them, I guess) and if there even is a killer app, we haven't seen it yet. More likely, it's going to be like simply being on the internet, and will become so baked into our mobile experiences that it will become invisible to everyday people.

While I am sure the commoditization of location service annoys operators and handset makers, it's going to be a a good thing for the end user.

So, to wrap up with a simple guide to design and development of location services, remember that:

Every phone is location enabled. GPS or not, working or not, there's some location available. And if you are giving something like a weather report or local news, a few thousand yards is practically pinpoint precision.
All the available location technologies must be addressed when designing your application or service. Don't shut off the service because the GPS is off.
Precision and accuracy must be understood by designers, and correctly exploited by the product. When the GPS is off, or doing badly, show that circle so it's clear that we don't know /exactly/ where you are. Say "turn right in about 1/4 mile" and so on.
If you work for a carrier, exploiting the network like this should be a snap. If not, your devices or software may or may not be able to be talk to the phone enough, and you might need to negotiate with the carrier or find a third party provider.
Consider what to store locally. Does the handset really need to be on the network, or should you give some functionality when the connection is bad or unavailable?
Though I didn't mention it above, look useful without acting creepy. And don't just follow the letter of the law. Be careful with your user's data, share only what is needed, and store only what you really have to. Often, these last two are answered as "nothing." If that is the decision, make sure it's implemented as such, and no one gets lazy with the development or doesn't get the memo.

Posted in Context, Design, Devices, Location (LBS), Theory | No Comments »

apps switch a lot, devices hardly at all

Thursday, April 22nd, 2010

Looking up some obscure bit of software setup, I googled around and found it in a blog post by the developer. I’ll just quote the beginning here:

As I’ve written previously, when OS X took over long-standing Photoshop shortcuts, it created a tricky situation: break Photoshop users’ habits/flow by changing PS to match the OS, or deviate from the new OS conventions?

The title of this post is one of those key tenets we operate on at Little Springs. We apply it to mobiles, but it’s really true everywhere. The vast majority of users, in the vast majority of situations, use a single device for all their work in a particular context. They switch applications a lot, but hardly ever change devices.

Sure, they switch from phone to desktop computer, but that’s such a change most people reset their brains pretty well to the marked differences. And some people in various regions swap SIMs all the time, and have night and weekend phones that are different from daytime phones. Even those, however, switch daily. They switch apps dozens of times an hour on each of those devices.

What this means is that your application should almost always use the OS-default behaviors. For mobiles, that’s putting softkeys in the correct locations (don’t flip them), making menus look like the device menus, supporting all gestures in the expected manner, and so on. This falls naturally into our avoidance of pixel perfect design. Use rules, and define a lot of the behavior as inherited from the device, instead of being always the same (looking at you now, Opera Mini for touch devices) or only being on one device, because of the “difficulty” of designing for multiple platforms.

Okay, I am sure the Adobe guys will argue that their tool is so heavily used that it’s practically a software workstation and therefore the tool should follow it’s own conventions. I’ve spent time in production environments, using Photoshop 10 hours a day and I say that those users exist, but are miniscule population, they still use their computers for other tasks (email, time tracking, file sharing systems, other Adobe apps with /different/ UI conventions), and anyway are going to invest the time in setup and training. Offer them a simple Photoshop/OS standards option if they want. The typical user should, by default with no extra work, get the OS-level defaults.

And a few others will argue this stifles creativity. I say “try harder.” There’s a LOT more interface and interaction room left around the edges to work in. If you just have to have something unique, pick an un-used command, gesture or corner of the screen and have fun with it.

I have installed fully eight browsers on my Android device, and almost all of them are pretty Android-ish, while also being pretty different. Often, weirdly so, with gestures and tilting and so on. But the core is something I am used to, which gives me some comfort zone to learn the application, and a point of departure for the new neat parts. And when it’s not (e.g. the Menu key doesn’t do anything) I get pretty lost.

To me, there is no tricky situation, because there is no choice: design for the OS conventions, even if they change, and break your existing design.

Posted in Design, Design Tips, Gestures, Mobile applications, Strategy, Theory, UI Design Patterns | 1 Comment »

brainstorming is for suckers

Monday, April 19th, 2010

Many times in my career, and several times lately, I have killed brainstorming sessions. I sort of never trusted them – even since grade school, when we indeed were introduced to the concept. But the more I consider how design processes work, the more I am sure there’s some key problems with it.

Let’s start with a definition. This is an abbreviated one I just got sent (this whole post is the result of having to make a presentation about integrating Usability and UX into a software development process):

All ideas captured, none are stupid. Even stupid ideas can have useful components, and stupid ideas can trigger other ideas. And, must capture ideas.

Key to my objection is understanding that I don’t just skip the step. I just make it something else. Something ordered and with more guaranteed useful output.

So, point by point, what I like or hate, and how I solve this otherwise.

All ideas captured,... – Of course. Key to the process. There better be a scribe, or an organizer. I prefer the Post-It method of capturing ideas, to make sure everyone participates. Those emphasized bits are key component that most folks forget. You need a moderator, preferably one who doesn’t spend too much time throwing out ideas. Even when leading a design project, I’ll often do this, so I can understand the conversation and make sure it’s on course and re-write good concepts to be understandable, but I add none of my own exactly. And, everyone has to participate. Force them somehow. Who knows what ideas they have unless you get them on paper.

...none are stupid. – Actually, there are stupid ideas. I think we all learned that by the time we got out of grade school again. And the very first brainstorm I was in back in like 3rd grade had plenty of ideas rejected out of hand. I have been to many in the corporate world where those “challenged” ideas are written down to remain letter-of-the-law compliant, but are off to the side. And this is by professionals hired in from outside. We should admit there are bad ideas, and that people judge, and not try to live in such an idealized version of the world.

Even stupid ideas can have useful components,... – Well, sort of. As long as they are in the correct domain. And are not illegal or immoral. And obey the laws of physics. Seriously. I’ve seen all these. Like the time we were brainstorming web self-service concepts, and had to sit and listen to ideas about RFID, where your car keys would fly to you… somehow. Using radio, I guess. This is irrelevant. So would even be a new product idea for the company that is not web self service. Define the domain early on, and get some basic information shared with everyone up front. A way to do this is to introduce everyone involved, and find out what their job is on the product, and what they think the product is (without discussion, else the session will break down immediately).

...and stupid ideas can trigger other ideas. – Sure, again, assuming the ideas are remotely in the ballpark of useful all ideas are good. Again best with the post-it concept, there’s time left at the end of the session to group and re-organize the concepts. From this, concept clusters should naturally be created, and the group can then have a nice discussion (or sometimes a heated discussion) of which grouping most reflects the core concept for the product, or the core philosophy of the company, or even is just achievable in the timeframe. And don’t throw away the others; I’ve been in meetings like this where each of those clusters became a full project, that launched eventually. Three to five of them very often. That’s pretty efficient idea gathering, even with all my terrible “there are bad ideas” constraints.

Also, ideas do beget other ideas. So if you let the discussion head out to flying saucer land, you might never get anything out of the meeting. Done that also. Four hours and hundreds of notes, that do us no good at all. And the time spent in the meeting is tiring, so people will wear out; you only get them for a few hours, and they won’t want to come back for another. The first run has to be relevant, and efficient and productive.

And, must capture ideas. – Well, this is just repeating the first point. But I’ll use it anyway. What happens after a brainstorming session? To business and marketing guys: Nothing. I’ve asked, and they have no idea. To designers and developers: (again, I’ve asked, this isn’t just me) throw away everything, do what we wanted to do anyway, and just frame it in the wording of some of those brainstormed ideas, so we can get buy in.

That’s not helpful at all.

But gathering ideas is. Working through them to cluster to solid, final ideas is good. Getting everyone on the team to contribute ideas is good, and making them all discuss the concepts and agree on a final direction (or directions) is great.

For some more tactics on this sort of information gathering, see my book on design process.

Posted in Design | No Comments »

sharing documents with the iPad shouldn’t be this hard

Monday, April 19th, 2010

Apple, with it's portable and mobile products, has always been a desktop-synching sort of a company. For their first foray – with music on the iPods, this worked very well and a good standard was set. It even seems to have served them well into the more complicated model of the iPhone and selling applications.

With the iPad, sharing of all sorts of documents (and other application data) with the desktop computer is becoming key to the use of the device. Apple has patched iTunes to allow for that sharing, but the way they've done this represents the equivalent of "the visible screw" that Steve Jobs is reputed to have fired an unfortunate industrial designer for.

It is a glaring exception to the fundamental metaphors around which the iTunes / Apple mobile device model has been built. That metaphor bundles data with the application meant to handle that data, and is designed to simplify the management of small devices designed for people who consume more information than they create.

Because I failed to discover how to do it on my own, and had to search to find out, I should go over the steps here:

Connect the iPad, and when iTunes comes up, click on the device.
This shows the summary data for the device, current software version, etc. There are tabs across the top.
Click on the App tab. This brings up an interface to allow management of which apps are synced on the device currently connected.
Scroll down below the fold to see applications which are registered as capable of file sharing.
Upon selecting an application from the list of sharing capable apps, an input window becomes available.

This metaphor makes handling the intersection of Apple's mobile device model and the standard file centric model found on desktops problematic. And Apple simply failed to provide a solution consistent with iTunes past behavior.

What I believe should have happened is exactly what iTunes attempts to do with music. iTunes actively searches the host computer for playable content, and it should actively search for sharable data. It should then categorize the data by the mobile device application designed to use it, and allow the user to actively exclude or include, set up parameters for future inclusion, and of course override automatic decisions.

Requiring iTunes to manage shared application data doesn't please me, nor does it fit how I hoped to use the iPad. That said, if iTunes is going to be required, it should handle document and other application files in the same way it handles things like photographs and music.

Posted in Design | 2 Comments »

history is context

Friday, April 16th, 2010

Despite historically being a personal computer maker, Apple is clearly moving to be some sort of “digital lifestyle” company. Forget the cute name change (dropping “Computer”) and other direct comments about this. They are all self-serving and much more can be learned from examining behaviors.

A key “behavior” of a company is the products it releases. Let’s look at the highlights of these “non-computer” products:

A (mostly) ARM based platform, centered around pen/touch interaction with specific appeal to the PDA, mobile communications, networking and graphics. Add ons and applications are supported with a custom SDK, allowed them to be written relatively easily in an OO language.

Devices that support the platform include simple tablet-like PDA/entertainment devices, smartphones, ruggedized devices for verticals and larger devices with integrated keyboards.

Any of those specs throw you? A keyboard on the larger device perhaps? That’s because this is not iTouch/iPhone/iPad, but the Newton platform, and refers to the MessagePads, Seahorse, Tarpon, Schlumberger Health Terminal and eMate among the many devices made to support the platform.

And this all started in the 1980s.

I periodically rant in Twitter about the stupidity of tech pundits. Such that I often don’t read, watch or listen that much, as they infuriate me. This is exactly why. No one [well-read, that I know of] has talked about the above history in any but the slightest detail basically since it was happening.

But a straight line can be drawn from Apple’s computer platforms, though the Newtons to the iPhone platforms of right now. And if you act all pundity and think about what they did, that’s called analysis. You can come up with some useful intelligence from it.

My key takeaway from Apple is actually a public statement, the Digital Hub concept. Delivered way back in 2001, and which I think they are clearly still working from.

You get one desktop computer, you attach PDA-type devices, entertainment devices and portable devices to it. You attach to the internet. And you get to continue being productive (work) as well as being entertained. Remember, this was the Information Superhighway era and there were Info Appliances (all to often, actual appliances like refrigerators with computers embedded) proposed and sold that would do specific tasks and network in their own way. It was not clear that the general purpose computer, the PC had a future outside of offices and servers. In fact I am a failed futurist – I thought the PC was dead and we’d all have info appliances for specialized tasks, and iPad like things and smart refrigerators. Instead, we have a faster, shinier ten-years-ago sort of computer world.

Anyway, back to Apple. They are still working on this whole philosophy and it’s easily visible in their mobile platform. Who else would require tethering to a computer to get software updates? Who else would assume (not just require, but assume) that the center of your media library is the computer, not the portable device. Etc. The core information architecture follows precisely from this assumption.

And – without getting too deep into it – their strategy for OS and application control has been unchanged since at least the Mac Clone business was killed in 1997. This extended straight to the portable platforms (nothing at all on the iPods, and strict control only when the market clamored for, and hacked into, ANY openness on the iPhone platform). Even before this, the little Pippin software was all routed through Apple. It even informs Apple’s own apps, like the iWorks suite; pretty, but built from a singular point of view. Trying to move outside the intended scope is difficult or impossible.

It’s not a shock. It’s not a regrettable surprise. And no matter how much I like to argue they could add something like an “untrusted app” feature, or better type controls, or a color picker that isn’t insulting to colors, without sullying their brand, it’s really not likely. Because this is now baked into the DNA of the company.

We spend a lot of time developing this knowledge at Little Springs. We have a wall of old phones and spend a lot of time showing what even 2-3 year old devices worked like to the sometimes annoyingly young staff members and interns. Some of us have been in mobile specifically for over a decade, and that’s just forever. Just myself, I’ve been on projects for the first musicphone “ever” and the first camera phones in the US, and built an app store something like 10 years ago.

All of this we try to keep in mind, and pass on to the rest of the company, and when we get our act together, mention in the blogging and on the wiki so everyone in the world can share in it. The next time you are trying to figure out something, ask one of the old timers around your office (or, email us I guess) to cast their mind back, and see what you can learn from the not-really-very-old history of technology.

And it doesn’t just make you feel good. Knowing what has been done in the past helps you exploit the concepts, or avoid those mistakes if they are fundamental (e.g. not just that the technology wasn’t advanced enough yet). Knowing what the competition is doing lets you predict their next move, and understand their current moves. For example, I’d say you are totally safe assuming Apple will continue to place the Mac at the core of their strategy, and protect it at significant cost. If you can exploit that, you have a leg up; you can design and market for the appropriate niche.

This works for any product – I just used Apple as a well-gossiped case. What are you competing with, or wondering about, or building that you think is all new? Are you sure it’s totally fresh and new? Are you sure you understand the competition as well as you can?

Posted in Business, Design, Strategy, Theory | No Comments »

meeting expectations, exceeding expectations

Tuesday, April 13th, 2010

Both at home and at the office, I have bought, obtained or gotten the use of a number of products lately that have made me think about why they are interesting (or not) to me.

Sometimes it's just fun, sometimes it's a great deal, and sometimes it's exactly what the rote sales and marketing guys say: features. Various of the new HD and Blue-Ray devices are like that; only exciting for feature count, but some balance that out with awful UI or reliability.

The good devices – by which I mean the ones I am still overjoyed to use long after initial acquisition – seem to share two key attributes:

Meet expectations – Based on most client briefs ("make something innovative and differentiable") this seems at first like almost a bad thing. But you have to give users a point of departure. They need to know roughly how to use the product, and what they can expect it to do before they can be thrilled by new features or a new experience overall. This doesn't mean everything must be anchored in the past; almost any level setting will work for this. Meeting expectations is about getting the product into customers' hands, and making sure that first experience is productive.
Exceed expectations – Simply adding to the specifications or adding a few bullets under the features list does not automatically exceed expectations. Once expectations are set, a good overall (and integrated) experience is a key way to exceed expectations. That experience doesn't have to be delightful and fun; just being productive in an unexpected manner is enough to make your otherwise-standard product stand out in the market. Exceeding expectations is about lifecycle. It keep your customers using the product, buying the next generation (or add-ons, or paying MRCs) and telling everyone else about it.

Those that do not flip my switch fail in one way or the other.

Instead of worrying over niggling details of mobile phones, let me start instead by talking about my new lawnmower. As a homeowner, I have mowed my lawn (or, admittedly, paid someone to do it) for some years. Mowed my parents' house for years, and even worked a lawn crew briefly in high school. I have a solid understanding of lawn mowing. Understanding the target market background is key to their expectations, and as the only consumer surveyed here, that's my background.

Gas mower on the left, battery on the right

I got (cheap, yes) a battery powered mower. It's the black and dark-green one on the right in the above photo. It meets expectations in that:

Mower shaped – While I could imagine odd solutions to this that might work better (where's Dyson with a mower?) I had no learning curve. It's a lawnmower.
Same controls – More than just being generally a mower, it has a safety handle thingy, which is at the end of a control arm. Essentially, I can just take off and mow without instruction.
Simple parts – Easy to fix with simple tools if, say, a wheel falls off. And the battery is replaceable by anyone who carries sealed lead-acid batteries. Nothing is totally unique to the mower or requires special parts or service.
No gas – Well, yeah. Key attribute is no gas, no gas tank, no purchases of gas, no mess or smell which annoys my wife to no end, etc.
Quieter – Not dead quiet, but I had seen some, and it's more in the vacuum cleaner range than the mower. I had taken to wearing electronic hearing protection attached to a radio and my phone when mowing, so I could tell what was going on in the house and take calls. And, I have a strange hearing loss so want to protect it. And anyway, I can mow (e.g.) Sunday morning without annoying anyone too much.

But it exceeds expectations in, well, unexpected ways.

Even quieter than I expected – Note that it's extremely okay for an expected feature to exceed the expectation.
No vibration – Such that without the noise, you cannot tell it's running. This, as it turns out, was a key problem with the fatigue of gas mowers. This thing is a snap to work for long periods.
Safety – Before working on a gas mower, you need to unplug the spark plug wire. Often this is hard to get to, and sometimes I've had it move back to resting on the plug. Which isn't really cut off. The battery mower I got has a simple, very sure (I looked at how it works) switch that cuts off all power when you pull the plug. I am totally confident it won't start and cut my hand off when working under the mower.
Speed of cut – The motor runs faster than a gas engine, so the cut speed it very high. Even with the blade dull (it hits rocks, etc.) it cuts fine, and it generally cuts finer, so clumps left on the surface don't kill my grass.
Weight – I expected it to weight a lot, since folks complain about batteries being heavy. But overall it is lighter than any gas mower I have used. Also adds to the ease of use, and it's replacing a self-propelled mower.
Starting – There is none. Like bill-payment is an inherently bad feature of any service with an MRC, it hadn't occurred to me that starting was a pain. It's totally removed now.
Cleaning, maintenance – Mostly removed as there's no air filter, etc. And there's no issue flipping it over, because it's light and gas doesn't leak out.

To make sure this blog post meets expectations, let's talk about the iPad. Disclaimer: I don't own one. I have played with a couple, have the office iTouch in my bag all the time, and certainly read up on it and all Apple product development plenty. Which is fine for at least the "meets expectations" round; that's the key part of selling the product to get it in consumer's hands.

As far as the rest of my level setting, I have pined for a good pen/touch tablet for around 25 years. Yes, they have been around at least that long. If I had the money in college, I would have bought a specific 386 tablet (but later saw it and would have been disappointed). I have a ruggedized touchscreen laptop, basically because it was cheap and tablets are much more expensive. More recently, I have worked on an eReader, and we specifically got pretty much all the other ones, so I've experienced the state of the art for lightweight consumption devices as well, and spent a lot of time thinking about what I want an ideal device to be.

Regardless, looking at the advertising (and other marketing), the iPad meets expectations in that:

It's a big iPhone – I know how it works. Everyone I know personally who has one has an iPhone and is rather an Apple aficionado (I'd say "fanboi" but that's apparently a pejorative).
It's a mass-marketed eBook reader – And I also know what those are. There has been plenty of advertising and even more writing about what eBooks will do to print some day.
It's colorful and responsive – Beating all ePaper devices, it's got a TFT screen of some sort, so is immediately responsive, helping with interactivity expectations. I don't have to learn a control set or patience while it reacts as most eBook readers make me.
It'll be popular enough – Maybe not with consumers, but certainly with developers and media companies trying the next big thing. It'll have content (whether media or actual apps for other purposes), and not all will be made by Apple.

For me, it exceeds expectations in the following ways:

orientation lock

For me, really, not a one. I won't outline what some of my needs would be a for a disruptive tablet device (and mostly they are outlined here). I don't really want an eBook reader, basic productivity stuff I do with my mobile phone, and way too many folks use the external keyboard, which looks pretty kludgy for something supposed to be amazingly portable.

Now, it does seem like it might encourage good media, so if I see more book/magazine projects I like, that could sway me. And it has some value as a browser, so I might get one some day after all. But not now.

The lesson here is not that I don't like the iPad. Or prefer batteries to gasoline. Or anything product-specific. It's that there is a tight relationship between product design and marketing of a product.

And even more importantly that usability/UX/design types need to be aware of the value of product design, sales and marketing to the success of your product. We all like to at least give lip service to taking business as well as user needs in mind, but really paying attention to this takes some work, and is foreign to a lot of designers. You have to be conscious of your process, and organize design around these goals.

Naturally, the end result has to meet those needs. But I still get lots of requests for something cutting-edge, fresh, edgy, unique, and that will differentiate the product in the market. Often, this happens at the expense of good design. An interface for a mobile phone that fails in as simple a way as reversing softkey positions is a serious failure. Users will make mistakes, become frustrated, and probably stop using your product. This is a "meet expectations" task.

Lots of neat products have failed because they didn't meet expectations. There was a spate of weird mobile phone form factors (e.g. the Moto V70, the original Nokia N-gage) that went nowhere, I feel partly because they departed too widely from the expectation of a phone.

Early musicphones failed because they were hard to use even compared to the junky pre-iPod MP3 players. To bang on Apple again, the Apple TV has languished because it does a very narrow set of things, but not many others (internet radio, PVR, even just play disks) that are expectations of media devices. For each of these, initial exploring, or even the post-purchase experience is not followed up with sufficient satisfaction.

Meeting expectations is not enough – you have to make the experience and the features exceed expectations to provide real satisfaction with the product. Success comes when you meet expectations then exceed them. The original PalmPilot created a mass PDA market by replacing the datebook, in a pocketable size, then exceeded expectations with a unique pen-input system, and an easy to learn interface. The original iPhone, even when a featurephone, created a market for itself by taking the then increasingly complex and boringly business-like PDA-phones and exceeding expectations with superior industrial design and a seamless and pleasurable interface.

Design holistically, both in the sense of the product and the total environment in which it will exist, to provide your product the best chance of survival.

Posted in Design, Design Tips, Theory | 1 Comment »

Little Springs Design. 2001 – 2010.