Flex ID

It’s surprising how often companies working on new products (or redesigning existing ones) don’t really know what they are trying to do or why. I’m a big advocate of talking to users in order to understand their needs, goals and behavior patterns as a starting point in the product design process, but before even getting to that, there are some questions you should be able to answer:

1. What problem/opportunity are you trying to address in the marketplace?
2. What’s the high-level product concept?
3. What do you want to avoid getting into? An example: Microsoft Word is a general purpose word processing tool; it’s not trying to be a good tool for magazine layout.
4. What sorts of people do you think are going to use it?
5. What’s the planned business model? (Straight purchase vs. subscription vs. license vs. ad supported, etc.)
6. Are the people making the buying decisions your end users?
7. What are the technology options and limitations?
8. Who are the competitors? Think about everything that’s addressing the current gap, not just direct competitors. For example, Napster’s competitors include the obvious (iTunes, other digital music services), but the bigger competitors are actually physical medial sales (CDs represent about 2/3 of music purchases in the US), and stealing (~95% of music downloads are illegal).
9. What’s the definition of success for the product, and how will that be measured?

This isn’t a comprehensive list, but it’s a good start. A deep understanding of all these things is great, but you also need to be able to articulate answers to these questions clearly and succinctly (or at least have reasonable hypotheses!). I’d say there’s some room for exception, say if you have the time and resources to explore experimental concepts that have a high likelihood of failure. That’s okay, but only if you know that you’re working on an experiment that might fail.

So, what’s the tenth question I missed?

More fun with Apple dialogs! This time we’ve got iPhone fun, with a variation on the app update dialog I wrote about the other day and an update to some terms and conditions. Can you guess which is good and which is bad?

Surprise! A human readable summary of the changes to the terms is always a nice surprise! Not that I actually read it any more carefully, but I almost did.

On the down side, I suffered another disappointment trying to upgrade the apps on my phone. It wasn’t as bad as on the computer – this time all the non-offending apps went about their business and continued to update even though I cancelled the dialog. Would it really be that hard to tell me which app is causing the problem?

Apple provided me with a pair of useless dialog boxes this evening when I tried to install their Java update. Here’s the first one…

And clicking OK revealed useless dialog box #2…

What am I supposed to do with this? No information and no path to resolution. Annoying! Didn’t they read my blog post from the other day? Just to recap:

• Provide meaningful information in dialog boxes. Why couldn’t it be installed? What sort of error occurred?
• If there’s a problem, give me an option to fix it.
• If there’s a problem that can’t be fixed by clicking a button, at least give me some helpful instructions.

I’ve ignored updating a bunch of the apps I’ve downloaded to my iPhone for some time. Most are free apps, and a few I’ve paid for. So, iTunes says I’m now up to 21 “free” updates to install, and I finally decided to download the updates. What did I get? This lovely dialog:

How many things can you count that are wrong?

1. The headline is crazy long.
2. The detailed description is exactly the same as the headline.
3. That’s terrible writing. “Can not.” Really? And “…you have not owned the major version…” Huh? Hire a writer.*
4. There are no choices offered – just “OK.” But it’s not okay; can’t you offer me a choice to resolve the problem?
5. Not only is the dialog not offering to fix the problem, it doesn’t even give me enough information to fix it myself. Which app is it that I can’t update?
6. Because there was one offending app, iTunes didn’t update any of them.

This is pure stupidity, and surprisingly common. Why is it that software usually stops everything at the first sign of trouble and refuses to proceed until each problem is resolved?

I had a similar problem with copying files from my Mac to my PC recently – whenever Windows had trouble copying an individual file, everything just stopped and I was presented with a non-specific error dialog. I forgot to get a screenshot, but the gist of it was: ‘There was a problem copying some file, but I’m not going to tell you which one, and I’m just going to stop copying the rest of the files. OK?’ I was trying to copy a large number of files, and so each time this happened, I had to manually compare the file lists to figure out where the problem was, and manually restart the copy (starting with the next file in the list). Totally obnoxious.

So, here’s my advice for how your software should handle batch operations:

• If you can quickly assess problems at the start, do that. But (a) report the specific problems, (b) provide options to fix the problems if you can or at least specific instructions on what to do if you can’t, and (c) provide an option to skip the problem areas/files and proceed with the rest of the operation.
• If you can only identify problems along the way: (a) skip the problems as they arise, (b) proceed with the rest of the operation, (c) present a message at the end with a specific list of all the problems you encountered, and preferably (d) provide options and/or specific instructions to fix the problems. Alternatively, report the problems as they crop up, but proceed with the rest of the operation in the background.

* OK Apple, some free advice on how to at least fix the writing in this dialog:

• Headline: There was a problem downloading one of the updates
• Details: You cannot download the update for [app name] because you haven’t purchased the most recent major version.
• Checkbox (checked by default): Don’t remind me again for this version of [app name]
• Buttons: Learn about the latest version; OK

I got this message when I recently ran the software update (while iTunes was running) to go from iTunes version 8.1 to 8.1.1.

Unfortunately, the developers weren’t smart enough* to figure out how to do an update gracefully (in the background, without quitting iTunes, and more importantly without forcing me to do the work). I know this is possible, because anything is possible with software (that, and the Firefox developers have figured it out). I’m sure it’s hard, and it would be boring work for the team, but is that really my problem? If there’s a choice to make between developers doing more work or users doing more work, I think the developers should have to do the work. A handful of developers would only have to do the work once, but instead they have passed the buck to tens (hundreds?) of millions of unsuspecting iTunes users.

The really galling thing about this dialog box is that the text clearly shows that they know exactly what needs to happen but they are unwilling to assist me. For some reason I have to read some annoying message, go quit iTunes on my own (and wait for it to close “completely” – how am I supposed to know what that means?), return to this dialog box to click Continue, wait for the update to finish, then relaunch iTunes. Just throwing the word “please” in there at the beginning doesn’t make it polite to order me around like this. Even if Apple can’t do a graceful update, couldn’t they at least do all that stuff when I click Continue?

* I don’t really think that their developers aren’t smart enough to figure this out, but someone at Apple is to blame. I imagine “graceful updating” is on a long backlog of features to implement, but it never bubbles up as a high priority because there’s a workaround.

If you use Adobe Fireworks for creating mockups (as I do), and have any need to create mockups for iPhone apps, you need this free Fireworks toolkit of iPhone UI elements from the folks who created Notespark.

It’s a fairly comprehensive set of UI elements, and everything is drawn as a vector object. I had started to create something like this for myself, but didn’t get very far — now I don’t need to finish the work.

There are a lot of things I hate about Bank of America’s online experience. After jumping through hoops to sign in to my account, rather than take me to my account, I got this ad.

I just don’t understand how they came up with the copy for this ad. Does having to deal with a physical card really make online banking “more convenient?”

Worst Assistant Ever

If you hire an assistant who is really talented at a couple of things, but every once in a while pokes you in the eye, how many times would you let that happen before firing them? What if they don’t poke you in the eye, but they do this kind of stuff:

• Interrogate you when you first meet
• Berate you every time you make a mistake
• Mumble incoherently when unsure of what you want
• List a bunch of skills on their resume for things they can only do badly
• Never bother to remember anything about you or any of your previous conversations
• “Accidentally” destroy your work when you push them too hard

In the face of that kind of behavior, would it matter that 80% of the time they do a good job? Unfortunately, most software products do some or all of the above (including the digital equivalent of giving you a good poke in the eye now and then). What’s worse is that many software companies knowingly create products that do these things and not only think it’s okay, but that it makes good business sense (because the ROI is too low to build products that don’t do these things).

The Little Stuff

Recently I’ve been thinking a lot about the importance of the “little stuff” in digital product design. Whether from a design, product management or engineering perspective we sometimes become focused on making sure that the primary scenarios are well served at the expense of the little things, and the overall experience suffers. This often comes out of a misapplication of the Pareto principle (the 80-20 rule) which leads people down a slippery slope that goes something like this:

• Since people spend 80% of their time using 20% of the product, it’s really important to nail that 20%.
• Since people only spend 20% of their time using that other 80% of the product, it’s okay if those parts of the product aren’t as good.

Once you take a stance that only 20% matters, it can become easy to rationalize away lazy design and implementation. More likely than not caring, this happens out of a need to prioritize time and effort under the pressure of deadlines and feature lists. In that environment, product teams will  focus on the important features and just cram in the rest.

Bad Rationalizations

There are all kinds of rationalizations for doing the wrong thing and building a sloppy, confusing, and/or painful UI:

• Very few people will use that feature anyway.
• It’s an edge case.
• It’s a one-time setup, so it’s not a big deal.
• That shouldn’t happen.
• Only people who really know what they are doing should use that.
• We don’t have a choice because (fill in the blank: the lawyers, our partner, the business people) said it has to be that way.
• We have to have the feature because our competitors have it.
• We can’t be late to market.
• We can fix it in the next version.

Certainly the primary paths through a product should be well thought out, and you don’t want to organize your product around edge cases, but that’s no good excuse for knowingly doing a bad job. The reality is that people’s overall experience of a product is a collection of their smaller experiences.

Windows Vista

Using Vista is a great example of this. There’s actually a lot that’s great about Vista, but it doesn’t matter, because it beats you down with the little stuff. Here’s just one example (and I’m definitely not the first to harp on this): in the name of security, I am bombarded with dialogs asking for my approval to do things that I just told the system I want it to do. Most of the time, these aren’t confirmation dialogs like “Are you sure you want to reformat your hard drive?” but more along the lines of “Was that really you that double-clicked that icon?” This is worse than the security theater practiced by the TSA at airports, which at least arguably has some deterrent effect. Instead, I start to become inured to the dialog boxes, stop reading them and now just blindly click “OK” when they pop up. This of course has the opposite of the intended effect, reducing the level of security because I stop paying attention. Annoying and ineffective by design!

Apple

By contrast, I think this whole topic has a lot to do with why Apple’s products are often lauded:

• They get the first part right of focusing on the 20% of stuff that’s important.
• They craft the smaller experiences as carefully as the big ones. Even though you only open the box and set up a product once, it’s a pleasure.
• Instead of including features that aren’t well done, they don’t include them at all.

Now, on that third point they often spin the intentional lack of certain features by claiming that people don’t want those features. Sometimes that’s just cover for “it’s not ready yet” (and hats off to them for being pretty disciplined about getting things right before releasing them to the public). More often, though, there actually is a desire for those features in the marketplace, but Apple knows that adding them, no matter how well done, will detract from the overall experience. They have done a good job of sorting out what people need to satisfy their goals rather than directly accepting feature requests from the user base as a work list of things to add to the product.

By the way, I don’t for a minute think Apple is perfect or gets it right all the time (iTunes? that program is kind of a mess), and will gladly dig into that in future posts.

Do It Right or Don’t Do It at All

How many ways can I say that I don’t think it’s okay to make products that you know are bad? What you don’t put in your product is at least as important as what you do put in. If 80% of your features aren’t important enough for you to pay attention to, don’t include them. If you are building your product to a feature list, being “feature complete” isn’t good enough. If you do include something, make sure it is well designed, well built and doesn’t poke your users in the eye.

On a sort of impulse while picking up some other supplies at Staples, I bought a paper shredder yesterday (the Staples M5 Mailmate Shredder, about $90). I’ve been collecting things to shred since my old shredder died about 4 years, so there was quite a backlog of shredding to do. I set out to shred it all last night and it was oddly satisfying.

Operation is simple. You turn it on and start feeding it paper. If you try to jam too much in, there are two buttons to help free up the blades (”FWD” and “REV”). This happened a couple of times over the course of an hour, but for the most part it lived up to its “12 sheet” rating.

Oh No!

Then, all of the sudden (and near the end of my pile), it got really stuck on a 10-page stack of pages, half-way shredded. The “REV” light was blinking angrily at me, and no amount of pressing the buttons or turning the thing off and on would allow me to free the pages. I struggled with it for a few minutes, then I started to rationalize. If I had bought this thing 4 years ago, it would have been chugging along all this time. As obnoxious as it is, electronics these days are built for obsolescence after a few years use, so 4 years isn’t a bad run. Or maybe it was my fault — if I had only been gentler with it, putting in just 8 sheets instead of 10, I would still be happily shredding.

But, no! It should still work. Maybe the “manual” would have some helpful info on clearing jams that I hadn’t considered. I put manual in quotes, because it really consists of one page of tiny print, translated into many languages. As it turns out, the manual did have some useful information. I know shredders have a tendency to overheat, and I thought I had been careful to pause every now and then to let it cool down, but I guess not careful enough. According to the manual, after 8 minutes of continuous use, it just stops working and the REV light blinks. Turn it off (and unplug it) for 80 minutes and it should magically start working again. Thankfully, this was true! I’m now back in operation, and don’t have another expensive, oversize paperweight in my life.

Fixing the Design

So what’s the problem? If this had happened sometime weeks, months, or years after buying the shredder, I surely would have thrown out (or maybe even shredded) the manual long ago, probably without reading it. It’s pretty likely that I wouldn’t think to wait 80 minutes and everything would be fine, and I’d assume it was broken for good.

I know that every extra component adds cost, but the big expense here was the sensor that they sprung for to detect the overheating problem. For another few cents they easily could have added one more LED next to a label that read “Too hot, wait” or “Overheat” or something similar. Actually, they didn’t need to add any cost, since there’s no good reason to have an LED behind the REV button for normal operation. So, even though the shredder does a good job of what it’s supposed to do (shred stuff), with just a little more attention to the interaction design they could vastly improve the overall experience of using the product.

One More Thing

The manual is really worth the read. I also learned that despite having a picture of some guy happily shredding his unopened junk mail on the product box, you shouldn’t shred envelopes, because the sticky material can hurt the shredder. Beware of the marketing department!

When I recently updated this site and decided to start keeping a blog, I installed WordPress to run it. WordPress is an is an amazing tool in its power and flexibility, but it falls somewhat into the same trap as a lot of software in that it works really well for beginners and experts, but those of us somewhere in the middle are kind of left in the lurch. It’s not quite as bad about ignoring intermediate users as a lot of software, but there’s still a gap.

The Short Story

Given the choice between taking someone else’s theme and just applying it to my site or developing one from scratch, I decided to do the later. I got in a little over my head, learned more PHP than I wanted to spend time learning, but in the end I’m generally happy with the result. So, what you’re looking at isn’t just an off-the-shelf WordPress theme with a custom header image, but something I built myself.

Mind The Gap

There are a couple of theme frameworks out there that are trying to serve people like me — they abstract a lot of the options that you might want to customize about WordPress in a way that’s more friendly for people without coding skills. The two frameworks that I looked at (and worked with for a while) are K2 and Hybrid. They are both powerful and have a lot of things going for them. They are built on the premise of providing a much more robust base theme than the defaults that come with WordPress, while also providing a way for you to customize further by developing a “child” theme. The child theme inherits everything the framework does unless you override it.

Unfortunately, they suffer from being so robust and comprehensive that if you want to step outside their expectation of things you should be able to customize easily, it’s overwhelming. Not only do you have to learn how WordPress works, you have to learn how the framework works. In (briefly) working with them, I was constantly encountering problems where (a) I didn’t really know the consequences of my actions (was I breaking dependencies that I didn’t know about?) and (b) when I understood what I needed to do to achieve a certain goal, there seemed like a lot of extra work to make it happen. I kept finding that to do what I wanted I would need to modify the framework just a little bit here and a little bit there to get what I wanted. That kind of defeats the purpose of using a framework with a child theme, so I ventured out on my own. (I don’t really mean to disparage these in any way, because they are great, definitely worth checking out, and I probably wouldn’t have been able to develop my own theme so quickly had I not studied these themes).

What I Was After, What I Got

Although my goal isn’t really to release a theme to the public, I created it with the idea in mind that it be easily customized by someone else. I figured that if I did that, it would make my own life easier if I want to change it later. For me that meant:

• Keeping it lightweight. The more places there are to look to have to change things to your liking, the more daunting it is (and the more likely you’ll miss something). Instead of the hundreds of files that make up K2 and Hybrid, there are 9 files in my theme (not including images). If I want to change something or if something is broken, there aren’t a lot of places to check. Their frameworks are about 1.3 MB and 1.7 MB (including images). My theme is about 170 KB.
• Keeping it simple. There’s only one custom function in my theme, and it’s only a couple of lines long. Instead of creating a bunch of different templates for different page types, I kept just about everything in the index.php file and used a few conditional statements. This may not be the best coding practice, but I don’t need it to be particularly modular, and this way I can keep track of everything much more easily.
• Keeping CSS semantic and separated. I broke my CSS into 3 files: a reset.css file (clears out all the default browser styles) a base.css file (building up things like basic typography, spacing, formatting that was stripped out in the reset file) and the theme’s style.css file which basically defines all the custom things you see. And everything is named in a meaningful way, rather than in some crazy shorthand. With just reset.css and base.css in place, the site would look like a web site from 1992, but all the content would be there and everything would work.
• Putting lots of comments in the code to explain what’s going on. I figure if I don’t touch this for 6 months, I’ll be in trouble if I don’t include good comments.

Unfortunately, there are still some things that I’d like to change that are going to require some heavy lifting on my part. There are a few things that seem to be buried deep in WordPress’s functions that shouldn’t be (text strings and CSS styles). I’ll probably have to learn some more PHP to write functions to override the behavior I want to change, but I don’t think there are too many of these things. There are also a couple of minor CSS hacks to get things working across the 4 browsers I tested (Internet Explorer 7, Safari, Firefox 3 on Mac & PC). If I get to updating some of this, I may release the theme to the public.

A Few Thoughts on How WordPress Could Improve

I imagine that this has been the trend all along as WordPress has been updated over time, but these are some of the main shifts I’d like to see with WordPress:

• Every bit of what can be displayed should be modularly accessible. I should be able to choose to show very granular bits of information or not rather than sometimes getting the kitchen sink.
• Text and styles should be completely configurable. Text strings shouldn’t be written into WordPress functions, you should be able to confure them. Most HTML tags and CSS ids or classes shouldn’t be hard coded into WordPress functions, you should be able to use the ids and classes you want.
• There should be a consistent way to configurable all this stuff. It would be nice to have a web UI to do it all from your WordPress dashboard, but even just having a standard way to call the display of each element, and pass text, HTML or code to display/execute before & after the element would be great. It’s possible that this last bit exists, but I just haven’t figured it out yet. My sense is this is that what I want is only partly there.

As I use it to blog, I’m sure I’ll more to write about WordPress and its UI problems big and small. But for now, long live WordPress!