"designing the obvious" at wordcamp

43
I’m RHJR, and I’m a WP blogger. Designing the Obvious, however, is a book about web application design principles. And I didn’t talk about blogs in it at all. But you guys are all here to talk about blogs, so I’ve adapted things a bit, just for you WordPress geeks. Today, I’ll follow each topic with an example of how to apply the concept to a blog. We’ll talk about: 1) Building only what’s absolutely necessary (and how to do it) 2) Getting users up to speed quickly so they can start liking your app 3) Surface the important elements on a page 4) Handle errors

Upload: rhoekmanjr

Post on 27-Jan-2015

108 views

Category:

Technology


0 download

DESCRIPTION

This is the presentation I had originally planned to give at WordCamp. Several people have asked for it, so I posted it here.

TRANSCRIPT

Page 1: "Designing the Obvious" at WordCamp

I’m RHJR, and I’m a WP blogger. Designing the Obvious, however, is a book about web application design principles. And I didn’t talk about blogs in it at all.

But you guys are all here to talk about blogs, so I’ve adapted things a bit, just for you WordPress geeks. Today, I’ll follow each topic with an example of how to apply the concept to a blog.

We’ll talk about: 1) Building only what’s absolutely necessary (and how to do it) 2) Getting users up to speed quickly so they can start liking your app 3) Surface the important elements on a page 4) Handle errors

Page 2: "Designing the Obvious" at WordCamp

build only what’s absolutely necessary.

First, let’s talk about building only what’s absolutely necessary.

Page 3: "Designing the Obvious" at WordCamp

Early on, we need figure out what really needs to be built. Seems obvious, right? Well, it is, unless you want to build something really good.

It’s easy to build everything that comes to mind. It’s easier to do that than it is to cut things out and build only what’s absolutely necessary. But that’s what needs to be done, because a more focused app is easier to learn and use, and easier apps lead to repeat business.

So take your wireframes (like this one) and strip things out of it until the essence of the app shines through. What’s the core purpose of the app? What’s it do? Focus on this.

Let’s see how to do that by stripping some things out of this “fictitious” webmail app. In the book, this is called “Interface Surgery” and there are several examples.

Page 4: "Designing the Obvious" at WordCamp

Strip out the ability to search the web. - All browsers have this. It’s redundant to include it.

Page 5: "Designing the Obvious" at WordCamp

Strip out the Saved Search feature.- Takes longer to save and re-run the search than it does to just type it in- This means we can get rid of the two tabs as well. Cleaner design.

Page 6: "Designing the Obvious" at WordCamp

Move the Storage Used info to another screen. It doesn’t need to be in the main UI 100% of the time.

This is a webmail app, right? So send an email when the inbox starts to get full.

OK, see the INBOX label? It’s big and bold to tell you which mailbox you’re looking at ...

Page 7: "Designing the Obvious" at WordCamp

So get rid of the TITLE BAR for the FOLDER box. You already know from the sidebar what folder you’re looking at.

Get rid of Apply Action dropdown. Move these actions somewhere else. (We’ll talk about those in a moment).

Clean up the mess. Again, a simpler design.

Page 8: "Designing the Obvious" at WordCamp

Surface the command links (reply, forward, etc.)

Apply some logic to the links so they’re disabled when they can’t be used. (Heck, you’re building fewer features now, so spend some more quality time on what’s left and make it great.)

Clean up the mess again.

Page 9: "Designing the Obvious" at WordCamp

Reminder: This was the original.

Page 10: "Designing the Obvious" at WordCamp

This is the new version. Much cleaner. Much more focused.

Not a huge difference to us, but MASSIVE to a typical user.

Let’s talk about how this applies to a blog. Usually, blogs contain several elements: a post, a link to another post (or two), a link to the archives ... things like that.

Page 11: "Designing the Obvious" at WordCamp

[example of this applied to a blog]

This is Sam Stephenson’s blog (and no, I have no idea who Sam Stephenson is). He stripped out almost everything. He left out the blogroll, the category links, the list of recent posts ... heck, he left out the post footer!

There’s no way to digg this, StumbleUpon this, trackback it, comment on it, or anything. Each page contains exactly one post.

I love this design. Sadly, Sam has only ever written two posts.

Bloggers are a creative bunch, and I certainly am not saying everyone should do this. This is sort of extreme. What I’m saying is to figure out what’s actually important to YOUR blog, and kill everything else.

If you don’t need links to previous and next posts, get rid of them. If a blogroll doesn’t really help you, ditch it. If you and your readers won’t benefit from a list of links to categories, don’t include one.

Page 12: "Designing the Obvious" at WordCamp

Sometimes a blog doesn’t even need standard blog elements. A “tumblelog” is a form of a blog that has no titles, no footers, no categories, no trackbacks, no search, no archives ... nothing. It’s just a long series of very stream-of-consciousness posts that are either quotes, links, images, videos, or ideas.

Of course, the trick is to avoid removing too much. Your page still needs a page title to provide some sort of context. Tumbelogs often lack the most basic and standard elements of a web page. So be careful if you do this.

Page 13: "Designing the Obvious" at WordCamp

turn beginner’s into intermediates, immediately.

Now that you’ve stripped down the app so only the important stuff is in it, it’s time to focus on turning beginners into intermediates.

Page 14: "Designing the Obvious" at WordCamp

Alan Cooper - “perpetual Intermediates”

Most users are not beginners. People learn as much as they need to learn very quickly, thereby becoming intermediates. They rarely advance to expert level.

Design for the intermediates, but MAKE SURE PEOPLE CAN BECOME INTERMEDIATES IN THE FIRST PLACE. How? Instructive design.

Almost EVERYONE fails in the area of instructive design. They never tell users how to use the app, and they never figure it out on their own. If you hired me tomorrow to fix your app’s design, this is the first thing I’d look at.

That said, I did find a few examples of good instructive design work. Some of them are discussed in the book.

Page 15: "Designing the Obvious" at WordCamp

Surface the Help info.

Inline tips from Squidoo (from Seth Godin)

- Show up on rollover- Short, concise tips

Page 16: "Designing the Obvious" at WordCamp

Take care of the “blank slates”

Basecamp screencasts

Fill up the blank slates with useful information- Big red link- Screencast

Page 17: "Designing the Obvious" at WordCamp

No milestones exist.

This is what it looks like with no instructive elements. Not very helpful, eh?

Page 18: "Designing the Obvious" at WordCamp

My Yahoo!’s blank slate is filled with a preview of what your page could look like.

No, Michael Jackson isn’t on it all the time.

Page 19: "Designing the Obvious" at WordCamp

Welcome screens:

- Call out what can be done on the page- Show it to new users- Set it to disappear automatically after the 5th login or something - As people get more familiar with the app, you don’t want them to keep bumping into newbie stuff.

BONUS:- You can use this again when you have a new feature to announce, so it’s dual-purpose.

Page 20: "Designing the Obvious" at WordCamp

[example of this applied to a blog]

This is a rather well-known blog that breaks the same rule that most other blogs break.

It doesn’t make it obvious that headings are links. Almost all of the links on this page black and underlined. But the links to the permanent post page are green and have no underline. Oh, and the link directly to post comments is ... um, purple. You know, so it doesn’t match anything else on the page. Four different link styles on the same page.

So how does someone new to this page get to become an intermediate user of this blog?

Yup. He has to guess.

Page 21: "Designing the Obvious" at WordCamp

[example of this applied to a blog]

And in the tooting my own horn category, this is my blog.

Notice that every link on the page is orange. The only exception is the notification area at the top, but I underlined that one to make it clear that it’s a link, so it’s OK. ;)

Page 22: "Designing the Obvious" at WordCamp

surface important elements.

To further help users understand how to use your app, and so they continue enjoying your app ...

surface the important elements on each screen.

Page 23: "Designing the Obvious" at WordCamp

Seth Godin’s banana principle:- Put up clear signposts on a site and people will follow them, just like a monkey follows a trail of bananas.

Page 24: "Designing the Obvious" at WordCamp

What’s this page about?- There is a point to it, but who can tell what it is?

Page 25: "Designing the Obvious" at WordCamp

Add some links. Color makes things stand out. But not enough.

We want to turn these 3 links into giant, clear bananas.

Page 26: "Designing the Obvious" at WordCamp

Surface the main points of this page - the three hot spots.

Page 27: "Designing the Obvious" at WordCamp

Get rid of the instructions at the end of the text, and you’re done!

Much clearer. Now the monkeys can follow the bananas.

Page 28: "Designing the Obvious" at WordCamp

[example of this applied to a blog]

What’s the major call-to-action on this page? What is it that the folks at WordPress want me to do when I land on this page for the first time?

Hint: Download WordPress!

Where’s the link? In the header, of course! (Kidding.)

What pops out the most on this page? The word “Welcome” and the screenshot on the right. Neither of these things are clickable. And the word “Welcome” doesn’t mean anything to a user. It doesn’t help them, doesn’t get them started, doesn’t provide context, doesn’t do, well, anything.

Page 29: "Designing the Obvious" at WordCamp

[example of this applied to a blog]

Any idea what’s on Apple’s mind today?

There are over 30 links on the Apple.com homepage. Which one do you think they want you to click?

OK, so these aren’t blogs, but you get the idea. If you write a blog post promoting something on another area of your site, for example, include a link, and make it big and obvious.

Page 30: "Designing the Obvious" at WordCamp

prevent errors with poka-yoke.(POH-kah YOH-keh)

Once they start using the app, make sure they can use it without feeling like idiots by making mistakes all the time. This one of the best ways to improve your app. If people never make mistakes in your app, they’re going to feel really smart. That’s a good thing, and it’s something most companies never achieve.

From Lean manufacturing processes, this is Japanese for “error-proofing”

The best way to handle an error is to prevent it from happening in the first place.

Two types: Prevention and detection

Some examples ...

Page 31: "Designing the Obvious" at WordCamp

Popcorn button = prevention device.

Page 32: "Designing the Obvious" at WordCamp

“Did you mean?”

Great idea. Helps users fix their typos and helps them correct words they don’t know how to spell.

This is a detection device.

Page 33: "Designing the Obvious" at WordCamp

Google Suggest

Blurs the line between prevention and detection by helping you choose a good search term.

- Doesn’t work well for people who stare at their keyboards while typing, though.- Also, people tend to rely on the suggestions rather than their own search terms, which may have been better.- If using this, use it for lookup actions (like looking up someone’s phone number), not for searches

Page 34: "Designing the Obvious" at WordCamp

Undo systems = fantastic.- Get rid of JS alerts/confirmations (because they suck and no one reads them)- Clear visual notification that you can Undo

This should be in every web app where you can delete or seriously affect data. (Right now, it’s not even in every Google app, so we’ve got a ways to go.)

This introduces “forgiveness” into your app. People can play around without being terrified of breaking things.

Page 35: "Designing the Obvious" at WordCamp

Anyone signed up for ODEO?

This shot doesn’t do it justice, but these fields are HUGE. And it doesn’t really help anything. They didn’t do anything to make the form more usable, they just filled up the page.

Imagine this at 800x600 (for people with bad vision). Four fields, and two of them would be below the fold.

Page 36: "Designing the Obvious" at WordCamp

RememberTheMilk

Inline validation = prevention AND detection.- Detects errors immediately and notifies you- Prevents users from hitting Submit before the form is correct.- Should still be able to hit Submit (accessibility reasons, disabled JS), but this alleviates most of the issues people have with forms. And they really appreciate it.

This one is good, but not quite perfect. Tells you there’s an error as soon as you hit the field, before you have a chance to enter anything.

Page 37: "Designing the Obvious" at WordCamp

OurProperty.co.uk

Much better. Also includes inline tips.

Let’s take a closer look at the decisions for your form design.

Page 38: "Designing the Obvious" at WordCamp

Typical form.

Thinking back over what we’ve talked about so far, what can we do to make it better?

(Take suggestions.)

Page 39: "Designing the Obvious" at WordCamp

- Add instructive text- Display checkmarks when fields are correct.- Show errors inline.- Show them next to the field.- Show them AFTER the field loses focus- Disable the I’m Done button

You can make these really big - it helps. Here’s an example:

Page 40: "Designing the Obvious" at WordCamp

Eventful.com - large errors = easy to see

MOST users can complete this form correctly before hitting SUBMIT- Good for users- Can translate to less bandwidth for you, because you’ll only get ONE server call

Page 41: "Designing the Obvious" at WordCamp

Completed form = I’m Done button lights up and you’re good to go.

Sadly, I couldn’t find an example of good error-handling on a blog. Typically, the only place this would apply is when a user is adding a comment to a post, and when I went through all the blogs I read normally, I didn’t find any that used inline error messaging like this.

Obviously, the moral of the story is that you should do add this to your blog. And since WP is open source, you can hack around it and make that work. And since I’ll be spending Monday with the dev team, I may just try to talk them into building this functionality into WordPress. :)

Page 42: "Designing the Obvious" at WordCamp

Questions?

Page 43: "Designing the Obvious" at WordCamp

Check out the blog at www.rhjr.net for continuous reality checks on application design.

I’ll be around, so feel free to come talk to me about your apps and ask questions and such. Enjoy the rest of WordCamp!