Spybot 2.0: problem handling concepts

I'll start the talk about the user interface with error messages, where our conclusion from 1.x was that we did not stay true enough to a very important concept. Well, proper error dialogs are rarely encountered anywhere, but that should not be an excuse.

A good error message should have three purposes, possibly four:
  1. Inform the user that something went wrong in terms he understands.
  2. Make suggestions how to correct the problem.
  3. Provide information that may help customer support trailing the source of the problem.
  4. Offer those users who want to understand a background.
You'll often find one, and sometimes two of these in an error message, but very rarely all three in a language and structure that's adjusted to the users situation. And we've got to admit: the standard Windows error box does not really supporting displaying that information well-structured.

You can see our attempts at immunization errors, shredding errors and restore errors to see how we try to improve (and that we still have to finalize those texts, since they do not yet fulfill all our criteria).

Key points:
  • We try to offer the user an alternative (like elevation in the shredder dialog) instead of just displaying an error message.
  • A Hide/Show button is there to show the technically interested more information.
  • A clear headline indicating what the dialog is about, e.g. the direct question the buttons will decide upon.
  • Possible error reasons (immunization).
  • An option to skip his information in the future for those users who do not want to be annoyed by these messages.
Comments on how you would see this as a novice user (who might need the guidance?), or an advanced user (how big is the annoyance factor?), would be welcome of course!
 
Click to expand...
Very good, an error message should be concise, clear and yet offer likely solutions - possibly a built-in link with pre-filled fields (related to the error's nature in standard form) to the forum's (more public) or wiki's search page may be helpful.

As to the toggle/skip, that seems to be a prime candidate for being another 'ignore' category in the main SSD settings page with a tree structure. This would centralize the switching for reference to individual (or by class) ignores.

For the novice, a 'level' by visual means such as background color or another icon might simplify a response priority - not all errors are critical or system-threatening but they are still errors. Hard to say on this, correct functioning of the app or applet is necessary as a base condition.
 
Last edited:
Thanks, good points :)

Settings will become a new separated module/window since it should not be necessary to open the main scanner app to change them. Screenshot of just that one settings tab, there are more of course ;)

Setting icons (information/warning/error) is also on our check list, I think we even updated dialogs already just not all screenshots. As for background color, we might play around with headers with a background color in those dialogs, just couldnt find a decent combination of gradient colors yet.

Weblinks are an interesting idea... maybe even to the forum with a list of threads tagged with a tag associated with that specific dialog or something like that. The danger of course is to put too mich into dialogs there. Maybe we could check the help system to combine it with sich an online lookup...
 
You must log in or register to reply here.
Back
Top