The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Program tips as RSS feed?

How do you get users to try new features, to do things a better way?

Some programs offer tip dialogs at startup. But when you started a program, you have a goal in mind so aren't in the mood to read tips. So that dialog gets cancelled without being read.

I suppose you could show a tips dialog when you exit a program, but again at that point you are on to something else and don't want to read tips.

You can interrupt the user with a dialog that says "Here is a better way ... " but that interrupts the flow.

Here is an alternative. As the program runs, it creates a RSS file with tips about ways the user could have used the program differently or better. The user can read the tips in a blog reader, at a time when he or she is in the mood to browse and read.

Our software is for scientists, and the whole rss-blog revolution hasn't penetrated the scientific community at all. If I told our users that Prism now creates a RSS feed with tips, they wouldn't have a clue what I'm talking about. But in other fields, and especially developer tools, the users know about and use RSS readers,  so this approach might be worth trying.
Harvey Motulsky Send private email
Wednesday, November 03, 2004
NewsGator does this. When you sign up, it subscribes you to a tips feed. That feed then returns one new item a day (it has a key to the signup day or something in the URL).

Of course, it is an aggregator, but still....
mb Send private email
Wednesday, November 03, 2004
I sort of despair of the idea of tips-of-the-day. Not because "users are dummies" but because of how many other problems users have to deal with in their lives.

Example: yesterday I needed to reduce the volume of a WAV sound file by about 1/2 a dB. Doesn't matter why. It took me about 12 seconds to find a GNU sound editing program on sourceforge, about 4 minutes to download it, and about 1/2 a minute to figure out how to reduce the volume on the WAV.

I don't even remember the NAME of the program I used. I'm sure it had many glorious features. I'm sure the programmers were very thoughtful and were concerned that I learn about all the glorious features. I'm sure if I were a musician or a sound technician or something, I'd read the manual, study the UI, post questions on newsgroups, go to the training course, read the source, post the patches.

But I'm not, and I didn't, and it doesn't matter, because all I had to do was reduce the volume of a single WAV file once, quickly, and the software in question accomplished that task brilliantly.

Program tips assume that users want to learn more about the features of the software. They don't. They have jobs they want to accomplish. The reason program tips are annoying is not that they are done badly, its that they are done at all.

The reason tips exist at all is mostly because Tucows won't give you lots of cows if you don't have them, so millions of shareware authors implemented them so they would get the cows, until they became a standard (the tips, not the cows). It's not because they're such a great idea.
Joel Spolsky Send private email
Thursday, November 04, 2004
I second what Joel said. Tips are useless. The time spent implementing and writing them would be better spent making the manual more useful. There are tons of software where the manual is crap, and you end up reading the tips simply because they might contain the information you hoped to find in the manual.

My point is, most of the time you just want to get a job done. If you really want to learn more, a good manual is thousand times more useful than tips. If you think your manual is too intimidating, you probably don't need tips; you need better manual instead, maybe including (but not limited to) a tutorial.
Thursday, November 04, 2004
I'll third Joel. "Getting users to try new things" as the OP said is the wrong attitude -- it regards users as servants to the program, rather than the other way round.

Usage tips, including info on unusual features, should go in the regular online help (and manual if you have one). Maybe write a separate how-to section that outlines frequent tasks.

If you truly have lots of unusual features you could also give an overview in a separate "Unusual Features" section. Then users can look them up if they actually do want to know about them.
Chris Nahr Send private email
Thursday, November 04, 2004
To clarify: I'm actually nerdy enought that I *want* to know if and how your software does something special. But even so, I *don't* want it forced down my throat via obnoxious tips when I'm trying to get a simple task done.
Chris Nahr Send private email
Thursday, November 04, 2004
I think the problem with tips as part of the help is that nobody reads the help, except possibly as a last resort. Now if you had all your tips and tricks bundled into one categorised list and a reasonably prominent button labelled 'Tips and Tricks', then people might actually go there and learn something. My experience is that nobody likes help, but they do like tips and they really like tricks.
Ron Porter Send private email
Thursday, November 04, 2004
No-one likes or reads tips-of-the-day, but I'm not sure that's the point. The OP says:

"As the program runs, it creates a RSS file with tips about ways the user could have used the program differently or better."

This isn't tip-of-the-day, because:

a) it's not in the user's face
b) the tips are designed to be context-sensitive - the user should get tips that actually relate to what the user has been doing and what the user wants to do

My understanding of the OP's target market is that they're users that are regularly using the software and receive periodic updates to the product. They use the software for a specific purpose, and they have done so for some time. When they get a new version, they keep doing things the same way. They don't read the Help, because they don't need to, and they don't read releasenotes, because no-one does.

The problem, therefore, is: if a feature is added to the product that can cut the old 4 step process down into 1 easy step, how do you let the users know? After all, the reason you've added that feature is to improve the product for them.

I know we suffer from this problem. I've lost count of (ok, I just haven't counted) the times that my clients say 'oh, I didn't know it could do that'.
Thursday, November 04, 2004
The previous poster defines the problem. I don't want to give prepackaged tips which may be about things the user doesn't want to do. And I certainly wouldn't want to give tips to someone who is just using the program once for one small project. But many of our users use Prism as their main tool to analyze, organize and graph their lab data so use the program many hours a week. They just do things inefficiently because they haven't discovered some feature -- sometimes one new to this release, sometimes one that has been there for ten years. A little nudge would help -- the question is when and how to give that nudge...

I'd say about half of the suggestions I get for new features are for things already in the program. So even people motivated enough to write in a suggestion are missing much of the program.
Harvey Motulsky Send private email
Thursday, November 04, 2004
The problem is that the only tip that's actually useful is one that is relevant to what's currently being worked on, not something that the user doesn't already know about, and not obnoxious.

I think the problem is that even the best in AI and human factors research hasn't come up with a good way to do it.

Thusly, all of the ways to "make things easier by offering tips" are obnoxious.

I think that an RSS feed, especially one that's not installed behind your back, wouldn't hurt because it's not in the user's face.  But it might not help.
Flamebait Sr.
Thursday, November 04, 2004
"In any application, the number of tips-of-the-day is inversely related to the number of truly useful items in the help file." Discuss.
Thursday, November 04, 2004
Context-sensitive tips have already (to a certain extent) been done - generating tips based on what the user is doing at the time.

Unfortunately, there are very few ways of easily directing the user to them, without annoying them. The 2 extremes are the 'tip of the day' format, and the tips that are generated more-or-less outside of the application (like an RSS feed that needs an aggregator to read it). One of the previous posters said that once the user has started up an application, they already know what they want to do. Unless by sheer chance the tip tells them EXACTLY what to do to acheive this task quicker, then it just gets closed. Fair enough.

But where's the middle ground? The closest thing I can think of (i.e. not too obtrusive, context sensitive, integrated into the application environment) was (I hate to say it) Clippy.

'It looks like you're writing a letter'

Yes, I hate it too. Yes, it's the first thing that gets disabled whenever I repave my machine, but it seems to sit right in the middle between the 2 extreme ends.

Maybe it might be worth thinking a bit higher-level and working on the wider issue of how to get users to use their tools more effectively.

Just a thought.
Ben Savage Send private email
Friday, November 05, 2004
A question for Joel: how come tips of the day ended up in Microsoft Office? I'm thinking back to version 4.x of the suite.
John Topley Send private email
Friday, November 05, 2004
Maybe I didn't got the point in this discussion, but I wonder what "how to get users to use their tools more effectively" really means.

If there are two different ways of doing the same thing and one is efficient, while the other isn't, I simply would blame this to be a design mistake. And rethinking the user interface will be the thing to do.

Or are we just talking about "use the keyboard, not the mouse"-issues and the "wizards are not sufficient for advanced users"-problem?
Gerd Riesselmann
Friday, November 05, 2004
Gerd - I was thining somewhere between the two (one way's more efficient than another AND use the keyboard rather than the mouse).

Picture the scene. Your software has performed a certain function (say, for example a mailmerge) since version 1.0. You're now on version 4.2.

Since version 1.0, you've refined your mailmerge function so that rather than perform 7 steps, you've reduced it to 2, with the proviso that you use one of a few common data sources. The rest is dealt with by the application. If you've kept the original dialogs etc. in your app to maintain consistency and to allow the same funcitionality for a wider range of data sources, and just supplemented them with a new method (could be a wizard, could as easily not be...) the how do you alert your users that you've refined your app to the point of being able to do the same thing in 2 steps rather than 7?

That was the example I had in my head at the time, anyway...
Friday, November 05, 2004
Well, out of the blue, I would do the following:

1. Estimate, what will be done more often: Merging one data source or merging several.
2. If merging one data source is done rarely, I won't implement a special UI for it.
3. If, however, merging one data source is the main usage, I would make this dialog the default (replacing the old one) and offer the user a button "Merge more then one source", which brings up the old dialog.
4. If merging from one source is done frequently but not in the most cases, just give your old dialog a button to switch to this UI.
5. You can also think about integrating both dialogs in one (This is easy for wizards)

You should not worry about "maintain consistency" by just keeping older dialogs untouched. If the new functionality saves the users a lot of work, they will appreciate it.

Some more general thoughs: Remember that users have tasks in mind, and the task is "Merge Mail", so they will look for and choose an menu item called "Merge Mail" in nearly all cases, independend from how many sources they have. And your UI should be consistent with users minds, so you should offer them a menu item "Merge Mail".

For this reasons, if you have e.g. two menu items, one called "Merge Mail" and the other called "Merge Mail from One Source", user will choose "Merge Mail" in nearly all cases, and there's nothing you can do about. So just surrender and give them what they want ;-).
Gerd Riesselmann
Saturday, November 06, 2004
Ah, I forgot. About keyboard usage: Advanced users will find out about that sooner or later. It is explained frequently in the non-geek-computer magazines they usually read because of all the tipps and tricks and the CD full off more or less useless but free applications that ships with it.

So don't bother. Just make sure that all your menu item display they shortcuts correctly and all your buttons, checkboxes, labels, and whatever have an access key - and that tab order is correct.

I wonder, by the way, who at Microsoft had the idea to hide the access keys by default in Windows 2000 and higher? Seems a very stupid idea to me.
Gerd Riesselmann
Saturday, November 06, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz