Tip:
Highlight text to annotate it
X
Fitzpatrick: So this is our talk about how to design--
Not so much how to design, but how to think more in a--
about users when you're writing software.
Collins-Sussman: Right.
Well, actually, let's introduce ourselves first.
Fitzpatrick: Okay.
Collins-Sussman: What's your name?
Fitzpatrick: My name is Brian Fitzpatrick.
Most people call me Fitz.
Collins-Sussman: My name is Ben Collins-Sussman.
I'm just Ben.
And we are gonna talk about--
It's a very subjective talk.
It's based on our experience.
We come from the open source world.
We both worked on subversion for many years,
and now we're at Google,
and we work on an open source team,
and we actually work on
Google Code's project hosting service.
That's what I do. You do some great management stuff.
But what we do essentially is--
everything we're talking about is coming from our experience
of working with communities of users.
Open source software, closed source software,
what is-- what kind of relationship
do you have with those users?
Fitzpatrick: And this is completely
based on a series of anecdotes that we're gonna tell
in addition to some little bits of information,
but most importantly, this is a subjective talk.
These are our opinions.
If you disagree with them-- and that's fine--
you can get your own talk,
and have your own opinion somewhere else.
But seriously, we're--
this is--we're sort of gonna tell this
through a series of anecdotes
and things that we've experienced.
And that's it.
Collins-Sussman: Yeah, and there'll be
time for Q and A when we're done, so--
First thing we want to talk about
is we're all programmers here, right?
Or most of us are, so when you think about, well,
what does it mean to have successful software, right?
There's a lot of different metrics.
You can say, well, it's really fast, or it has a lot of users,
makes a lot of money, right?
Or something, or maybe it's really clever.
But there are a lot of things to think about
besides the technical side.
It's not just about how great your code is.
It's actually about...
Well, there's a whole social aspect to it
that a lot of programmers forget
because we're so busy writing code all the time.
That's what we want to talk about.
Fitzpatrick: Right, when you're thinking about software,
engineers typically think about the code,
and some twist of algorithm, or writing software,
or a neat bit of Java that they might write.
Collins-Sussman: That's the meat.
Fitzpatrick: Sort of the meat, right?
So people tend to think about
the meat of your application.
However, what you don't really think about
is sort of, like, making that look more presentable
and more appetizing to our users, right?
Typically, in the past, engineers have seen
what happens when people put sizzle onto a product, right?
What you get is you get a whole bunch of sizzle,
and you get a whole lot of no steak.
Right? And so people tend to be a little wary--
Engineers tend to be a little wary of doing that.
Collins-Sussman: Well, it's also usually--
It's a relationship with the marketing department, right?
Ah, what are you doing to our product?
What are you promising about it?
What are you saying about it, right?
And I guess we're here to talk about how
that is not necessarily a bad thing.
And trying to create a better understanding
of what does it mean to add sizzle to your product--
how do you make it presentable to the public
without feeling like you're compromising your ideals,
and, like, it's still good software?
Fitzpatrick: Right. Exactly.
So a lot of this stuff is not gonna come
as a complete surprise to you.
This is sort of an opportunity to bring it together
as well as to remind you of some of these things
that you might not think of day to day
when you're sort of down in the trenches
writing up an application.
Collins-Sussman: Pull it from their subconscious.
Fitzpatrick: Exactly.
So we're gonna focus
on three particular areas in this talk.
Collins-Sussman: Yeah, so the first part,
we're gonna talk about marketing.
What does it mean?
How does it relate to you as a programmer?
And when you think about marketing, right--
Just say the word, "marketing."
What is the first thought that comes to your head, right?
You probably think about this guy, right?
Ah, run away.
Want nothing to do with him, right?
Fitzpatrick: This guy is all sizzle and no steak.
Right?
This is what you tend to think about, okay?
The real thing is is that people are used to--
when they think about marketing or stuff,
engineers are used to being lied to.
Okay?
Engineers don't like being lied to, okay?
Anybody know when Duke Nukem 3-D was announced?
audience member: [indistinct]
Fitzpatrick: 1997. Okay?
That was 11 years ago,
and it took 'em 11 years to go out of business.
Collins-Sussman: 12. Fitzpatrick: 12?
12 years. Collins-Sussman: [laughs]
Fitzpatrick: 12 years ago,
but they never released a piece of software.
And that's the type of distrust that I think we as engineers
tend to harbor when we hear about this type of stuff.
Collins-Sussman: I think we're just inoculated as a culture
to any kind of advertising or marketing, right?
We're skeptical about everything we hear,
'cause we just believe that marketing and advertising people
are always lying all the time, right?
Programmers really don't want anything to do with it.
Programmers are very logical people,
they're obsessed with finding the truth,
finding the true thing,
and only talking about, you know, logical, true stuff.
I mean, we live with compilers.
Those are the tools we use every single day, right?
We like order, we like predictability,
we like control.
We don't like listening to people try to spin things
and then we're sort of left to guessing
as to what's real and what's not.
Fitzpatrick: Five years ago I was the vice president
of public relations for the Apache Software Foundation,
which is an organization made up almost exclusively
of engineers.
And, you know, most people thought,
oh, we shouldn't have to do PR.
If we write the best software,
people are just gonna come use it.
And meanwhile, other web servers
and other pieces of software that competed with Apache
were eating their lunch because when an analyst
would come up to a commercial company and say--
Collins-Sussman: "Where's your white paper?"
Fitzpatrick: "Where's your white paper?"
and "We want you to answer this, this, this,
this, and this about your software,"
and the company would, you know, have four or five PR flacks
get down on their knees and then worship the analyst
and tell them how wonderful they are,
and they do all their work for them and hand it to them.
And an analyst shows up at Apache
for one project in particular,
which will remain nameless,
and says, "Hey, we want to know this, this, and this
"about your projects, and blah, blah, blah,
"we're gonna write a paper, et cetera,
and go do all this work,"
and their basic response was, "Go screw yourself.
Join the mailing list and find it yourself."
Collins-Sussman: "Go read, you know. Go read our docs."
Fitzpatrick: Right.
Collins-Sussman: "Not our problem."
Fitzpatrick: So the best approach probably lies
somewhere in between those two approaches.
The sort of sycophantic begging, and then
the, like, "Go read the mailing list."
Collins-Sussman: Absolutely.
I mean, the other thing that programmers like to do
is especially when it comes to legal things,
they start trying to interpret the law, right?
I mean, there's a lot of issues that have to do
with marketing and PR, and they always get entangled
with legal discussions, right, licensing,
and what are we allowed to say and or not say,
and programmers love to look at laws and licenses
and try to process them like code,
when in fact, if you are a lawyer, or you know lawyers,
they will laugh at you if you talk about that idea, right?
'Cause the legal system is not perfectly rational.
It's not logical. Fitzpatrick: What?
Collins-Sussman: I know, it's crazy.
Fitzpatrick: Yeah, if you're ever talking about something
legal with a license, you say, "well, it should do something,"
stop yourself right there
because you're clearly going down the wrong path.
Collins-Sussman: Absolutely.
Fitzpatrick: But beyond this sort of obsession with truth
is that we expect some sort of a meritocracy, I guess.
That people put the most effort into something
or the best technical thing would win.
Collins-Sussman: Right, but if that were true,
we'd all be using Betamax--
well, nobody uses VHS either anymore--
but the classic story, right?
Fitzpatrick: But it had a good run.
Collins-Sussman: Betamax was technically superior to VHS,
and yet VHS won, right?
So not everything-- the technically superior product
does not always win, right?
That is not the only metric you need to think about
when you're saying,
"well, how is my product gonna be successful?"
You need some sizzle. Fitzpatrick: Right.
Collins-Sussman: To some degree you need it.
Whether you like it or not.
Fitzpatrick: So the point that I try to make is that
truth is actually fungible.
Okay, there are different shades of truth,
and this is a mean that I've been trying to propagate
for years, which is that perception--not procession--
but perception is 9/10 of the law.
What it comes down to is that--
Collins-Sussman: First perception.
Fitzpatrick: Exactly.
What people see is the reality, whether or not it's true.
What people will believe.
And marketers have used that to their advantage
for years and years and years.
There's no reason that we as engineers
shouldn't do that as well.
Collins-Sussman: Typically in the first 2, 5 minutes
of using a piece of software,
you formed an opinion about it, right?
It doesn't matter whether you've--you know,
whether you read the docs
or you should have read the docs, right,
or you get an opinion about it very quickly.
There's either a good or a bad barrier to entry,
and then you've made up your--
and that's the truth you now live with.
You have a certain feeling about this software,
whether you were fair in judging it or not.
Fitzpatrick: Well, with Subversion
we were particularly conservative
in calling Subversion 1.0
because when it comes to a version control system,
if it loses your data,
you're probably never gonna come back.
Okay, data--that's sort of an important thing.
It's not really the best,
technically the best version control system out there,
but it was generally perceived
by people as being a good thing.
Moving along,
one other thing that you can sort of have
the sizzle in the steak
is that under-promise and over-deliver.
You still have great things to give to people,
you still have a great piece of software,
but you don't have to tell them everything
that you want to give, maybe,
so you tell 'em the first few things.
I come from New Orleans,
and in New Orleans we talk about lagniappe,
okay, a little bit of something extra.
Like you buy a dozen doughnuts,
you get an extra doughnut free.
You buy five pounds of meat and you get a pound of liver free.
I don't know why that was ever a good thing,
but apparently that's the way it worked back in the day.
Collins-Sussman: But you certainly
don't market that, right?
You don't write that in the coupons, right?
It's just one of those things you do.
In the same way we're talking
about under-promise and over-delivering,
Google, as a policy, doesn't pre-announce products.
We don't send out endless press releases saying,
"We're working on this cool thing.
It'll be done this quarter."
'Cause then essentially we set ourselves up for failure.
It's a matter of, you know, surprising people,
and saying, "Isn't that wonderful?"
Fitzpatrick: You set your expectations really high,
and then you wind up with something
people aren't looking forward to.
So that's sort of the marketing angle,
and we want to talk a little bit about customer service.
Now, sort of close your eyes for a second and think--
what do you think about when you hear "customer service"?
Collins-Sussman: Mmm...
Fitzpatrick: In this day and age,
especially in the United States,
people think of customer service,
they think of a service-oriented industry where someone
is doing something for someone else,
and sort of a one-on-one kind of thing.
Collins-Sussman: But it's also sort of considered
the bottom of the ladder, right?
Like, working the help desk in a company.
Oh, my, no. Customer service tech support.
Got to get out of there. What a waste of time, right?
Fitzpatrick: So we have a graph here
that we spent minutes researching.
It's basically-- you start off, and you--
if you have a successful piece of software,
you're going to get more users over time.
That's what everybody wants, I think.
I don't think there's anyone in this room
who writes software that doesn't want more people to use it.
The problem is is that as you add users,
you don't stop writing code.
You continue adding to your--
the complexity of your application.
Collins-Sussman: More and more features,
more and more feature creep, at least.
Maybe the users are asking--
Maybe the power users are asking for more features
so you're like, "Great, more code, throw it in, throw it in.
Look how great this is."
Fitzpatrick: The problem is is that as time goes on,
and your user base widens,
you attract less tech-savvy users.
Okay?
And the combination of these three different factors
results in an exponential increase in despair.
Collins-Sussman: Very carefully measured.
Fitzpatrick: Very carefully measured.
Exactly.
But the point is is that this is something
that's really important to realize,
is that this complexity is very difficult
for users to sort of grok and understand,
but you have to listen to them.
This is part of customer service.
You shouldn't just assume that they're dumb.
We had a talk yesterday at the ignite
that was just fantastic where they were talking
about, you know, give your users the real thing.
Don't give them some dumbed-down,
toy version of that thing.
I think that's a great point.
Collins-Sussman: Right.
I mean, they're not dumb people necessarily--
Sure, a few of them out there are dumb,
but there's not a safe assumption to assume
that just because somebody's asking a question or needs help
or doesn't understand something about your software
that they're inherently dumb in general,
or they're just not techie people, right?
I mean, if something is wrong
you actually need to hear what's going on,
and the first step is not be condescending.
It's to respect and listen carefully
and really try to get some empathy going
with what they're experiencing.
I mean, we're so used to being holed up with our compilers
and our code that we sort of lose all perspective
of what the rest of the world sees.
Fitzpatrick: Right, and people just want to be heard.
So give them an opportunity to be heard.
Even if they're not writing code for you,
they can give you valuable feedback.
Collins-Sussman: You can let them
file bugs in your issue tracker
and respond with them,
so then they at least feel like
you are listening to them in some degree.
Fitzpatrick: An example of this is Google Moderator.
We've--you know, I mean... Collins-Sussman: Oh, yeah.
Fitzpatrick: The White House recently used that
to sort of get questions from people.
And setting up a moderator instance for, you know--
What do you guys want?
Let's get some feedback,
and let's get some people to vote it off.
In the issue tracker, users can star things,
and you can sort of see themes.
And we notice this very clearly in Google Code itself.
We have an issue tracker for the product.
and we heard very clearly different pain points
that people had, and different features
that they really expected the product to have.
Collins-Sussman: The trends become really obvious
if you start deliberately listening
and open--creating some kind of open forum to get feedback.
It becomes very obvious what's important and what's not.
rather than, you know,
just what you happen to think is important
it's really important to listen
and get that data from the outside,
not just from the inside.
But there's a fear there.
People tend to be afraid of doing that.
First of all, because they get a lot of crazy ideas, okay?
And they feel like, oh, God, if people start saying this
I'm gonna have to wind up writing this,
which is not true.
Collins-Sussman: You don't have to listen to every quack.
Fitzpatrick: You don't have to listen
to every single idea that comes in the long tail.
Just pay attention to the ideas
that you're hearing over and over again,
or the questions, or the themes,
or the bugs, that sort of thing.
Try to do fewer things better.
And we sort of use a metric of target in the 80%.
As opposed to the 100%.
Collins-Sussman: Right, it's really--
I think it's really great that if your product can do 80%,
it can solve 80% of everybody's pain really really well,
you're great.
You see a lot of failure happens when people
try to be absolutely everything to everyone.
Every bell and whistle in the world.
I mean, I guess one example is Emacs, right? [laughs]
Fitzpatrick: Exactly.
It's everything to no one.
Well, a quick survey-- who in the room uses Emacs?
Raise your hand.
Who uses the I?
Okay, fight.
No, just kidding. [laughter]
But seriously, though, I mean,
I've been an Emacs user for 12 years,
and it makes me crazy 'cause it's just like the Swiss Army--
Collins-Sussman: Occasionally you will see products out there
that try to be everything to everyone.
There's some wacky-- We're not sure what this is.
I think it's...
Fitzpatrick: We actually do know what this is,
so don't email us afterwards.
People emailing us explaining exactly what it is.
But, you know--
Collins-Sussman: Well, there's more than one version of it,
so it must be important, right?
Fitzpatrick: It has a lantern on the back, too.
A big, like, tube lamp.
Collins-Sussman: But it's got a competitor, right?
Fitzpatrick: Right, and there's more of these things.
Collins-Sussman: Don't be this. [laughing]
Fitzpatrick: So this is an example of something
that's just utterly terribly designed
'cause it's trying to be--
I think it's trying to be too many things.
I understand it's an emergency gadget, remember that.
Collins-Sussman: Okay. But what's a good example?
Fitzpatrick: Here's a great example, okay?
You can't boil an egg in this,
you can't--you know, you can't cook a whole turkey in it.
It's a toaster oven.
You can make toast, you can toast a bagel,
you can do some small pieces of fish, maybe...
Collins-Sussman: Make pizza.
Fitzpatrick: It does it really well.
And after we gave this talk last year,
someone sent me a picture of a toaster
with a radio on the side of it.
Collins-Sussman: Argh...
Fitzpatrick: I'm like, you don't get the point;
that's not the point.
Collins-Sussman: So this is-- this does a lot of things.
Most things for most people.
Incredibly useful to a wide variety of people.
Doesn't do absolutely everything,
but boy, you know, it hits that sweet spot.
So the next thing you need to think about,
I guess, is trust.
And what we mean by that is it is--
Nice effect.
It's an irreplaceable resource.
Trust is one of these things that you--
It's a reputation that you build up
with your users, and it's one of those things that--
Makes me think of it as, like, a bank account.
Every time you do something well, or you listen to people,
or, you know, you help solve their problem in some way,
you get a little bit of money,
you put it in that bank account of trust.
But it's very, very easy to destroy that bank account.
You do one evil thing,
or one thing that's a slap in the face of the users,
and all the trust is gone.
Fitzpatrick: Well, people typically
do that for short-term gains.
Your temptation to betray user's trust, I think,
is for short-term gain, which results in a long-term loss.
If you get users to trust you,
and they like your product,
they'll stay with you through thick and thin
for a very long time.
And the best example of this
is how many people in this room own a car?
How many people in this room have a mechanic that they trust?
Collins-Sussman: [laughs]
Fitzpatrick: Okay, see me after this talk, please.
No, but seriously, this is a great example of--
Collins-Sussman: Why is that?
Fitzpatrick: I think mechanics, for the most part,
aren't interested in long-term customers.
I think it's harder to do that.
Collins-Sussman: It's an assembly line.
Right? In these typical situations--
Oh, my car needs maintenance.
I'll go take it to some random dealer,
who I have no real personal relationship with,
and they put it through an assembly line.
Then they always try to up-sell you
to do something that you don't really need, right?
And we kind of expect it at this point.
Fitzpatrick: My grandfather owned--managed a Firestone store
for 35 years, and after the first 20 years,
95% of his customers were returning.
Return customers.
And that's because he never tried to sell 'em--
They come in for a flat tire,
he'd never try and sell 'em a radiator flush.
"Oh, it looks like you need
your flob-dangle zip-zopped or something like that."
Collins-Sussman: Absolutely. Fitzpatrick: People--
I don't think people--
Whether you know a lot about a car or not,
I think it leaves you
with a sort of sick feeling in your throat,
like, "I'm being played," you know, to some extent.
But we've got an example of that in Subversion as well, right?
Collins-Sussman: We worked on the Subversion Project
for many years, and one of the things
we set out at the beginning
is Subversion is basically gonna be a set of APIs
with a small binary that uses them.
'Cause we wanted people to connect to them
and write alternate clients and things.
But our APIs are very, very structured.
They occur at many levels,
and they're full of all sorts of promises
that "we will not change this, we will not change this."
When new versions of the product come out,
we very explicitly mark it.
Old APIs as deprecated,
we do not get rid of them, we make sure they work,
we keep them testing, and that's just about--
you know, that's a certain
kind of relationship with programmers.
They are another kind of user--
Fitzpatrick: But we reap the benefit--
We still get the benefits of that today
'cause Tortoise SVN was--
which is an amazing piece of software.
You know, those guys wrote
a really complex piece of software
where that just made Subversion much more popular in general.
Collins-Sussman: Absolutely.
The thing you need to think about
when you're listening to a user, right.
Someone's giving you a piece of feedback--
You often have to read between the lines.
What we mean by that is
do what I want, not what I say.
So, I mean, I had this problem-- like, for example,
trying to teach your parents, who may not be tech savvy,
how to use a computer.
Maybe you're on the phone with them or something.
They're saying one thing,
and usually you have to sort of listen,
and it becomes a skill,
like, well, I think what they really mean is X,
or they're describing something
in a way that's not familiar to you.
Doesn't mean they're dumb,
it just means they don't know the same lingo as you, right?
Or maybe they don't know how computers work--
Fitzpatrick: People have a different mental model.
I mean, people have a very different mental model
of computers-- how computers work.
Especially if they're not engineers.
And I'm gonna digress for a moment and tell a story
about a pencil sharpener
to give you an idea of how different
peoples' mental models are.
A couple years ago, my grandmother said, you know,
"Is your grandfather's computer still any good?"
Now it's a 1990 Macintosh SE.
You know, and it hasn't been used in six or seven years.
I said, "Oh, you know, I really don't think so.
"It's black and white,
"it doesn't have an Internet connection,
"you know, it's probably best to just, you know,
give it away or recycle it or something."
She said, "Oh, okay,
'cause I only ever turn it on anymore
when I need to sharpen a pencil.
Collins-Sussman: [laughs]
Fitzpatrick: And I stopped, and I scratched my head,
and I lis--played that back again in my head,
and I realized I really have to know.
I probably don't want to know,
but I have to know what she's talking about.
So I start asking some questions.
"Well, that's interesting, grandma."
And it turns out that she has an electric pencil sharpener
that's plugged into a power strip,
into which this Macintosh has been plugged into.
So once a week she'd take her pencils,
she would go into the office,
she would turn on the power strip,
and the little Mac would go, "beep,"
and it would start firing up his hard drive
and reading its operating system,
and she'd sharpen her pencils, and she'd kill it.
Collins-Sussman: Cut the power. Fitzpatrick: Mercilessly.
Before it even booted up.
I-I--To let you know... Collins-Sussman: Poor Mac.
Fitzpatrick: I rescued this poor Mac from its fate,
and it's been put out to pasture
with all the other Macs and Commodore 64s and whatnot.
Collins-Sussman: That is a good story about mental models.
Fitzpatrick: Right.
I mean, this made perfect sense to her, right?
But beyond that, seriously--
Beyond just listening to your users
and focusing on giving them good service,
take the opportunity to delight them, you know?
Collins-Sussman: This is an art.
Fitzpatrick: Being whimsical isn't actually bad.
I think it is an art.
And it's somewhat of a cultural thing
across some pieces of software.
Some pieces of software, I think, do this really well.
Collins-Sussman: Well, they'll put Easter eggs in,
or they'll do silly things,
but just something so they're
not taking the host quite so seriously.
They understand that there's some empathy going on
between the software and the company, and the user.
It's not just this formal relationship.
Fitzpatrick: Right, right.
Collins-Sussman: So I mean Google's an example of that.
We do a lot of silly things.
We've got doodles that, you know, happen year-round,
and we get unbelievable amounts of email
about particular doodles--
why we did do a certain doodle, or didn't do a certain doodle.
Fitzpatrick: But no matter what they do,
they get a big pile of, "We love this!"
and a big pile of, "We hate this!"
Collins-Sussman: I'll talk to my relatives; they're like,
"Oh, did you see the doodle that Google did last week?"
and I'm like, "Uh, I guess so."
Fitzpatrick: We're talking about inspiring passion in users.
I personally don't care if you guys love this talk,
or hate everything we say and disagree with it all,
as long as we spark some reaction in folks
and make you think a little bit about something.
You know, if you're asleep,
then that probably means we failed somewhere.
Collins-Sussman: Google has a long history
of doing April Fool's jokes as well.
Which--Every year it's something different.
In 2008, every single link on the YouTube front page
went to a Rick Roll.
Okay, great. It's funny. Right? One day.
Fitzpatrick: But why would you do that?
You know, most people don't even, like--
It seems so impractical and so whimsical.
But people remember that,
and they're like, "Oh, God, I remember; I was there."
Collins-Sussman: I think another great case is you can use humor
to sort of encourage people to do the right thing.
There was a social networking site
that went up for a little while where they really wanted
people to upload photos, and a lot of people
won't do that at first when they join
a social networking site.
So this site, what they decided to do
was put in a default image of *** Cheney to every new user.
And, oh, my goodness, everybody uploaded a new photo right away.
Fitzpatrick: Over 90% of their users uploaded a new photo.
Collins-Sussman: Clearly something humorous there, right?
But that's just another way of delighting the users.
So the third thing we want to talk about is focusing on users.
We talked about marketing and customer service.
What does it mean to actually focus on them
and have them affect your everyday activities?
Fitzpatrick: What do you think about
when you hear "focusing on users"?
You usually think about the orbiting brain lasers.
Collins-Sussman: No, no, not released. Next.
Fitzpatrick: Oh, we don't talk about prerelease. Sorry.
Collins-Sussman: [laughs]
Usability.
Fitzpatrick: It sort of falls under usability.
It falls under making your software something
that people can comprehend and do great things with.
If you just can't try out your software,
you don't have any users, right?
And like we said earlier,
the first impressions are really key to this sort of thing.
Collins-Sussman: And the barrier to entry.
Fitzpatrick: The metaphor we like to use
is one of a storefront.
Okay, if you're walking down the street,
you look in a store window, and you see something--
"Oh, hey, there's a doodad I want to buy."
You walk inside and you inspect it.
Okay, that costs you nothing but a few steps.
If you walk up to the door and they say,
"Stop. We'd like you to fill out this form.
All this information about yourself."
You're gonna be like, "Really? I just wanted to--
It's not that important to me."
And they're gonna go away before they even had a chance...
Collins-Sussman: Read this documentation, right?
Read this license agreement.
Fitzpatrick: Exactly. Collins-Sussman: It's crazy.
Back to the Emacs and vi, which we mentioned before,
when I first was introduced to Unix,
years and years ago,
I remember saying, "Which editor should I learn?
Emacs or vi?" and everyone in the room kind of laughed at me
and said, "Well, you figure it out.
Which one you want. We're not gonna tell you."
So I started up vi,
and I really didn't know what to do,
and I was typing things and nothing was happening,
and I kind of got frustrated.
And I started up Emacs, and I just started typing.
There were characters appearing.
"Oh, this is just like a word processor."
Fitzpatrick: How did you figure out how to quit it?
Collins-Sussman: Well, that was--I couldn't qu--
Fitzpatrick: I had to unplug the computer
to quit Emacs the first time I tried.
I'm like, "You got to be kidding me."
Collins-Sussman: I couldn't quit vi either,
but the point is, at least, you know,
in the first ten seconds
I just had an initial impression of, like,
"Oh, look, here's something that's familiar to me.
At least it's behaving somewhat like what I expect."
Now, maybe that's not the perfect example,
but I think it's a nice anecdote about first impressions.
Fitzpatrick: Well, there's a lot of examples.
I mean, Perl and PHP I don't--
They're not generally considered really powerful things
for writing Web apps or general apps, but they're really easy.
There's a really low barrier to entry with these things.
Or Fink, for example.
If anybody uses Mac OS X, there's this thing called Fink
that has all this extra packages and stuff.
In Tiger, they had this really nice disk image.
You just double-click it, you install it, and it's done.
As soon as Leopard came out, they didn't have this ready,
and so you had to download things and build things
and go through all this crazy stuff.
Collins-Sussman: Everybody stopped using it.
Fitzpatrick: Well, people eventually started.
Collins-Sussman: Well, a lot of people did.
Fitzpatrick: But it was a higher barrier,
and you're more likely to say,
"Oh, heck with it, I can live without this stuff."
Collins-Sussman: So one way we like to think about usability
is we have this bell curve.
On one end we have Donald Knuth,
on the other hand we have Fitz's grandmother.
Fitzpatrick: Who I love dearly, really.
Collins-Sussman: We do love her.
I've never met her.
So the question is where does your software fall
in terms of--we just want to think about drawing a line.
Every user to the right of the line
is able to use your software with not much effort.
So we can sort of talk about various pieces of software.
Fitzpatrick: We're version control geeks,
so we think Subversion actually falls pretty easy.
In the easy to use.
So there's a lot of people
that it's accessible to, quite frankly.
Collins-Sussman: Even people who've never
used version control before
find it not too hard to get used to.
Fitzpatrick: Right, and another example is Git.
Collins-Sussman: [laughs]
Fitzpatrick: It's technically a great piece of software,
but it's quite hard to use.
Collins-Sussman: And you can do anything with it, right,
but you have to be this tall or this technically awesome
to even, like, get past that first day or two.
I've heard people talk about the first two weeks of using Git
as being sort of mind-numbingly hard,
but I hear it's actually getting better.
That line's moving to the left now.
Fitzpatrick: So we're big fans of Mercurial.
Collins-Sussman: We are.
Fitzpatrick: Which we think is actually--
sort of finds a nice middle ground
for something as powerful as that.
Collins-Sussman: Incidentally, Mercurial is now available
on Google Code Project Hosting,
if you haven't seen our blog posts about it.
You can now use Mercurial instead of Subversion
if you're setting up an open source project.
So there's gonna be a talk about that at 4:30 today.
So side note.
Fitzpatrick: But the other thing to think--
We're talking about barrier to entry.
We have a couple more fun examples here.
This is sort of the standard,
you know, credit card application.
This is a massive pile of stuff.
There's plenty of sites you've been to that once you try out,
you fill out all this stuff.
Anyone in the room ever use TripIt?
Okay, TripIt is really cool.
Collins-Sussman: It's the best user interface ever. Why?
Fitzpatrick: For signing up
because you don't have to do anything.
Collins-Sussman: There is no user interface.
Fitzpatrick: You just start--
You can use the user interface, but you just start emailing
your trip to it, all the information.
Rental car, your flight, et cetera.
Collins-Sussman: You sign up for a car and hotel and airplane
on the regular Web sites, you get these receipt emails back.
"Thank you for registering for your flight, thank you--"
And you forward those emails to this email address.
That's it.
Fitzpatrick: And then it sends you back this nice...
Collins-Sussman: Yeah, you go back to the TripIt Web site,
and it's parsed all your emails
and put them into this beautiful itinerary.
And everything's organized. It's just fantastic.
Fitzpatrick: Super easy to use and try out.
Collins-Sussman: Absolutely.
Fitzpatrick: And then people wind up staying around.
Collins-Sussman: One of the things I want to talk about
is users versus usage.
This is an interesting term.
We talk about this a lot at Google.
We say, "I've got 50 million users."
And we're like, "Okay, well, what does that mean?"
Are they actually using it?
Some companies will say, you know--
They'll say, "We had 50 million downloads,
so we must have 50 million users."
Well, wait a second,
you don't know anyone's actually using your software.
So we talk about this a lot at Google
as a metric of success and usability.
We want to measure who is actually using your software
for how long.
Fitzpatrick: The example for that is--
Who knows what ar is? The ar utility in Unix?
Collins-Sussman: Anyone ever heard of ar?
It's in bin.
Fitzpatrick: It's bin ar. It's the Unix archive utility.
It's installed on millions and millions
and millions of computers, but no one uses it.
Collins-Sussman: Well, I mean, it's probably
on every Linux and every Mac laptop out there.
But nobody--It has zero usability but millions of users.
Fitzpatrick: So who cares?
Collins-Sussman: Zero usage.
Fitzpatrick: Right, right. Collins-Sussman: Absolutely.
Fitzpatrick: So the next part of focusing on users is sort of--
We're talking about laziness, okay?
Now, I personally admit I am incredibly lazy.
I would much rather write an application than write code.
So the least amount of code that I need to debug, maintain,
remember what the heck-- a document,
remember what it was about, the better.
But when it comes to designing your interface and stuff,
you really have to spend more time
so that your users can spend less time.
This is lazy. Collins-Sussman: [laughs]
[audience oohs]
Your favorite application.
Fitzpatrick: Your favorite application.
This is lazy. Collins-Sussman: Oh, yeah.
Fitzpatrick: Now I understand this came back from the days
when, you know, people didn't spend time
designing any sort of a command line interface,
but, you know, I can't remember a darn thing about tar
other than cfv and xfv, I mean, that's about it.
Collins-Sussman: Becomes a reflex.
Who knows what the other stuff does?
Fitzpatrick: You know, the--et cetera.
Mail a copy to Martha Stewart,
whatever, there's that command.
Collins-Sussman: Oh, I hate this.
This is one of those things. You know about the--
Fitzpatrick: This is a huge pet peeve of mine.
Collins-Sussman: Where you go to a Web site, and you're like--
Because, you know, it's so, so hard
to parse out spaces and dashes,
we wouldn't want to stress our programmers out.
Let's make the users do it instead. Great idea.
Fitzpatrick: Right, or even then you get the one
where you have to enter your phone number.
You type the first few letters it automatically advances you
to the next one, and you've hit Tab and go on to the next field.
Collins-Sussman: Yeah. Great.
Fitzpatrick: You make your users feel dumb,
and when people feel dumb they hate you, and then they go away.
Collins-Sussman: [sighs]
Fitzpatrick: But beyond just the usability stuff...
Collins-Sussman: Speed.
Fitzpatrick: Speed is really important.
Collins-Sussman: It's a huge impact on usability.
In fact it's one of those things that actually--
it affects usability in this sort of weird,
unconscious kind of way.
You may not realize how fast or slow
something is consciously,
but it actually affects your mood,
and it affects how you feel about a piece of software.
You know, if you've used--
Especially on mobile phone apps as an example,
certain applications will be super quick and responsive,
others you'll click a button
and you'll sort of wonder what's going on.
You may not register in your mind
that "I'm frustrated with it,"
but it does actually change your mood.
Fitzpatrick: And change your likelihood
to use something off the cuff.
So here's another graph that we spent minutes researching.
Collins-Sussman: Minutes.
Fitzpatrick: As time goes on, and you get more users,
sometimes people notice
that the number of users they have plateau.
And the marketing guys decide
at this point we need more sizzle.
Collins-Sussman: Clearly that's the problem.
Fitzpatrick: That's the solution.
It's a way to solve this.
But what it also turns out
is if you look a little more carefully,
because your users have grown, your application's slower,
you've maybe got some bad algorithms in there.
Collins-Sussman: You're not scaling.
Fitzpatrick: You're not scaling very well.
Your latency gets to a point
where your existing users use your application less,
and your new users either
come and go, which is very little,
and of course this all means
that despair increases exponentially.
Collins-Sussman: Very carefully measured.
Fitzpatrick: Carefully measured.
So here's an example to give you a little actual data here
with some math behind it,
which is that if you have a million users,
which I think would be great.
I don't think anybody here wouldn't want a million users.
Each one of them does 20 requests a day to your app.
Of course we're talking about some sort of network app here.
Each response is 500 milliseconds too long.
Over the course of an entire year,
you've wasted 116 years of peoples' time.
Collins-Sussman: Holy smokes.
Please stop killing your users.
Fitzpatrick: So it just is sort of a plea
to not kill your users.
So beyond latency, I'll talk a little bit about complexity,
which we've touched on earlier.
Collins-Sussman: Yeah, complexity is not
necessarily an evil thing.
Some problems really are complex.
But the thing you should be striving for is to sort of--
There is an art to dealing with complex problems
and yet taking that complexity and still making it accessible,
but not just dumping it in the user's face.
Fitzpatrick: Right, and you don't have to
dump it in the user's face,
and you don't have to dumb it down so that,
you know, anybody can "use it,"
you make things very weak and not very powerful.
Collins-Sussman: We have a nice counterexample.
Has anyone ever used Eudora email program?
Or maybe ten years ago?
Fitzpatrick: I used to use Eudora, sure.
Okay, we've got a couple of screenshots
of Eudora's preference panel.
Collins-Sussman: Big.
Fitzpatrick: And I'm gonna count through them really quickly.
Okay?
We have 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18--
Collins-Sussman: What is that?
Fitzpatrick: What is a "mood watch"?
Collins-Sussman: [laughs] [audience laughs]
Fitzpatrick: Why do I need a panel for a mood watch?
Okay, but there's more.
19, 20, 21, 22, 23, 24, 25, 26, 27.
27 separate panels to configure a mail client.
Collins-Sussman: Hmm. Email is a complex problem, right?
But you don't really need to throw that
all in the user's face like that.
It's absolutely insane.
What's a good example of hiding complexity?
I think probably everybody has one of these in their pocket.
Wow, is this a dated picture now? It probably is.
But think about how hard it is just designing an mp3 player.
Before the iPod came out,
there were a lot of different models out there,
and they all had millions of little buttons
and weird, little fonts on there.
It was kind of hard to use, and I think what Apple did--
the brilliant thing-- I mean, it's--
Clearly there's a lot of electronics.
There's a lot of complexity going on
just in terms of hardware.
But the thing they did was they took
this very difficult problem of managing your music,
and they took it off of this device,
and they put it onto a real computer.
Fitzpatrick: With a keyboard. With an actual keyboard.
Collins-Sussman: And they wrote this beautiful piece of software
to organize it and manage it.
And then all that complexity has shifted off to the computer,
where it's doable,
and then the device itself becomes incredibly simple.
It just becomes a very simple mirror
for playing back all the complexity
that you've already organized somewhere else.
Fitzpatrick: And this is still a very complex piece of software.
It treats your music as data.
You can rate things, you can do genres,
you can do smart playlists, all this stuff.
It's really quite impressive.
Another example of something that's incredibly complex
is Google Search.
If you really want to strip this down,
it's basically a text box and a couple of buttons and a logo.
Collins-Sussman: You don't really need the logo.
Fitzpatrick: You don't even need the "I'm Feeling Lucky" button.
Or the logo.
In fact, you can just hit Return
and get rid of the button entirely.
Collins-Sussman: [laughs]
Fitzpatrick: That is a window into a massive amount of data.
And it's not just dumbed down.
You can still use some very powerful
search operators on there if you want.
Collins-Sussman: If you're a power user
you can go learn all the fancy syntax.
Fitzpatrick: Right, but it's an illusion of simplicity.
Just typing whatever into that box 90% of the time
gets you where you want to go.
And this is sort of what it looks like behind the scenes.
Collins-Sussman: Piles of computers.
Fitzpatrick: But beyond that we want to talk
about another way of hiding this complexity.
Is abstractions.
Abstracting out some of this complexity
is a way for you to sort of hide, I guess,
some of the complexity while still giving users
the opportunity to do things.
The real problem with this
is that all abstractions are leaking.
Especially if you use the Web, you see this every day.
You hit a 404, you're in a Web browser.
What happened? Where am I?
Your plug-in isn't found.
Collins-Sussman: Yeah, I mean, think about it.
Even the most non-technical users, they see 404.
It's become part of sort of everyday speak
even though people don't know
where that comes from or what that means.
That's an abstraction leaking out to the user.
Which is not necessarily a bad thing.
Fitzpatrick: No.
Collins-Sussman: I guess what we're trying to advocate here
is that you don't need
to try and prevent all abstractions from leaking,
instead you should go and say, well, that's fine,
let's actually create a layer that people can build on.
Like an API layer,
or some way so people could get under the abstraction
and really do what they want to if you're a powerful--
if you're a programmer.
Fitzpatrick: Right, and so an example of that--
the Apache Web Server, years ago,
decided that people in some cases needed to do
more than just configure things through a little text file.
So they had a module interface
where you could hook into the request response
in any one of a bajillion different places.
But this gave people like you guys, like the engineers,
the ability to really do a lot with it.
And, you know, Google knows this too.
Collins-Sussman: Google Calendar, right?
I mean, everyone uses--
well, lots and lots of non-technical users
using Google Calendar, love it.
Given me all sorts of testimonials of my friends
about how it's changed their life.
And yet there's a great API for it too.
You can mix it, and match it, and embed it,
and all sorts of things.
Fitzpatrick: And we could go on and on.
I mean, this whole conference is about that.
This whole conference is about the fact
that there's these APIs to all our different products.
I mean, Lars this morning in the keynote--
Did you guys go to the keynote this morning?
You guys like Wave? Does that look pretty cool?
Collins-Sussman: Yeah. Fitzpatrick: Yeah?
Collins-Sussman: [laughs]
Jury's out.
Fitzpatrick: They're all clapped out from this morning, I think.
But they realize that it's being able to hack into things
like maps and whatnot, and access it through strong APIs
are what makes it really great, I think.
So we have a couple of stories to end up here?
Collins-Sussman: Well, yeah. [laughs]
Um, I think this is your story, but I mean actually we get--
I've had other people tell me this as well.
Is that, all right, Google's corporation's got
a lot of people, but a lot of people
don't actually realize that.
There's a lot of people out there who really--
they just think Google's part of their computer,
or they think it's part of their Web browser,
and I've actually met people who I'll say,
"Oh, I work for Google,"
and they're like, "Oh, I didn't know anybody worked there."
Fitzpatrick: Exactly, yeah.
My mother-in-law introduced me
to some 82-year-old friend of hers, and she said,
"This is my son-in-law, he works for Google,"
and she looks at her and looks at me like what am I doing here?
She said, "I didn't know anybody worked at the Google."
Collins-Sussman: Well, we've had the opposite, right?
Fitzpatrick: Right, well--
Collins-Sussman: This is my favorite so you tell this.
Fitzpatrick: One of our other friends out here
told his aunt that, you know,
everyone was going to Disneyland a couple years ago.
Collins-Sussman: All the Google employees.
Fitzpatrick: All the Google employees were
taking a couple days and we were gonna go to Disneyland.
And his aunt said, "Well, you can't do that."
He's like, "What do you mean I can't do that?"
She's like, "Well, who's gonna do my searches for me?"
Collins-Sussman: [laughs]
I sort of imagine, like, you know, switchboard operators.
Fitzpatrick: Right.
Somebody with the Yellow Pages looking things up.
But I mean, again this is the way people perceive things,
and the point of that is just to think about the fact
that the way that you perceive your software
from the inside looking out is very different
than people who aren't as technical, who aren't engineers,
perceive your software.
Collins-Sussman: So it's really--
it's not just about the code.
I mean, yes, we all have an inherent distrust of marketing,
and spin, and interacting with users.
It's something that sort of scares us as programmers.
But there's actually-- there is--
You are able to have a healthy relationship
with these facts, with these people on your team,
you just need to find that nice balance
where you are promising the right amount of thing,
they are promising the right amount of thing,
they're adding the appropriate amount of sizzle to your steak,
and you end up with something that's really, really usable.
Fitzpatrick: And you're listening to your users as well.
And that's all we have to say about that.
Thanks for coming.
[applause]
We do have a little time for Q & A.
If you have any questions
come up to the mic and ask them, please.
If you have any answers,
definitely come up to the mic and give us them.
Collins-Sussman: Great. Fitzpatrick: That's it? Anyone?
Oh, somebody's running up. Collins-Sussman: Somebody.
audience member: Hi.
Are there any standards that Google uses for processes
to kind of--to, I guess, review products,
how they're being used?
Are there, like, five steps
or something like that that they go through?
Collins-Sussman: I'm not sure I--
If there are any processes
to review how products are being used?
Oh, you mean like how do we evaluate usability?
audience member: Yeah.
Fitzpatrick: Like user experience?
Like research and stuff like that? User testing?
We do tons of that. Absolute tons of that.
I mean, everything you--
Sometimes if you're doing a Google search,
you'll see results come up differently, for example,
it looks a little different.
Collins-Sussman: Once in a blue moon.
Fitzpatrick: Once in a blue moon.
That means that, you know,
you just saw a test that we tried out.
Try and see if people behave differently
and how they behave.
So we definitely do a lot of that.
Collins-Sussman: We'll do experiments on people.
See how they change behavior.
That's an unwilling experiment in that case.
You might be a subject of experiment without realizing.
But we also do deliberate experiments too,
where we actually will have
user discussion groups, user focus groups,
or somebody will volunteer to use a product
and we'll watch them use the product
and study what they're doing,
and it's classic user experience stuff.
Fitzpatrick: Thank you. Next question.
audience member: Uh, are people who--
or kids who are grown up
with phones and computers from very young ages--
How is this gonna change
the way users see and use software,
and how is this gonna change
over the next 20 or 30 years
as everyone starts to know how to use a computer from--
they're two years old or whatever?
Fitzpatrick: Well, I think the bell curve--
The competency level is just gonna continue shifting
as more people are used to having
these sort of technical devices around,
and that sort of thing.
Collins-Sussman: I guess I don't feel like
it's a big paradigm shift.
I mean, when I was a kid
there were hardly any computers at all.
But yet, you know, everyone in my generation,
my parents' generation, grew up with other forms of technology
that they did not understand.
How many people understand their television sets,
or the electricity or the heating system in their house?
I mean, none of us can go
be dropped in a field and survive anymore.
We've all lost that ability to some degree.
We're all dependent on technology to some degree.
So to me, computers and cell phones just feel like
just yet another piece of magic in our lives,
just like everything else that we use to sustain ourselves.
Just one more thing.
Fitzpatrick: I agree and I disagree a little bit.
I mean, I agree that people
don't understand the internals of something,
but I think they're gonna be much more capable
of dealing with more complex technological things.
I think we see that as--
And I think that's more of what your question was,
if I understood.
Collins-Sussman: And more OCD.
Fitzpatrick: Yeah, and a little more OCD.
And you're gonna see people talking to each other less
and just texting each other more, something to that effect.
The social implications are interesting, I think.
It brings people together, to some extent,
and maybe brings them apart, we don't know.
Yes.
audience member: Yes, I wonder how both of you think
about designing software for the way users currently think
versus taking them into a new model of doing things.
And one example that jumps to mind was Gmail.
How there was no Delete button at first,
and we're trying to push them towards a totally new model
and then eventually caving and adding the Delete button.
Fitzpatrick: I personally agree with the Delete button.
Even though I rarely use it, it's nice to know--
It's like an emergency exit, you know.
I don't want to have to use it,
but it's nice to know it's there.
Collins-Sussman: I think there's a tightrope you need to walk.
I mean, if you have a new, radical way
of working with software,
I don't think it will get a lot of uptake
if it's completely alien.
I think you need to find some balance
between somewhat familiar, and then users are willing
to tolerate a little bit of the unfamiliar
if they see an obvious gain in productivity or something.
And I think Gmail is an example of that.
It's like, okay, it's a familiar.
I've used email before.
But a lot of friends of mine who started using Gmail
weren't used to seeing conversations grouped together,
and that was a little bit of a shock,
but it was not so much that they ran away screaming.
And now, you know, months later,
I can't remember living without it.
Fitzpatrick: Right. But there's huge advantages.
I mean, you still have to offer a net gain to your users
if you're gonna have something new like that.
Gmail's first offer was a gigabyte of storage space,
which was two orders of magnitude
more than anybody got at the time.
And people really thought it was an April Fool's joke
five years ago when they announced that.
'Cause it was--I did.
Collins-Sussman: Announced on April 1st.
Fitzpatrick: I was like, come on. This is crazy.
Who could do that?
audience member: So I work at GrayShark.com, right,
and we have a very healthy rivalry
between everybody in engineering that thinks
that we should test 8,000 shades of gray,
and our designers that say, "Hey, this is the right one."
Everybody in engineering points to the fact
that Google tests things a lot.
Everybody in design points to the fact
that one of the famous Google UI designers quit,
and her famous thing was, "It took months to do anything
'cause we had to test 8,000 shades of gray."
So the question is, you know, from your experiences,
where do you draw the line?
You know, where do you really find kind of the best compromise
between testing a bajillion shades of gray
and then just actually implementing one
that you know will work?
Without, like--
so when you're going forward and you're building features,
There's, you know, the continuum
of testing every version of every possible thing,
or there's just doing it the way you envision it
and the way that you think will work.
How do you balance that?
Do you have any suggestions there?
Collins-Sussman: It's an interesting tension.
Fitzpatrick: Yeah, I think it is an interesting tension,
and I probably have a little different view
than a lot of people on that.
So anybody here familiar with EveryBlock.com
or ChicagoCrime.org?
EveryBlock.com is an amazing site,
especially if you live in one of the cities it covers.
But Adrian Holovaty, who started it, is a friend of mine,
and I was talking to him, like,
"Why does, like, the Jango Web site look so beautiful?
Why does ChicagoCrime look so beautiful?"
I'm like, "You're not a designer.
"I know you're not a designer.
You're a journalist and an engineer."
And he said,
"It's because I have a UX designer who I really trust,
and I can leave him to make all the decisions for that."
User experience and user design, I think,
Is actually incredibly sophisticated,
but it's a thing that most engineers--
myself too, at some point--
think that they can just understand.
Same for PR.
I think most engineers are like, "Oh, this is a soft skill,
I could figure this out," when you really can't.
And you don't have as much of a respect for, I think,
other peoples' abilities in that.
So I personally believe that most of the time
if you can find someone who you trust,
and let them sort of make that decision...
If there's not a lot of trust between those two,
I would say you might have some issues,
especially if you don't respect what they're doing or saying.
Collins-Sussman: I think that the tension you're pointing out
is between art and science.
There's an art to it, and there's a science to it.
Some people have good taste, some people have terrible taste.
Fitzpatrick: That's subjective. We always have good taste.
Collins-Sussman: Always. Right.
Everyone else always has bad taste.
But I guess my feeling about it is you need to find people
with good taste to get you, you know, 80% of the way there.
And maybe they'll make sort of the artful decisions
that are more emotional, less rational,
to sort of decide maybe the overall look and feel,
or what features are exposed or whatnot,
and then that last 20%
can sort of go into the realm of scientific testing.
Like, what color should this be?
Exactly how wide should this part be?
And maybe there really are measurable usability metrics
that come from that scientific bit.
So there is a tension, but I think they can cooperate.
If you-- if you do it right.
It's not all one or the other.
Fitzpatrick: And I still think
that there's opportunity for testing.
In the engineering side,
you can make it easy to do experiments
or that sort of thing,
especially if you're dealing with network apps
and not something you have to, you know,
buy a CD and download it.
Those days are thankfully going away, I think.
But again, there is a balance there,
but I think it really requires
some sort of trust and respect
of the folks on the other side of the fence.
Just like it requires trust and respect for your users.
That they're staying--
What they want--What a majority of them say they want
is something that's good to add to your product.
Collins-Sussman: UI is a really hard field.
Fitzpatrick: It really is.
And engineers beat the heck out of UI people.
Collins-Sussman: Anyone who may not be a programmer
must not be very skilled.
There's sort of this weird bias in the industry.
Fitzpatrick: What are the different things
that engineers think they can do?
UI design, PR, legal stuff. All these different things.
Just read things they had compiled into a head, right?
Rarely is it the case.
Next question.
audience member: So as a person that actually
does a little bit of everything--
engineering, UI design, everything--
I can say that actually UI design is pretty difficult.
Something that I'm still having
a hard time getting a good grasp of it.
One of the challenges that we're having is that
I mean, what's a preferred method of educating your users?
So you do have a piece of technology
that you can do fantastic stuff with it,
but you need to get users to use it the right way.
There needs to be a little bit of education.
I know it goes counterintuitive--
So you have to make it simple enough
that everyone can just get it right off the bat.
What if there are--
Like, for some of the mail application
you guys showed from Eudora,
that was an overkill,
but what if there is some essential steps
that they really have to take?
In your experience, what's the best recommendation to do that?
Is it videos, images, step--making--
splicing it up so people go into chunks?
Fitzpatrick: I'd probably start
with user testing, quite frankly.
'Cause I think once you--
If you get something and you put someone in front of it
who's not a super tech-savvy person,
who's unfamiliar with it,
and look at what they do first.
Look at what confuses them, look at where they get lost.
I think that's a very telling kind of thing.
Beyond that, certainly documentation,
you know, fun videos.
I mean, remember years ago Rails did that video
of how easy it was to build an app.
And that was a huge win for those guys.
You know, 'cause it was a couple minutes long,
and you could see how easy it was
to build their sort of demo app.
Collins-Sussman: The things that I've seen actually not work well
is when a company puts all their eggs into either--
People learn sort of bottom up or top down.
And some people want the overview, they want the video,
they want to read the manual.
And some people just want to jump in
and play with it and figure it out as they go.
And there are different techniques
for teaching both ways,
and one of the things I see companies don't do
is they choose just one technique.
Like, maybe they'll have an online help system
that's just for bottom-up users,
but there won't be an overview anywhere.
Or maybe they'll do a video that has a general overview
of how the system works and how cool it is,
but then there won't be any bottom-up learning.
No, you know, help system
that's sort of contact sensitive or anything like that.
So I think you need to think about both kinds of users.
That's my pet peeve.
audience member: And also, can you guys--
Are you guys familiar with the process that Google--
that the iPhone team had to go through
in order to make the Google mobile app?
Fitzpatrick: Um, no I'm not. Collins-Sussman: No idea.
Fitzpatrick: Got about it online if you know, maybe.
audience member: Thank you.
Fitzpatrick: They go to Steve and yells at him or something?
Collins-Sussman: Well, should we call?
Fitzpatrick: I think we're gonna--
We'll be up here for a few minutes
and then we'll step outside,
but if you have anything else you want to chat with us about,
please stop by.
Thanks again for coming. Collins-Sussman: Thank you.
[applause]