Should I revive Clippy ? aka how can i provide user-friendly tips and help in a desktop application? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this questionWhile I've been working hard to keep the WinForms application I'm working on simple and easy to learn, the functional domain I'm working in (finance) is pretty rich, and I feel I should help the user figure out what to do next once the program is launched.
I must add that in the software I'm working on, there's often "something to do next" (ie validating something, answering a message, etc.)
I've been thinking on this quite a lot in the last days, and I feel a lot of things have already been tried in that field :
Clippy (R.I.P.).
The ? button on the upper right corner (a.k.a. "what's this" button), which users have learned to ignore as clicking on "retro-transponder amplitude" with ? will probably bring a helpful "the retro-transponder amplitude" tooltip, which is not worth the mouse trip to the upper right corner.
There are a few variations to the ? button, including a contextual help zone in the status bar (which refers to the thing the mouse currently hovers), which solve the problem of having to click on "?", but still don't let the user grasp a whole interface at a glance. Edit : Joe's suggestion of a contextual help window is another example of this.
Help files are helpful (provided they're well written), but they lack the "immediate feedback" thing - precisely the problem Clippy was trying to address
"Tip of t开发者_JS百科he day" are usually shot on sight (usually so fast than some users don't even have the time to spot the "Show tip of the day at start-up" ticked checkbox)
Something I'm considering is using an overlay help screen, ie hitting "F1" would popup a lot of overlay tooltips on the screen explaining what everything does, with possibly a red tooltip (instead of yellow) for the recommended next action. Releasing F1 (or possibly hitting it another time) would hide all the help clutter
This would address the problems with the four approach I mentioned :
help is only popup on demand (vs clippy)
you don't have to click ? then every single label on the screen (vs ? button)
you don't have to spend time searching the relevant information in the help file. The documentation is right at your fingertips (vs .chm help file)
useful tips are displayed at a relevant time (ie you get tips regarding dialog foo when it's displayed, not at program startup - a time when you probably have no idea what the foo dialog looks like)
As this already been tried in some software? Do you think it's a good idea? do you have other ideas in mind to address my problem ?
Disclaimer : please don't answer "you should address your real problem, which is that you UI is too complex". Please assume everything has been done to keep the UI simple.
Think of an airliner cockpit. Ton of effort has gone into the UI, but it's still extremely complex. Now imagine ordinary users should be able to use it : how would you address the issue? That's exactly my problem.
Ableton Live (A music program) has a square window a couple of inches across at the bottom that describes whatever the mouse is hovering over. It's enabled by default and can be minimised but it's only ever a click away. I found it useful when first using the software. Whilst I minimised it within 5 minutes, it helped to explain certain slightly obscure functions and alert me to those functions that weren't easily discoverable. And I always knew where to click to get it back.
Well most people don't like ui paradigms that behaves like a teacher (that is smarter than your self),
help should be provided when the user asks for it.
useful clippy http://middaysoftware.com/MinhsBlogs/DirectGallery/bad_clippy.gif
When a user needs help, usually it isn’t a question of “what does Control X do?” It’s “How do I complete Task Y?” To support this you can:
Include a hide-able pane or drop-down menu that provides a context sensitive list of likely tasks (or next steps in tasks) that the user is looking to complete. Label them as questions (e.g., “How do I handle loans that aren’t being repaid?”). Selecting one question fills the pane or opens a help window describing how to complete the task (or step). Make it so such offers of help are easy to ignore (unlike Clippy) and also easy to retrieve later, such as through a Back button (again, unlike Clippy). Rather than providing instructions in a separate pane or window, you could show individual steps to a task with numbered balloons pointing to the relevant controls in the window. That's a novel approach that I think has a lot of potential. However, you have to be sure your design and/or algorithm handles the possibility of balloons interfering with each other or anything else the user wants to see.
On first execution of the program, this pane can include “Getting Started” which provides a conceptual overview of what users needs to do to get some specific useful outcomes (list them) from the app.
The main page of help should list high-level tasks the app supports. Selecting each task provides a conceptual overview and breaks down the procedure into steps or sub-tasks to be completed in the app.
In your detailed help for task or step, describe both the mechanics of using the UI (e.g., “Now select investment goals from the Goals drop-down list”) and task-related domain information (e.g., “Setting goals to ‘Long Term’ will bias the Stock Search for higher risk but higher return stocks. This is suitable if you don’t expect to need the money you invest for 10 years or more.”).
Tag your help files so that searching help by task name or description provides useful results. Make sure tags include terms a naïve user may choose (e.g., “profit” when they mean “capital gains”).
You may want to consider a full-scale tutorial not only for the app but the task domain. Emphasize how using the tutorial helps the users with their tasks or goals. For example, don’t label the link or menu “Learn to use Invest-o-max,” label it “Getting the most from your investments.”
You may want to consider structuring some rarely used features or even the whole app by task. This is what a wizard and Microsoft’s “Inductive User Interface” does. If the task is so structured that you really can tell what the user should do next, then consider this approach.
You still want to provide a means to explain every control, because sometimes that is the user’s question. Balloon help is one way to do this, but as you point out, it does little good if it just repeats the control’s caption or tooltip. Balloon help text should include much more, that’s why it’s in a balloon, and not permanently written on or beside the control. The help for a control should explain what it does, when to use it, what the values or parameters mean and which ones to select for what goal. In other words, more task-related help. Just a guess, but I don’t think you can show such balloons for all controls at once –they’ll get in each other’s way.
If there's usually some logical "next action" the user probably should be doing, how about throbbing/highlighting that area if the user appears to be stuck trying to work out their next action? A bit like the way the Office globe subtly glows and throbs the first few times you start Office.
A lot of web apps have extra tips the first few times you visit them, that's always handy. Some even have a guided tour that holds your hand and steps you gently through the first few tasks, a well designed one of them can help users hit the ground running. I've never seen this kind of thing in a winforms app, maybe you could be the first :-)
I like your F1 idea though, that'd be quite nice to use. I've often wanted to turn on all the tooltips at once so I can find the darn button I'm looking for, I think your F1 idea is not dissimilar to that.
Nice question!
Why assume that Clippy will never work? Just let me slap him for stupid tips, so he won't ask me the "letter" question again. An anthropomorphic assistant should behave like a real person. If you ignore them, they ignore you. And they don't keep giving tips that you already ignored.
The problem was, Clippy looked a lot smarter (socially) than he really was.
i agree with the "Ableton Hover" panel mentioned above. Also, perhaps offering a UI tour on first launch and making it accessible later might help. Also, as mentioned before, this involves lots of AI which may or may not be worth the effort.
BTW, Clippy was ok, but the metallic knocking on the monitor was annoying.
Screen casts. Its the fastest way for someone to learn how to use a program.
On my olympus camera the mode wheel has a slot called guide. when I turn the wheel to that slot, a set of common tasks appear, like "Shooting into backlight", "Blurring background" and "Reducing red-eye". These are tasks that require several steps to complete (changing aperture, light-sensitivity, etc), but can be described in a few words, and are considered as a single thing by the user. Most programs have such tasks (eg, "writing a letter", "moving a file to another device", etc). The program should have an easy way to see a list of common tasks and how to perform them.
I'm not sure that remapping the F1 key functionality is the best approach, although I like that you're thinking "out of the box" for ways to provide user assistance.
You used the example of an airline cockpit as an example of a complex UI. But the comparison doesn't work; airline pilots are trained, trained, and trained some more. They know where every instrument is and what each one does almost by instinct, and it's because of that training. Unless your users are going to have equivalent training....
(BTW, as an interesting aside, the pilot who put the plane down in the Hudson, Chesley "Sully" Sullenberger, lamented the corporate savings of removing tabs in the emergency manual, making it more difficult for his co-pilot to find very necessary infortmation very quickly.)
I bring this up to illustrate two useful concept of user assistance design and development: just-in-time information and layered information.
If you can find places in your UI for bits of information, hints, as it were, right at the time and place of need, then users might have just enough to figure out what to do with that UI element. (This is actually a layer of information, but it is the second layer. The first layer is what the UI itself communicates, and is why UI design is such an important part of the development process and one so important to get right.)
The next layer can be accessed in many ways, but it usually takes some kind of user action, either indirect or direct. An example of indirect is when a user gives a field focus, some extra information appears, perhaps in an out-of-the-way pop-up. An example of direct is where a user takes a specific action to get more information, whether pressing F!, clicking on a small question mark icon, or clicking the Help menu.
The interesting thing is that these layers of information can reside in several places. Some development teams have all this content, and the coding to make it appear, in the product code. Some have it in a database, while others have it in a "traditional" help system that is hooked into the programming code.
All that said, I'm actually shooting in the dark a bit here, offering theoretical ideas rather than practical ones. Why? Because I know nothing about your users. Are you writing an application for an internal audience whose job will be to use the software? (In which case, will they get training, and will they be motivated to learn about how to use the software?) Or is this for a more "casual" audience, who will use the software only occasionally, or even rarely. Are you writing for users who understand the underlying subject matter, or those who have no clue? Understanding you users needs and goals are key to reducing their frustration and making them happy, and that will drive some of the best ideas about how, when, and where to provide assistance.
I think you've got two issues here - one about describing the interface to the user and the other of walking the user through the process (the validation, etc).
To tackle the first there's all sorts of approaches mentioned by others but I quite like Joe's solution of the "context box" and mouse-over. Sure, it doesn't tell people where to start, but often people like to just explore for themselves.
As for the second, some sort of process flow diagram that may be made visble/invisible would be useful. Think of how some install wizards do it - similar concept.
eg. Step 1 -> Step 2 -> etc.
I've always felt Clippy died because he was intrusive and got in the way of what the user was trying to do. From sitting with my users while they are learning a program it seemed to me that most of them would rather stumble around the UI until they find what they are looking for. Asking for help was the method of last resort. I have used the status bar for very brief tips, but I never caught one of my users actually reading the tips. They did click the Help menu, or press F1 if they got frustrated enough. Now I just use the Help system for my programs. For the most part I display the help file at the topic for the window they are currently working with. If the user has pressed F1 and are in an area that requires less in-depth help I prefer to use popup help.
加载中,请稍侯......
精彩评论