'Re: amaroK usability report'

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

List: kde-usability
Subject: Re: amaroK usability report
From: "Chi Shang Cheng" <chishangcheng () gmail ! com>
Date: 2006-05-02 19:30:11
Message-ID: 8e5359a90605021230r1b6429a1ldab8eaab8430f880 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

2006/5/2, G=E1bor Lehel <illissius@gmail.com>:
>
> On 5/2/06, Chi Shang Cheng <chishangcheng@gmail.com> wrote:
> > I have conducted a quick heuristic evaluation of amaroK.
>
> Thanks for the report! Here's some feedback.
>
> 3.5 - I'm not sure 'appearance' is the right term here. As a result of
> this option, things will not just look different (as with a theme),
> but they will be in different places. Which to me implies something
> more than just 'appearance', but I can't think of anything better,
> either.
>
> 3.6 - This can actually be changed with 'Show Player Window' in the
> Settings menu. So yes, there is a bug, but it's not that the setting
> isn't in the configuration dialog, but that it's referring to the
> configuration dialog at all.

Player controls wouldn't change accordingly, at least not when I tested it.

3.7 - Any ideas how to manage showing the home directory as the root
> of the treeview by default, while also making it readily possible to
> show the whole filesystem if the user needs it? Perhaps using the same
> widget as the 'sidebar' of the filedialog? (I just checked, it is
> available separately as KURLBar).

What I meant with "progressive disclosure", is that advanced functions
should be hidden, but still available for those who need it. The easiest wa=
y
to accomplish that, is to create a button labeled "Advanced" and when the
user clicks on it, a dialog will pop-up with the current interface (the
filesystem tree-view).

3.12 - This widget is actually one of my favorite things in amaroK. It
> doesn't take much space away from the content, but still has nice big
> targets to hit, thanks to them taking the full height, and is as
> functional as any other sidebar out there (and more than most of
> them). The vertical text is imo a worthy tradeoff for this, but as
> usual, others' opinions may differ.

I couldn't find much research about this, so I'm not certain what the actua=
l
implications would be for vertical tabs. What I do know, is that reading
speed will be decreased by arranging the text vertically. This is primarily
due to larger gaze amplitude for horizontal reading, and thus smaller
numbers of saccades and fixations. I'm not sure how or whether this will
effect Fitts' law.

3.13 - I don't see the point of this...  doesn't the rest of the
> search bar serve as well for 'empty space' as actual nothing would?
> And by making it shorter, it would be asymmetrical, which might be
> ugly. (And, just as a sidenote, you can also put more advanced queries
> into the search, with ANDs and ORs and stuff, so occasionally someone
> might want to type something longer in, not just a word or two.)

Don't expect the search bar to contrast with itself. As for the size, there
are certain rules in graphics design from which you can calculate the size,
while it still looks natural. Since I'm not a designer, I can't help you
with that (yet).

3.14 - Not necessarily. While all menu items -are- actions in the
> sense that something happens as a result of them (otherwise they would
> be quite useless), and that this can be construed as an action, in the
> Actions menu, you have for example 'Play', which is an action; but in
> the Tools menu, you have for instance 'Equalizer', which is not an
> action, but a thing. (As an action, it would be "Open the equalizer".)

As the actions for opening certain tools are grouped in the menu "Tools", a
similar approach can be used to improve the Actions menu. On a side note,
I'm planning to do conduct a usability test involving users to improve the
amaroK menu. The usability inspection method that I will be using is called
"card-sorting". But I'm not promising anything? ;-)

3.17 - As far as I know, while there was a heated debate on the topic,
> having these clear buttons is still the default in KDE. So it would be
> better to keep it for now, for the sake of consistency, no?
> (Did the debate have a conclusion, by the way, or is this just the
> opinion of the author? If it did, then removing these clear buttons is
> probably something to be done for KDE4 and amaroK 2.0.)
>
> 3.19 - I think it should be kept, for the sake of clarity and
> convenience. While you could still drag things from e.g. Konqueror to
> the playlist without it, it wouldn't be immediately obvious that this
> is possible. Also, Kate for example has a similar file navigation
> sidebar, and Kate certainly doesn't have the concept of a collection
> -- it's only there because it's a whole lot quicker and more
> convenient than opening the file dialog every time, and the same
> applies here.

Usage of the Collection concept should be encouraged, since it is more
powerful. Also, the user should be able to add multiple music files to the
playlist from the Play Media dialog.

3.20 - For reference, KP_Enter is the Enter key on the numeric keypad,
> on the right of most (all?) keyboards. I dislike this shortcut too,
> don't know what could else could be used instead (is plain Ctrl+Return
> taken?).
>
> 3.22 - Actually, you can put in URLs here (such as online music
> streams). Having separate dialogs for files and URLs might be a good
> idea though, nonetheless.
>
> 3.23 - As far as I can tell, the text is intended to encourage the
> user to start one of the lyrics scripts, so (s)he can then continue
> using the Lyrics tab. But it could probably be worded better. (Or just
> automatically start the first script which works, and let the user
> change it if (s)he doesn't like it.)
>
> 3.25 - Actually, it also displays the artist. Previously tooltips were
> used, but there was some technical issue with them I don't recall, so
> now there's a statusbar instead. (Personally, I think the artist
> should be displayed under the icon along with the album name, as I've
> often missed having it, and it was a while until I realized the
> statusbar was there.)
>
> 3.26 - This is there either because albums have different artwork in
> different territories, or because you aren't likely to find album art
> for an obscure French band by searching for it on Amazon's American
> site (probably the latter). Perhaps it should be labelled just
> 'Locale' instead?

Instead, amaroK should search on other locales automatically, if no artwork
has been found in a certain locale. :)
Add the option to download/display artwork from another locale to the
context-menu.

3.29 - Unfortunately this can't really be done without either amaroK
> becoming a package manager, or a greater amount of cooperation and
> standardization between desktop environments and distributions coming
> about, than we have currently. Specifically, these are binary
> packages, which must be installed using the package manager of
> whatever distro the user is using. amaroK can do little more than tell
> the user to do so.
>
> 3.30 - This is a case of the correct name versus the familiar name.
> Because these really aren't plugins, they are scripts. You can't
> enable amaroK to decode new media formats, or change its appearance,
> with them, as you can with most plugins. They are more like small
> mini-programs running alongside amaroK (as opposed to becoming part of
> amaroK itself, as with plugins), with an unusually high degree of
> integration, thanks to DCOP. The distinction is technical, but it does
> have a profound effect on what these scripts are capable of doing. So
> I'm unsure which is the best thing to call them.

The average user probably won't see this distinction, if the name plug-ins
was chosen.

3.31 - It actually does work, but you have to choose a category
> (Favorite Artists, whatever) before you can see the effect. I'm not
> sure what the best solution is -- hiding it before a category is
> chosen is the most straightforward, but a user might want to (for
> example) type in 'Pink Floyd', and then visit the categories in order,
> to see what his/her favorite songs, albums, et al, by Pink Floyd, are.

It would be cool to find out whether users would still use the search
functionality before selecting a category, is the search bar was placed
below the categories. :)
Even then, I didn't expect that the items were going to expand like in a
tree view (since it doesn't like a tree view).

3.34 - This dialog is provided by a KDE library, not by amaroK, I
> don't know if there is an easy way to disable the sidebar (but don't
> think so). Though we could probably come up with a hack.

I forgot to mention that I didn't make the distinction whether an issue was
a pure amaroK issue, or whether KDE was also involved.

3.36 - Might be the same as 3.3.4?
>
> 3.37 - Again, this is most likely a KHelpCenter bug. (but correct me
> if I'm wrong)
>
> 3.40, 3.41 - There are plenty of other actions (for example, 'Stop
> Playing After Track') which are only accessible through context menus.
> The main menu would probably become quite bloated if there were
> included into it. What is the rationale behind "Actions that are in
> the context-menu, should always be accessible from the main menu"?
> (genuinely curious, i've heard this before)

My teacher once told me this, I don't recall what the rationale was... But =
I
think it has to do that many people actually browse through the menus,
rather than right-clicking. I've seen this behaviour a lot with novice
users.

3.15, 3.24, maybe others - these would probably require a (semi-)major
> reorganization of amaroK's interface. (For example, I think it would
> look quite dumb if the player control buttons were shown in the top
> left corner, above the context browser). Any ideas?

Right now, I'm catching up on visual design/graphics etc. and hope to come
up with some great ideas in the near future. :)

(Where I haven't commented, it's either because I don't know much
> about that part of amaroK, or because you're simply correct.)
>
> Thanks for helping. Please reply and elaborate on the points where you
> disagree with me.

--
> Work is punishment for failing to procrastinate effectively.
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>

[Attachment #5 (text/html)]

<br><br><div><span class="gmail_quote">2006/5/2, Gábor Lehel &lt;<a \
href="mailto:illissius@gmail.com" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">illissius@gmail.com</a>&gt;:</span><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">

On 5/2/06, Chi Shang Cheng &lt;<a href="mailto:chishangcheng@gmail.com" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">chishangcheng@gmail.com</a>&gt; wrote: &gt; \
I have conducted a quick heuristic evaluation of amaroK. Thanks for the \
report! Here's some feedback. 3.5 - I'm not sure 'appearance' is the right \
term here. As a result of this option, things will not just look different (as \
with a theme), but they will be in different places. Which to me implies something \
 more than just 'appearance', but I can't think of anything \
better, either. 3.6 - This can actually be changed with 'Show Player \
Window' in the Settings menu. So yes, there is a bug, but it's not that the \
setting isn't in the configuration dialog, but that it's referring to \
the configuration dialog at all.</blockquote><div> Player controls wouldn't \
change accordingly, at least not when I tested it. </div> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">

3.7 - Any ideas how to manage showing the home directory as the root of the \
treeview by default, while also making it readily possible to show the whole \
filesystem if the user needs it? Perhaps using the same widget as the 'sidebar' of \
the filedialog? (I just checked, it is available separately as \
KURLBar).</blockquote><div> What I meant with &quot;progressive disclosure&quot;, \
is that advanced functions should be hidden, but still available for those who need \
it. The easiest way to accomplish that, is to create a button labeled \
&quot;Advanced&quot; and when the user clicks on it, a dialog will pop-up with the \
current interface (the filesystem tree-view). </div> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">3.12 - This widget is actually one of my favorite \
things in amaroK. It doesn't take much space away from the content, but still has \
nice big targets to hit, thanks to them taking the full height, and is \
as functional as any other sidebar out there (and more than most of them). The \
vertical text is imo a worthy tradeoff for this, but as usual, others' opinions \
may differ. </blockquote><div> I couldn't find much research about this, so I'm \
not certain what the actual implications would be for vertical tabs. What I do know, \
is that reading speed will be decreased by arranging the text vertically. This is \
primarily due to larger gaze amplitude for horizontal reading, and thus smaller \
numbers of saccades and fixations. I'm not sure how or whether this will effect \
Fitts' law. </div> <blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.13 - I \
don't see the point of this...&nbsp;&nbsp;doesn't the rest of the search bar serve \
as well for 'empty space' as actual nothing would? And by making it shorter, it \
would be asymmetrical, which might be ugly. (And, just as a sidenote, you can also \
put more advanced queries into the search, with ANDs and ORs and stuff, so \
occasionally someone

might want to type something longer in, not just a word or \
two.)</blockquote><div> Don't expect the search bar to contrast with itself. As \
for the size, there are certain rules in graphics design from which you can calculate \
the size, while it still looks natural. Since I'm not a designer, I can't help you \
with that (yet). </div> <blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.14 - \
Not necessarily. While all menu items -are- actions in the sense that something \
happens as a result of them (otherwise they would be quite useless), and that \
this can be construed as an action, in the Actions menu, you have for example \
'Play', which is an action; but in the Tools menu, you have for instance \
'Equalizer', which is not an

action, but a thing. (As an action, it would be &quot;Open the \
equalizer&quot;.)</blockquote><div> As the actions for opening certain tools are \
grouped in the menu &quot;Tools&quot;, a similar approach can be used to improve the \
Actions menu. On a side note, I'm planning to do conduct a usability test involving \
users to improve the amaroK menu. The usability inspection method that I will be \
using is called &quot;card-sorting&quot;. But I'm not promising anything? ;-) \
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.17 - As far as I know, \
while there was a heated debate on the topic, having these clear buttons is still \
the default in KDE. So it would be better to keep it for now, for the sake of \
consistency, no? (Did the debate have a conclusion, by the way, or is this just \
the opinion of the author? If it did, then removing these clear buttons \
is probably something to be done for KDE4 and amaroK 2.0.) 3.19 - I think \
it should be kept, for the sake of clarity and convenience. While you could still \
drag things from e.g. Konqueror to the playlist without it, it wouldn't be \
immediately obvious that this 
is possible. Also, Kate for example has a similar file navigation sidebar, and \
Kate certainly doesn't have the concept of a collection -- it's only there because \
it's a whole lot quicker and more convenient than opening the file dialog every \
time, and the same applies here.</blockquote><div> Usage of the Collection \
concept should be encouraged, since it is more powerful. Also, the user should be \
able to add multiple music files to the playlist from the Play Media dialog. \
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.20 - For reference, \
KP_Enter is the Enter key on the numeric keypad, on the right of most (all?) \
keyboards. I dislike this shortcut too, don't know what could else could be used \
instead (is plain Ctrl+Return taken?). 3.22 - Actually, you can put in URLs \
here (such as online music streams). Having separate dialogs for files and URLs \
might be a good idea though, nonetheless. 3.23 - As far as I can tell, the \
text is intended to encourage the user to start one of the lyrics scripts, so \
(s)he can then continue using the Lyrics tab. But it could probably be worded \
better. (Or just automatically start the first script which works, and let the \
user change it if (s)he doesn't like it.) 3.25 - Actually, it also displays \
the artist. Previously tooltips were used, but there was some technical issue with \
them I don't recall, so now there's a statusbar instead. (Personally, I think the \
artist should be displayed under the icon along with the album name, as \
I've often missed having it, and it was a while until I realized the statusbar \
was there.) 3.26 - This is there either because albums have different artwork \
in different territories, or because you aren't likely to find album art for an \
obscure French band by searching for it on Amazon's American 
site (probably the latter). Perhaps it should be labelled just 'Locale' \
instead?</blockquote><div> Instead, amaroK should search on other locales \
automatically, if no artwork has been found in a certain locale. :)

Add the option to download/display artwork from another locale to the \
context-menu.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

3.29 - Unfortunately this can't really be done without either amaroK becoming a \
package manager, or a greater amount of cooperation and standardization between \
desktop environments and distributions coming about, than we have currently. \
Specifically, these are binary packages, which must be installed using the \
package manager of whatever distro the user is using. amaroK can do little more \
than tell the user to do so. 3.30 - This is a case of the correct name \
versus the familiar name. Because these really aren't plugins, they are scripts. \
You can't enable amaroK to decode new media formats, or change its \
appearance, with them, as you can with most plugins. They are more like \
small mini-programs running alongside amaroK (as opposed to becoming part of \
 amaroK itself, as with plugins), with an unusually high degree of integration, \
thanks to DCOP. The distinction is technical, but it does have a profound effect \
on what these scripts are capable of doing. So I'm unsure which is the best thing \
to call them. </blockquote><div> The average user probably won't see this \
distinction, if the name plug-ins was chosen. </div> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">

3.31 - It actually does work, but you have to choose a category (Favorite Artists, \
whatever) before you can see the effect. I'm not sure what the best solution is -- \
hiding it before a category is chosen is the most straightforward, but a user \
might want to (for example) type in 'Pink Floyd', and then visit the categories \
in order, to see what his/her favorite songs, albums, et al, by Pink Floyd, \
are.</blockquote><div> It would be cool to find out whether users would still use \
the search functionality before selecting a category, is the search bar was placed \
below the categories. :) Even then, I didn't expect that the items were going to \
expand like in a tree view (since it doesn't like a tree \
view). </div> <blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

3.34 - This dialog is provided by a KDE library, not by amaroK, I don't know if \
there is an easy way to disable the sidebar (but don't think so). Though we could \
probably come up with a hack.</blockquote><div> I forgot to mention that I didn't \
make the distinction whether an issue was a pure amaroK issue, or whether KDE was \
also involved. </div> <blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.36 - \
Might be the same as 3.3.4? 3.37 - Again, this is most likely a KHelpCenter \
bug. (but correct me if I'm wrong) 3.40, 3.41 - There are plenty of other \
actions (for example, 'Stop Playing After Track') which are only accessible \
through context menus. The main menu would probably become quite bloated if there \
were included into it. What is the rationale behind &quot;Actions that are \
in the context-menu, should always be accessible from the main \
menu&quot;? (genuinely curious, i've heard this before)</blockquote><div> My \
teacher once told me this, I don't recall what the rationale was... But I think it \
has to do that many people actually browse through the menus, rather than \
right-clicking. I've seen this behaviour a lot with novice users. \
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3.15, 3.24, maybe others - \
these would probably require a (semi-)major reorganization of amaroK's interface. \
(For example, I think it would look quite dumb if the player control buttons were \
shown in the top left corner, above the context browser). Any \
ideas?</blockquote><div> Right now, I'm catching up on visual design/graphics etc. \
and hope to come up with some great ideas in the near future. :) \
 </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">(Where I haven't commented, \
it's either because I don't know much about that part of amaroK, or because \
you're simply correct.) Thanks for helping. Please reply and elaborate on the \
points where you disagree with me.</blockquote><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">

--<br>Work is punishment for failing to procrastinate \
effectively.<br>_______________________________________________<br>kde-usability \
mailing list<br><a href="mailto:kde-usability@kde.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)"> \
kde-usability@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-usability" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)"> \
https://mail.kde.org/mailman/listinfo/kde-usability</a><br></blockquote></div>

_______________________________________________
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] 