0:00
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.
2:51
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.
4:34
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.
5:25
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.
6:45
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.
7:06
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.
8:54
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
9:49
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.
11:23
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.
12:11
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.
14:04
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.