Hey, folks.

Welcome back.

The goal of this video is to go over our final three of Nielsen's ten heuristics.

Let's start with recognition versus recall.

So, Nielsen defines this heuristic as follows.

We want to make sure that we minimize the user's memory load by making objects,

actions and options visible.

The user should not have to remember information from one part

of the dialogue to another.

Instructions for use of the system should be visible or

easily retrievable whenever appropriate.

So to understand this heuristic, let's take a step significantly back and

think about actually short-term memory.

So, you'll recall from course one effectively what you need to remember is

that short-term memory is limited.

We only remember five to nine, for instance, digits or

five to nine chunks of things and what Nielsen means by recognition versus recall

here is that recall is something where you have to put something in one of those,

you have to use one of those five to nine slots.

Whereas recognition says, I recognize that.

You don't need to keep that in your short-term memory.

And very classically,

this is a very important story from a user interface design.

And more generally,

a command line interfaces where you have to remember what to type in.

So, this is an example of a command line interface from Mac OS exposing its

underlying Unix command line interface.

I have to remember that to copy a file, I have to use a certain command to

see what's in a directory I have to use a certain command, CD.

I always have to recall this.

On the other hand, in a Graphical User Interface, I can just go to menu's,

edit, copy.

I can recognize the commands I want, it doesn't tax my memory.

GUIs succeeded over command line interfaces,

graphical user interfaces defeated command line interfaces effectively,

because they tax your recall less.

They allow you to recognize or at least that's a major reason why they're so

effective relative to CLI's.

Now of course, this is an old battle.

Graphic User Interfaces, this dates back to at least the 80s.

So, Mac had one of the first commercially successful ones.

It was much more compelling and

easy to use than a DOS at that time on the PC side.

So we fought this battle a lot in the 1980s, but this is actually a battle that

we need to continuously fight in our own user interfaces and

let me show you some great examples of how recognition versus recall or

this heuristic has actually been very much honored in some very important

interfaces that most of us use on a daily or a weekly basis.

So, let's go to Amazon.

Obviously, a very prominent website.

Tons of research has shown that when you're browsing the web,

you very often are looking at something that you've looked at before.

We call this revisitation.

So let's say, I was shopping for something a couple days ago and

I thought I found something that maybe I wanted to buy, but

maybe I wanted to check with my wife if she was okay with me buying it.

And now I'm back on my computer and I have to remember, I want to go and

actually buy the thing.

I have to remember, I have to recall what the specific name of that is unless Amazon

does something specific.

So in the recall version,

I have to type in the search bar exactly the product name.

And if I make a mistake, it's going to cost time and potentially money.

You're going to see some people dropout of the purchasing process, but

Amazon has fixed this through a number of different means, but

one of which is it has a browsing history.

You can see which items you've looked at.

I can recognize that I wanted to buy this personal information management book or

this building online communities book, or this Bruce Springsteen album.

Yes, that's the one.

It does not tax my short-term memory, I don't have to recall.

This is the way to go.

This would be a violation of this heuristic.

There are all sorts of other positive examples of people following this

heuristic.

So for example, or systems following this heuristic.

So, the very simple convention that's actually implemented in all browsers

that I've ever used is that you have a different color for

links that you visited than links that you haven't visited and

this is allowing me to recognize places that I've already been.

Revisitation is very common on the web.

I say, yes, this is the website that I wanted to go to or this is the news story

or the several news stories here that I remember, that I want to visit.

The different color allows me to assess this.

Another good example is the SmartBar in Firefox.

So when I start typing in Nielsen right now,

because I've been putting together this particular lecture, Firefox shows me some

websites that I'd been to that are associated with this term.

It's not just a blanket search result.

It's places that I've already been.

This is allowing me to recognize the website that I wanted to go to.

It doesn't require me to recall information from my memory about

the specific website.

Another good example, Google Sheets, Google Docs and

all of Google apps pretty much do this.

It shows you which things you've used recently.

I can just recognize this.

This is our course outline actually for this course has all whether a video has

been recorded, whether it hasn't been recorded and so on and so forth.

I can never remember the name of this thing.

The good news is I don't have to, Google allows me to recognize the name.

I don't have to recall it, I can recognize it.

So that was all sorts of nice, fun, positive examples of systems,

doing exactly what Nielsen would want them to do according to this heuristic.

Let's talk about a case were we have a violation and

a violation of this heuristic and this is a fun example.

This has been the subject of some dissuasion in some of the user interface

design community.

I want to say dissuasion, I think I actually mean debate.

Command line interfaces require you to remember each command.

Graphical user interfaces allow you to recognize the commands.

Many people argue that gesture based interfaces like we're seeing in iOS and

Android these days are moving back towards recall, back towards command

line interfaces and one example of this argument is the control panel on iOS.

So, this is the standard iOS home screen right here.

To get this control panel, which has all sorts of important information.

So to turning on Wi-Fi, turning on Bluetooth, turning on do-not-disturb mode.

Very important when you're playing your Podcast or your music and so on, and

so forth.

But to do this, I have to know a priori without knowing anything else,

I have to know that, I have to swipe up here to get that.

This is effectively,

me remembering a specific command in a command line interface.

They're more or less the same.

I'm not recognizing, I'm recalling.

And so, people have been criticizing gesture-based interfaces for relying too

much on recall and this is, I would say, a violation of Nielsen's heuristic.

And a pretty serious one, given the importance of some of these commands.

If you want to solve this problem, the solution is you give a visual indicator

at the bottom of the, you can see it, at the bottom of the screen.

So you maybe have something here that's indicating, hey, swipe up.

In certain cases, Apple does this, but not here.

Not in the base home screen.

So this would help users recognize a command rather than recall a command and

it would make this heuristic violation or make it go away, at least in my view.

So let's move on to our next heuristic, which is aesthetic and minimalist design.

What this heuristic tells us, the definition according to Nielsen is that

dialogue should not contain information which is irrelevant or rarely needed.

Every extra unit of information in a dialogues competes with the relevant

units of information and diminishes their relative visibility.

Let's look at a great violation of this particular heuristic,

in this case, from weather.com.

When people go to weather.com, what type of information do they want?

They want the weather.

They want the current temperature, maybe the forecast.

Any information that competes with that information is a violation of this

heuristic.

And boy, howdy, do we see a lot of competition here.

We see a video about a phantom trailer Thundering Down the Highway.

That looks good.

We also see once a Major movie set, Now Abandoned.

An abandon movie set, that sounds interesting, but

what these are actually wanting to do was go for this information here.

So, this is a violation of this heuristic.

I actually might give it a, I say, I put two here earlier.

I may be give it a three here, because it's such a serious violation of

this particular heuristic, although the damage isn't particularly intense.

It's written here that weather conditions and

forecast are swamped by other information, and boy is that true.

So, this heuristic is actually very closely associated with the notion of

chartjunk from information visualization.

Chartjunk is stuff in a graph that is not just the data the graph is visualizing.

So, you can see this big coin is an example of chartjunk here and

this monster is an example of chartjunk here.

You can see this is the graph that is actually being visualized, but

it's in the monster's teeth here.

So, the reason they bring up chartjunk is that like this heuristic chartjunk,

I think is a little out dated and a little controversial and let me tell you why.

This is the one heuristic where I'm not in full agreement.

Oftentimes, this stuff adds utility that

isn't maybe directly obvious and this came out in a really great study done

by Scott Bateman and his colleagues back in 2010, that showed that

visualizations with chartjunk actually had the same communicative capability.

They communicated the information just as well as the visualizations without

chartjunk, but that people remembered those charts and

the content of those charts much better a little later.

So this paper was controversial and caused a lot of discussion and I think the end

result at least in my view is that chartjunk and non-minimalist design,

violations of this heuristic are okay if you're very intentional.

Let me show you a good example of a success here.

Google's Doodles.

Google Doodles are classic non-minimalist design.

Everyday they have different things, it's causing a distraction.

People are going to Google not for the fancy doodles, but

they're going to Google to search and to see search results, but Google Doodles

have this effect of building a positive sentiment around the brand.

They're fun, people associate Google with fun and these types of things.

And in addition, minimalist design often is culturally defined.

So as we discussed in the last course,

certain cultures have a higher tolerance for information density.

So, a lot more can be crowded in one space in other cultures.

So between some of the new work associated with chartjunk and non-minimalist design

being good and the cultural concerns here, I'm actually going to say, it's okay to

violate this heuristic in specific cases and the rules of thumb that you should use

when thinking about this heuristic are as follows, at least in my opinion.

Other practitioners, other researchers might have different views.

Two rules of thumb.

One, eliminate extremes in non minimalist design.

So the weather.com example, that's an extreme.

It's a little bit too much.

Second, only violate this heuristic consciously.

So you can violate this heuristic, but you better be able to back it up and

I thought this might be a fun sort of meta example of this.

So I have rules of thumb, I put a thumb here.

This is not minimalist, but I figured it might be a good way for

you to remember these two rules.

It makes this slide more memorable.

So, at least that's my justification for using non-minimalist design.

And I, therefore, I'm following in a very meta way these two rules of thumb.

So let's jump to our final heuristic, which is help and documentation.

This is an interesting one.

Nielsen defines this heuristic as follows.

Even though it is better if the system can be used without documentation,

that's critically important.

It's always better that the system can be used without documentation.

Nielsen does say, it may be necessary to provide help and documentation.

Any such information should be easy to search, focused on the user's task,

list concrete steps to be carried out and not be too large.

So this is the last heuristic, but is it the least heuristic?

Yes, it is.

So the key thing actually in that heuristic,

I think is that your system should be able to be used without help and documentation.

Now that said, if you have absolutely no documentation,

zero and it's a major system, I would actually say

that it's a violation of this heuristic and a pretty serious one.

There are times when users, for whatever reason can figure something out and

we all know that it turns to documentation.

In that case, if it's not there, that's a pretty serious issue.

You'll get a lot of complaints you could imagine.

The good news though is that in the modern day and age, documentations aren't just

handing over your system to a technical writer to write a manual.

There are all sorts of new, I think more engaging and

often very much cheaper ways to build documentation.

One of which is to use things like stack exchange or stack overflow.

I taught a web applications class recently and we used meter and

it's a a new framework and they were advertising their framework saying,

we have a whole bunch of questions that have answers on staff overflow.

They're effectively bragging about their documentation.

This is a great way to build up documentation about your system.

Now in order to get a community around this and

to get a lot of people asking questions, a lot of people giving answers.

That's a whole other can of worms.

A lot of what defy faculty who teach this class study is figuring out ways to do

that, but that's a different course.

Another thing you can do is build one of these answers websites where you hire some

people to answer customer questions.

You don't need to have the community answering.

You can just have people asking the questions.

Microsoft has one of these.

Apple has one of these as well and then there's some other good stuff.

Jake Wallbrack, a colleague of ours at the University of Washington has a startup

that does contextual help that you remember in Nielsen's definition,

there's a strong context element.

You want help when you need it and this startup basically predicts what people

are going to have trouble with, and brings up that documentation.

You can see here in, let's see over here, there's the cursor.

You can see here in this little menu here, it'll give you the questions and

answers relevant to the specific context in the specific application.

So, this is another interesting way to go about building help and

documentation in a nontraditional, non-boring way.

We are done with our ten heuristics.

Good work.

Whoa, we get a big check mark across the whole list.

Here is some additional reading that you might be interested in and

I will return next with a video about your assignment.

Nielsen's Heuristics (Part 3)

Evaluating User Interfaces

Meet the Instructors