[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-03 9:28:04
Message-ID: 8e5359a90605030228w33365ab0n89a1f7f1c2f9476d () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2006/5/3, Iñaki <ibc2@euskalnet.net>:
>
> El Martes, 2 de Mayo de 2006 00:33, Chi Shang Cheng escribió:
> > I have conducted a quick heuristic evaluation of amaroK.
> >
> > Abstract:
> > After a short heuristic evaluation of Amarok, a total of 41 usability
> > issues were found. Only 8 issues of low severity were found, 11 were
> marked
> > medium, and the remaining 22 issues considered highly severe.
> > Most of the issues were related to design flaws. The application was not
> > tested for task-oriented usability. Even though the application
> functioned
> > properly from a technical perspective, attention should be given to a
> more
> > aesthetic user interface design in the future.
>
>
> Excellent document, congratulations.
>
>
> About the issue:
> 3.13 Large width of search bar (playlist):
>
> I reported the same wish/bug to "kdebugs" but they didn't like the
> proposal:
> http://bugs.kde.org/show_bug.cgi?id=126249
>
>
>
> I'm not agree with "3.19 Unnecessary use of Files browser":
>
> My brother (with knows nothing about "collection" concept) uses it ALWAYS.
> In
> fact it's the only he uses to select music. Sometimes he browse him music
> with Konqueror, but just sometimes. The same with many friends of mine: no
> one of them know the concept of tags collection/library and use always
> the "file" concept, but they use amarok file browser more than just
> Konqueror.
I didn't treated the Files browser as not functional, but it was more from
an aesthetic design perspective. I've also read a comment about this from
one of the amaroK guys on the amarok-devel list, and he agrees with your
point.
I will elaborate my point of view on this issue:
I think that we should investigate this further, preferably with user
testing. If task analysis (of non-amaroK users of course) would show that
users would actually use the Files browser, in favor of file browsing with
Konqueror, than this feature should remain. Of course, the task should not
imply what method should be chosen.
Since I hadn't conducted any user testing, my assumption was that user
wouldn't use the Files browser, for the following reasons:
- I assumed that text that was vertically arranged, required intentional
reading behaviour of the user, i.e. the user wouldn't detect this as easily
as horizontal text if he was to "scan" the window. Basically, this browser
panel wouldn't be easily detected. I think that when the tabs were placed
horizontally, the Files browser would be more discoverable, but this is also
an assumption.
- Similar applications don't have this functionality, so this behaviour of
file browsing inside a music management application (for instance iTunes,
Songbird, Banshee etc.), so it wouldn't be experience that would help the
user discover and use this functionality.
- The Files browser panel is quite narrow, and I also assumed that users
would prefer a wider screen to browse in. I haven't looked for (scientific)
research about the implications of subjective preference of window
dimensions for applications; more importantly, do users make this
disctinction/discrimination (consciously/subconsciously)?
- KDE users that are not familiar with amaroK, but are (probably) already
familiar with the Konqueror file browser. But task analysis should also be
conducted to find out more about the "opening file" behaviour of users (on
the KDE desktop): how often do users open a file from within an application
and how often do users use the file browser to access a certain file.
- If the Files browser wasn't available, would users know how to play
music/add songs to the playlist/etc. while still not using the
collection/library? If the users could easily do this with another, with the
emphasis on easily, then it would be obvious that this Files browser does
not fulfil an important purpose. If the answer was only a modest 'yes',
emphasizing modest, then this feature would be questionable.
Anyway the amaroK file browser allows typical actions of amaroK as "add to
> the
> playlist", "edit info"... and it's easy to use, more than draging and
> dropping files from Konqueror to amaroK playlist (that forces the user to
> see
> at the same time the konqueror and amaroK-playlist windows.
In Windows, an application can add (cascaded) context-menu items to the
Windows Explorer. Winamp makes use of this functionality for instance. So it
could be solved this way.
Congratulations again for an excellent work!
> _______________________________________________
> 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/3, Iñaki <<a \
href="mailto:ibc2@euskalnet.net">ibc2@euskalnet.net</a>>:</span> <blockquote \
class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: \
#ccc 1px solid">El Martes, 2 de Mayo de 2006 00:33, Chi Shang Cheng escribió:<br>> \
I have conducted a quick heuristic evaluation of amaroK. <br>><br>> \
Abstract:<br>> After a short heuristic evaluation of Amarok, a total of 41 \
usability<br>> issues were found. Only 8 issues of low severity were found, 11 \
were marked<br>> medium, and the remaining 22 issues considered highly severe. \
<br>> Most of the issues were related to design flaws. The application was \
not<br>> tested for task-oriented usability. Even though the application \
functioned<br>> properly from a technical perspective, attention should be given \
to a more <br>> aesthetic user interface design in the \
future.<br><br><br>Excellent document, congratulations.<br><br><br>About the \
issue:<br>3.13 Large width of search bar (playlist):<br><br>I reported the same \
wish/bug to "kdebugs" but they didn't like the proposal: <br><a \
href="http://bugs.kde.org/show_bug.cgi?id=126249">http://bugs.kde.org/show_bug.cgi?id=126249</a><br><br><br><br>I'm \
not agree with "3.19 Unnecessary use of Files browser":<br><br>My brother \
(with knows nothing about "collection" concept) uses it ALWAYS. In <br>fact \
it's the only he uses to select music. Sometimes he browse him music<br>with \
Konqueror, but just sometimes. The same with many friends of mine: no<br>one of them \
know the concept of tags collection/library and use always <br>the "file" \
concept, but they use amarok file browser more than just<br>Konqueror.</blockquote> \
<div> </div> <div>I didn't treated the Files browser as not functional, but it \
was more from an aesthetic design perspective. I've also read a comment about this \
from one of the amaroK guys on the amarok-devel list, and he agrees with your point. \
</div> <div> </div>
<div>I will elaborate my point of view on this issue:</div>
<div> </div>
<div>I think that we should investigate this further, preferably with user testing. \
If task analysis (of non-amaroK users of course) would show that users would actually \
use the Files browser, in favor of file browsing with Konqueror, than this feature \
should remain. Of course, the task should not imply what method should be chosen. \
</div> <div> </div>
<div>Since I hadn't conducted any user testing, my assumption was that user \
wouldn't use the Files browser, for the following reasons:</div> <div> </div>
<div>- I assumed that text that was vertically arranged, required intentional reading \
behaviour of the user, i.e. the user wouldn't detect this as easily as horizontal \
text if he was to "scan" the window. Basically, this browser panel wouldn't \
be easily detected. I think that when the tabs were placed horizontally, the Files \
browser would be more discoverable, but this is also an assumption. </div>
<div> </div>
<div>- Similar applications don't have this functionality, so this behaviour of file \
browsing inside a music management application (for instance iTunes, Songbird, \
Banshee etc.), so it wouldn't be experience that would help the user discover and use \
this functionality. </div>
<div> </div>
<div>- The Files browser panel is quite narrow, and I also assumed that users would \
prefer a wider screen to browse in. I haven't looked for (scientific) research about \
the implications of subjective preference of window dimensions for applications; more \
importantly, do users make this disctinction/discrimination \
(consciously/subconsciously)? </div>
<div> </div>
<div>- KDE users that are not familiar with amaroK, but are (probably) already \
familiar with the Konqueror file browser. But task analysis should also be conducted \
to find out more about the "opening file" behaviour of users (on the KDE \
desktop): how often do users open a file from within an application and how often do \
users use the file browser to access a certain file. </div>
<div> </div>
<div>- If the Files browser wasn't available, would users know how to play music/add \
songs to the playlist/etc. while still not using the collection/library? If the users \
could easily do this with another, with the emphasis on easily, then it would be \
obvious that this Files browser does not fulfil an important purpose. If the answer \
was only a modest 'yes', emphasizing modest, then this feature would be questionable. \
</div><br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px \
0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Anyway the amaroK file browser allows typical \
actions of amaroK as "add to the<br>playlist", "edit info"... and \
it's easy to use, more than draging and <br>dropping files from Konqueror to amaroK \
playlist (that forces the user to see<br>at the same time the konqueror and \
amaroK-playlist windows.</blockquote> <div> </div>
<div>In Windows, an application can add (cascaded) context-menu items to the Windows \
Explorer. Winamp makes use of this functionality for instance. So it could be solved \
this way.</div><br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: \
0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Congratulations again for an \
excellent work!<br>_______________________________________________<br>kde-usability \
mailing list <br><a href="mailto:kde-usability@kde.org">kde-usability@kde.org</a><br><a \
href="https://mail.kde.org/mailman/listinfo/kde-usability">https://mail.kde.org/mailman/listinfo/kde-usability</a><br></blockquote></div><br>
_______________________________________________
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