[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Introducing LikeBack - Quick Feedback from Beta-Testers
From:       "Diego Moya" <turingt () gmail ! com>
Date:       2006-08-16 11:22:13
Message-ID: 11ee04940608160422k795e54a7mf0bdca1dc4f3b58 () mail ! gmail ! com
[Download RAW message or body]

Good work! Your code should soon be included as a KDE default library
to enhance the life cycle of the Open Software projects, which heavily
depends on user reporting.

On 11/08/06, Sébastien Laoût <slaout@linux62.org> wrote:
> Le Vendredi 11 Août 2006 21:40, Chi Shang Cheng a écrit:
> > - The use of colour in the feedback dialogs is unneccesary, the colour does
> > not add useful information and results in a less consistent KDE interface.
>
> By experience, it's quite important the user click the right icon (Like or
> Dislike) because it can be mis-interpeted by the developers.
> When I read a message saying "the new tree view" I need to be sure the user
> have not made mistake in clicking the Like or Dislike icon, because it change
> completely what I will do for the application (abandon the new feature
> because not liked at all, or continue and improve it).
> Sometimes I thinked it was a dislike instead of a like, even tought the
> background color was green. So the background color is not too much.

There's a number of problems with your current use of colors:
- Blind-color users won't notice the green-red difference.
- Green and red are cultural colors, anyway. For example, in Asian
cultures red is the colour of happiness, and green means health and
peace.

You never should rely only on color to present information of state,
you should always have another indicator. In this case, the best
widget to convey the type of comment would be a radio button:

-------------------------------------------------------------
 Select the type of comment:
  :-/   (*) I'm reporting an error.
  :-)   ( ) I like the described feature.
  :-(   ( ) I don't like the described feature.
-------------------------------------------------------------

and the second-best, a drop-down list:

-------------------------------------------------------------
    Type of comment
    [ :-/ I'm reporting an error  v]
-------------------------------------------------------------

This way, the user can READ the selected state, and even better,
change it before sending the comment. If it is so important that the
user classifies the comment under the right kind, she shouldn't have
to cancel the dialog (possibly losing the already written comment) and
open a new one.


> > - The placement of the accompanying text in the feedback dialogs is
> > unfortunate. The visual dialog dictates that it should be in the top of the
> > window, because people are used to reading from the top-left corner to the
> > bottom-right one.
>
> The LikeBack goal is to lower the barrier between the users and the
> developers.
> So the text is on the bottom because it's not very important to read it.
> This helps users concentrate on typing theire comment, IMHO.
>
> It can be seen as a "legend" text.
>
> And that way the "I like..." label is logically glued with the text area.
> And as it's a sort of title, the "I like..." label should be on top of the
> window, thus the legend can only be put on the bottom of the window ;-)
> Unless you propose a better layout.

If the text is not important, it shouldn't be there at all. But the
first time the user uses this report system, it IS important and
should be read - so it should be at the top. Don't worry about the
users concentration - after having read the text for the first time,
users will simply ignore it.


Also the wording of the help text is subtly inducing errors. You say:
"Notice that to improve this application, it's important to tell us
the thing you like as much as the things you dislike".

This is encouraging the user to write down BOTH the "I like..." and
the "I don't like..." comment IN THE SAME TEXT BOX. When the user
finishes writing an "I like" comment, she is instructed to send also
"don't like" ones - and the easier action for this at this point is to
simply add one at the bottom of the current text box. To avoid this,
you should direct the user to the correct action to take for sending
further comments - open a new comment window.


You should design the interface to prevent errors, instead of trying
the user to recover from errors when she has made a mistake. IMHO you
should rethink the "I like" and "I don't like" buttons if you feel
that they are prone to errors. A simple "Send a comment" could
suffice, and then you can use a single window for all types of
comments, like this:


-------------------------------------------------------------
Please briefly describe your opinion about a part of the interface.
Your comment will be sent to the developers of this application. Only
English and French languages are accepted.
Notice that to improve this application, it's important to send us
several comments telling the things you like as much as the things you
dislike.

  Describe a feature of the window NewBasket:
   -------------------------------------------------------------
   |                                                           |
   |                                                           |
   |                                                           |
   |                                                           |
   -------------------------------------------------------------

 Select the type of comment:
  :-/   (*) I'm reporting an error.
  :-)   ( ) I like the described feature.
  :-(   ( ) I don't like the described feature.
  :-?  ( ) I want to propose a new feature.

 [Send comment] [Cancel]
-------------------------------------------------------------



If you still want to have different "Like/Don't like/Bug" buttons, you
can have them all open the same dialog just changing the default
selected value for the radio buttons.

Also you should have in mind that ther will always have some misguided
reportings which include both "like" and "don't like" features in the
same comment, so you shouldn't rely too much in this classification.
If you MUST have this classification right, you could try a
multi-comment design for the window, with a different box for each
type:

-------------------------------------------------------------
Please briefly describe your opinion about the window NewBasket. Your
comment will be sent to the developers of this application. Only
English and French languages are accepted. (You don't have to fill in
all the boxes below).

  I like...
   -------------------------------------------------------------
   |                                                           |
   |                                                           |
   -------------------------------------------------------------

  I don't like...
   -------------------------------------------------------------
   |                                                           |
   |                                                           |
   -------------------------------------------------------------

  Something is not working:
   -------------------------------------------------------------
   |                                                           |
   |                                                           |
   -------------------------------------------------------------

 [Send comment] [Cancel]
-------------------------------------------------------------
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic