[KDE Usability] Re: Usability Questions for KDE Telepathy

Martin Klapetek martin.klapetek at gmail.com
Tue Feb 1 17:20:07 CET 2011


I'd still like to point out the issue with checkboxes next to the accounts
in the accounts list (see background in screenshot [1]). There is no
indication, what are these for (I assume they're for enabling/disabling that
account, but average user might not and can get easily confused), so I'd add
some kind of information to them, column header might be great, but it would
have to be the whole row and that wouldn't look too good IMHO. So probably a
tooltip explaining what is it for. Another option is to add a text right
next to them, but this would introduce more UI clutter.

So the tooltip seems to be the best solution. What do you think?

Marty


[1]
http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/select_protocol.png


2011/2/1 David Edmundson <david at davidedmundson.co.uk>

> Here is our reply from the usability guys.
>
> ---------- Forwarded message ----------
> From: Aurélien Gâteau <agateau at kde.org>
> Date: 2011/1/29
> Subject: [KDE Usability] Re: Usability Questions for KDE Telepathy
> To: kde-usability at kde.org
>
>
> Hi,
>
> I finally took the time to look at your message and screenshots. Thanks
> for taking the time to produce detailed screenshots. See my comments below.
> [snip]
> > We have a wizard for setting up new accounts.
> > [1]
> >
> http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/select_protocol.png
> >
> > The second page on here allows us to set up everything you need to set up
> > everything 90% of users will need to configure to set up an account
> > (username/password normally). This changes per protocol.
> > [2]
> >
> http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/configure_jabber.png
> >
> > From here I made a decision that all advanced settings (that most people
> > won't need to change (server addresses, ports, security, etc. ) should be
> an
> > entire page away to 'hide' them from the majority of users who won't
> care.
> > [3]
> >
> http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/configure_jabber_advanced.png
> >
> > Some protocols have several tabs of advanced options, others (such as
> > Facebook or IRC) have none, and as such have no "advanced button as seen
> in
> > screenshot 2.
> >
> > Issues:
> >  * Is the 'overuse' of dialogs ok? If not what is a good solution?
>
> The only problematic dialog here IMO is the "Advanced" dialog. Is it
> possible to move its content either as an "Advanced" tab or to place it
> below the "Advanced" button, but keep it hidden until the user clicks
> this button?
>
> >  * How can we solve the 'large whitespace' issue seen in screenshot 2?
>
> Do you have code which ensures the content of the list in screenshot 1
> is fully visible? That would explain why the wizard dialog is so tall.
> >
> > ---
> >
> > We're also looking at, and not sure on a good way to do input validation.
> >
> > There are two ways we're currently providing (or wanting to provide)
> > feedback on the validation state. We've developed a custom widget which
> > shows a star on the right when a field is required and the user hasn't
> typed
> > anything in the field. When the user starts typing, the star becomes a
> red
> > cross. This indicates that the provided value is not valid. When the
> value
> > gets valid, the red cross turns into a green check mark.
> >
> > The second widget to provide feedback to the user would be a red-isch
> error
> > message on top. The idea is (stolen) borrowed from the bluedevil
> > configuration dialog. They have the same box on top. This box would
> appear
> > if a user clicks OK and not every value is valid, or somethings else goes
> > wrong. With a meaningful error message that is of course.
> > Look at the screenshots validation1.png and validation2.png attached to
> > actually see the widgets. I know the placement of the validated line edit
> is
> > not OK. It's just there to test. Of course, the text in the feedback
> widget
> > should say something meaningful instead of Creation failed.. We would
> like
> > to know if we are on the right track though, before we start integrating
> > these widgets.
> >
> > [4]
> >
> http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/validation1.png
> >
> > [5]
> >
> http://static.davidedmundson.co.uk/accounts-kcm-pics/usability_review_1/validation2.png
> >
> > The question we would like to ask about validation:
> > * Should we even give the user the opportunity to click the OK button if
> not
> > all required values are valid, or should it be grayed out?
>
> Both approaches are valid. As long as the "field validity" indicators
> make it obvious that something is missing, I would personally go for
> graying out the OK button.
>
> > * Is it common to show the icons of the validation state on the right,
> > inside the line-edit?
> >
> > * Is there any way to improve all of this? We're not really sure about
> all
> > of this
>
> Using a star to denote a mandatory field is a common UI pattern on the
> Web. I think it is a good idea to use it here, but I have two concerns:
>
> - If the star becomes a red cross as soon as the user starts typing, I
> am afraid the user will interpret this change as an indication that he
> just made a mistake. I suggest always showing a red star (not the cross,
> because it is associated with "error", not with "mandatory") when the
> field is empty or wrong and turn it into the green check mark when the
> field is OK.
>
> - The icon looks a bit big inside the line edit. It would probably be
> nicer to show the widget on the right of the line edit.
>
> Your work looks promising, looking forward for it!
>
> Aurélien
> _______________________________________________
> kde-usability mailing list
> kde-usability at kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110201/89db10fa/attachment-0001.htm 


More information about the KDE-Telepathy mailing list