Abstract: It’s not about you, not about your product, it’s about how awesome you make your users. If you sell digital cameras, make your users better photographers, through a better camera yes, but also teach them about exposure, light, etc.

(If the embed is broken, see Kathy Sierra at Business of Software)

Here are my notes:

Make the user awesome.

You want them to talk about the amazing thing they did (with your tool).

Your product is part of a higher purpose (digital cameras -> photography). Don’t talk about your product, instead blog / tweet / evangelize the higher purpose.

Make the user better. Teach.

Sense of belonging. Do people want to wear T-shirts with your logo? What does being your user SAY about your user? It shouldn’t say something bad, and it shouldn’t say nothing.

Get them interested

Trigger an emotional reaction (faces, sex, cute, fear, story) so people pay attention.

Talk in conversations, not formal language. Stories trump data.

Contrast your marketing material, with your user manual. Take care of people after they buy, so they stay excited.

Give super-powers

Instead of Word Of Mouth, which requires people telling other people, use Word Of Obvious, where they show other people what they did, or other people see it, it’s obvious that person is awesome now that they use your product.

Flip business advice:

• Exceptional customer service -> exceptional customers.
• ‘From good to great’ -> great customers.

Make your customers into the perfect customers you wish you had.

What super-powers do you give your customers? Help them get really really good at something.

Don’t build a better [x], build a better [user of x]. Say: We help [type of person] get better at [thing].

Wrong: What problem do you solve? What value to you add?
Right: What does having the solution mean to our users? What bigger, cooler thing is enabled?

Make it a rule that with your product, the user must do something cool within [x] minutes. Make a document listing 10 awesome things they can do, quickly, with your product, and how.

Help users justify acquiring your product to others. They are already sold, help them sell others.

Make good things easy / natural / obvious

Motivate / Inspire users. Motivate users to do things they wish they already did.

Peter Bregman, harvard business.org, on the easiest way to change behavior:

Right things should be easiest, most natural. Make doing the wrong thing very difficult. Usability matters.

Help your users practice

Make your users smarter. Shrink the 10,000 hours they need to become experts. Give users patterns they can learn. Experts are better at identifying patterns in the problem domain (the thing you are making your users super-heros at). Make their practice fun.

After 1 or 2 years, experience is a poor predictor of performance / expertise. Was it 10 years, or 1 year repeated 10 times?

Offer exercises, games, contests, tutorials that support deliberate practice of the right things. The things that make people awesome.

Those exercises etc should use cognitive pleasures to keep users interested and practicing. Game designers have identified a bunch:

• Thrill
• Discovery
• Challenge
• Self-expression
• Social
• Novelty
• Sensory.

The more deliberate practice [pdf] your users get, the better they get, so the more they enjoy using your product. And the more chance other people have of seeing them practice, so more Word Of Obvious.

Talk with users at their angriest

Add a “WTF?” button.

Help / FAQ are usually written for people who are intellectually curious, wanting to learn more. The “WTF?” button is for angry upset people who hate your product right now. Different feeling, different audience.

How you make users feel about themselves, drives how they feel about YOU.

If you want them to RTFM, make a better FM.

Where do you fit on their Hero’s Journey (also here and full detail here). What part do you play? Are you the helpful sidekick? The ogre guarding the bridge? Something else?

Community management

Model good behavior in your community.

Make a short document for moderators / active users telling them how to answer ‘dumb questions’, in a nice way. Provide alternative answers to guide them away from RTFM or “just google it”.

Encourage a culture of “there are no dumb answers”. Newbies are often the best people to answer other newbie’s questions, yet on most forums people don’t feel ready to answer until they are experts. Encourage early participation.

Don’t force inclusivity, don’t force your expert users to hang out and nurture the newbies. Hanging out with other experts is a lot more interesting. Give them a special space, where they can use jargon. Django, like many projects, has two mailing lists: django-users (beginners, normal folk), and django-developers (experts).

Evolution of awesome:

1. Awesome product (features)
2. Awesome people talking about the product (expert / influencer testimonials)
3. User testimonials (”I love this company”)
4. User benefits (”Look at what I did”)
5. I know Kung-Fu

Summary

In the words of Jamie Zawinski:

So I said, narrow the focus. Your “use case” should be, there’s a 22 year old college student living in the dorms. How will this software get him laid?

Your job is to make people better. Your tool is software.

My talk will be entitled How and Why to Extend Firefox in Javascript (and Thunderbird, Komodo, and Songbird). I will post the slides here in June.

See you there!

A richer graphical interface

This is mostly done today by using Javascript. This is a good approach to start with, but your Javascript can quickly get quite hairy, and there are certain things you simply can’t do, such as interactive graphs, flexible typography, or socket connections (which matters in the next section). If you do use Javascript, I recommend the Yahoo User Interface Library.

For a richer environment that is easier to work with, and if you create a graphically rich web application in Javascript you will yearn for both, Flex is the way to go. It is a free (as in beer, unfortunately not yet as in speech) SDK by Adobe that allows you to write graphically rich and responsive applications that run in the Flash player. Flex already has a lot of traction, see O’Reilly books sales for 2007. Bruce Eckel was so impressed with Flex that he went to work for Adobe (as a consultant).

If you can accept targeting your application only at Firefox, for example for an in-house app, then an alternative is to build it as a Firefox extension.

Real-time data

AJAX has given us more responsive web applications, by allowing them to fetch data from a server programmatically. This is what gmail does to check if you have new e-mail. AJAX, or more correctly the browser XmlHttpRequest object, solves the problem of a client fetching data from the server., but it does not allow a server to tell a client that there is new data to fetch. Currently most servers will just check at regular intervals. There are currently two ways to allow the server to push data to the client.

You can trick the browser into keeping your HTTP connection connected, and receive data this way. There are many very nasty ways of doing this, collectively known as Comet.

Or, you can allow your web application to chat, using IM, with your server, or with anything else on the XMPP network. This is a fantastic way of making your app ‘connected’, receiving live data about anything you care to send it. Other people are saying this better than me, such as Matt Tucker here – a less technical summary is here.

There is an XMPP library for Flex, called XIFF. I’ve blogged some documentation about using XIFF.

Applications that just happen to come from the web

So, what can a desktop client do that a browser originated one can’t?

• Drag and drop from the OS, for example to upload a file, is still difficult. In Firefox the dragdropupload plugin makes this easy. In IE there are some ActiveX’s. For a cross-browser solution you have to turn to Java, see here drag drop file uploading in Java. I wish Flex / Flash did this.

• Desktop integration, such as minimizing your application to the taskbar. If you need strong desktop integration, you could use Mozilla’s Prism, or write an Adobe AIR application. In most cases launching your app from a button in the browser toolbar instead of from the OS menu doesn’t make a difference to the user.

• Work offline. If a user is offline, they aren’t getting their e-mail, can’t get to their network shares. They will be quite unhappy. The fact they can’t access your application will likely be far down their upset list, so for most applications this doesn’t matter much. For those apps where it does matter, there is Google Gears which is wrapped by the Dojo offline toolkit. Firefox 3 also has offline support.

Let’s be sensible now

I am not suggesting you build your whole application in Flex, or that HTTP be replaced by XMPP. That would be ridiculous. What I am saying is that if you add these to XHTML, CSS and Javascript, you get a much better web application, which allows an even greater proportion of the world’s software to be web based, with all the advantages that that entails.

Yesterday: cgi-bin/submit.pl. Tomorrow: the world.

An API takes a good thing and makes it better. API must not change.

API allows external extension of your application. A plugin architecture allows internal extension.

The 10 reasons are:

• Increase brand awareness
• Allow users to own their data
• Build goodwill with developers
• A perfect excuse for a community
• Solving programming problems with an API in mind can improve code quality
• Simplify internal reuse of data
• Allow others to extend the functionality of your application
• Alternate input mechanisms
• Unanticipated applications of your data

• Turn your program into a platform

  The initial Mint release only supported Firefox and Safari (not IE), to cut down on the support calls by only having technical users.

  See also Larsz’s mind map.

Tom Coates used to work for the BBC, and has recently joined Yahoo. He has worked with Simon Willson. Tom had a highly polished presentation. Here are the notes:

• We are moving from web pages connected by links to data connected by APIs.

• The Web 2.0 design aesthetic can be summed up as: Rounded corners and gradient fills.

• The future according to Tom: A web of data sources, services for exploring and manipulating data, and ways that users can connect them together.

• Mash-up: A network effect of services. Web as a platform. Hybridization of web services together makes both of them better.

• APIs drive people to your site, allow people to enhance your site. You don’t have to do all the work yourself. People might start charging for the user of their APIs.

• “What can I build that will make the whole web better ?” The Aggregate Web. It’s all about data – owning, exploring, manipulating.

• Build for normal users (the HTML interface), for developers (the API), and for machines (XML, predictable and consistent URLs and structure)

• Start designing with data, not pages. Navigable, re-usable, explorable data.
• Identify core objects that people will refer to. For the BBC, that’s programs, films, events, people. Then make each core object addressable by URL.
• Good URLs: permanent, readable, and have a 1 to 1 correlation with concepts. Use directories to represent hierarchy. Predictable, guessable, hackable. Reflect structure of data. Only 1 URL for a piece of data. For example the BBC needs to have one and only one URL for a single program. That way all entries on the web will connect to that one URL, and will be connected themselves.

• Correlate with external identifier schemes (such as ISBN)in your URLs, or coin a standard if there isn’t one. If 100 people are blogging about a film, they need to be connected somehow – if they all link to the same BBC or IMDB page, they will be connected.

• Build list views and batch manipulation interfaces. Types of page:

  • Destination page (the entry of a film). Make XML versions of these.
  • List page (search results, lots of films). Make RSS versions of these.
  • Manipulation page (comment on a film). If needed, use AJAX / Flash here.

• Make sure your AJAX / Flash doesn’t break your URLs. Keep it in the page. Only manipulate the concept of that page.

• Use standard formats where possible. See microformats.org.

• Make your data as discoverable as possible.

  That’s the end of my notes ! See also a good mind map of this talk

Lars Ploughman posted a great mind map of the talk.

Collaboration

• Try and figure out what people need; this is not always what they say they need.
• Network effect: When people get their friends to sign up, it makes their experience better.

Aggregation

• Instead of always grouping data by user, we can slice it in other interesting ways:
  • Most recently uploaded
  • Most popular
  • By tag
  • By weighted ‘interestingness’ algorithm

Open APIs

By API the Web 2.0 people mean a web service API: REST, SOAP, XML RPC, etc. You need an API to for your web client anyway, so clean it up and make it public.

The evolution is: web site -> web application -> web service

Clean URLs

Don’t expose internals or physical structure on the URL. They should reflect a consistent, logical structure, the way the user thinks about it. mod_rewrite enables this. URLs should never change, otherwise you break links.

AJAX

It’s Asynchronous. It streamlines user interactions.

Unicode

Internationalisation and Localisation. Store, present and receive all textual data as UTF-8.

Desktop / Platform integration

Backed by the API. With an API for your app, you can write desktop apps. Some interactions on the web are difficult and/or slow (such as uploading lots of pictures). Desktop apps can have drag and drop for example.

It doesn’t have to be a full fledged desktop app – use Bookmarklets, Firefox plugins, etc.

Integrate with e-mail; every user has it and uses it daily. It’s often difficult to get data off mobile phones, but they can do e-mail, so provide an e-mail uploader. Send e-mail notifications.

Mobile phones

They mostly support XHTML-Mobile, a cut down version of XHTML. Build custom pages for mobiles because the screens are so small. Re-think what is on the page. Cut down as much as possible.

Open data

Allow users to import / export their data. Include the meta-data as well. This makes people feel safer about using your service.

Open content

When a user uploads something, they still own it. They still control the licensing.

http://www.flickr.com

Lars Ploughman posted a great mind map of the talk.

• del.icio.us started as a text file of 25 000+ links on Joshua’s computer. Each one had a descriptive sentence, that got shortened down to a single word -> a tag. When building an application, it must solve a problem you have. You need passion.

• Cross browser compatibility is difficult

• Monitor your app.
• Optimize: Add database indexes. Cache. Monitor user behaviour to find out what they do. This allows you to optimize certain parts – for example no-one ever goes to search results page 100. Figure out where latency is acceptable and use that; for example the RSS feed can be a few minutes behind the live site.
• Aggregation of attention is interesting: What are people looking at, etc. Top 10.
• Your application will be used in unexpected ways, so react to it. Monitoring helps.
• Learn the ins and outs of Apache, including mod_rewrite.

• Put a proxy in front of Apache – for example pound or perbal.

• Build an API, and make sure it is easy to use. Avoid SOAP, CORBA, etc. Stick to simple XML. The API should allow uses to save their data offline, to script your application, etc.

• Don’t expose internal ids, especially if they are consecutive. Otherwise people will try and iterate over them to get all your data, and overload your site.
• Don’t add features that already exist elsewhere. For example your site doesn’t need a messaging system – use e-mail instead.
• Add features that people will use; this is not always what they ask for. Get to the root of each feature request – what exactly is the user trying to do, and is there a better way of doing that than what they asked for.
• RSS is the web’s native style for a list of links. Put RSS everywhere you have a list. It’s another way for users to get data from your system. del.icio.us has more RSS than HTML traffic.
• Sensible URLs: They get passed around, bookmarked, mailed, etc. They should be user-friendly, not developer friendly. Don’t include session ids, or implementation specific details on the URL.

• Release early and often. No closed beta.

• When you block spammers, don’t let them know. Don’t display an error message, or change visible behaviour. Otherwise they start trying different methods.

• Understand user motivation. The application has to be useful for user number 1. Users are selfish. Ideally people use the system and evangelise it. They come for themselves not for the data others created.
• Measure how people react to new features and how long they keep using a feature. Rely on what people do not on what they claim.
• Do user acceptance testing. Everyone involved in the project should watch this. If you can’t afford a test lab (with a two-way mirror for the team to stand behind), do ghetto testing: Buy people coffee in the local Internet cafe and show them the application. Don’t give them goals, just let them be normal users.
• Speak the users language: Only Netscape / Firefox users call them bookmarks – IE users call them favorites.
• Don’t force users to register. Or if you really need to, delay it as long as possible. Give as many public features as possible. Make registration short and afterwards send them back to where they were.
• Understand the Internet design grammar and choose when to follow it and when not to. For example clicking the logo in top left corner goes back to the home page.
• Remember that the data is not yours, it belongs to the user, and you’re just borrowing it. Allow users to export their data, delete themselves completely from the system, etc. Having an API helps with this.
• The clients to your web app aren’t just browsers. Think of everything that can take data from your server: RSS readers, iCal clients, Excel, widgets (Konfabulator and Dashboard) etc.

• Build a tool, not a community. Unless you are explicitly trying to build a community.

  http://del.icio.us