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

List:       kde-usability
Subject:    Re: amaroK usability report
From:       "=?ISO-8859-1?Q?G=E1bor_Lehel?=" <illissius () gmail ! com>
Date:       2006-05-02 16:54:58
Message-ID: 9cfeadb80605020954t2f7fd696m3f71f5c1c432c1da () mail ! gmail ! com
[Download RAW message or body]

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.

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).

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.

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.)

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".)

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.

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?

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.

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.

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.

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)

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?

(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
[prev in list] [next in list] [prev in thread] [next in thread]