[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: konqueror usability report
From: David Hugh-Jones <hughjonesd () yahoo ! co ! uk>
Date: 2003-02-01 1:48:11
[Download RAW message or body]
Here it is. These are just some issues that have been bugging me for a
while. Certainly not complete, probably highly subjective. ("report"
sounds far too objective!)
I didn't validate the schema, sorry. NB: why XML? What is it actually
doing for us that searchable plain text wouldn't do? I merely ask. NB2:
is there an easy way to do this schema stuff in KDE?
Most of these comments are, by their nature, negative. I just want to
say - I wouldn't do this if I didn't love KDE & konqueror and really
admire the people who write the code.
Dave
["konqueror-usability-report.xml" (konqueror-usability-report.xml)]
<report date="">
<author name="" email="" />
<application name="Konqueror" version="3.1" />
<issue severity="low">
<title>
CVS integration enabled by default
</title>
<description>
By default, there is a "CVS view" button in the Konqueror main toolbar.
This button is of specialized use only and will confuse non-programmer users.
</description>
<reproduction>
</reproduction>
<solution>
Remove the button by default.
</solution>
</issue>
<issue severity="medium">
<title>
Using previews causes icons in dirview to move
</title>
<description>
With previews turned on, Konqueror will take some time to display
previewed files. Before that time, file icons will be displayed. When
the previews are shown, files can move. This confuses the user and
can lead to clicking on the wrong file
</description>
<reproduction>
<step>Turn previews on
</step>
<step>Move into a new directory
</step>
<step>Try to perform an action on a file before previews are painted
</step>
</reproduction>
<solution>
There is an option to display previews at the same size as file icons.
This option should be enabled by default.
</solution>
</issue>
<issue severity="high">
<title>
Too many entries in RMB menus
</title>
<description>
Konqueror RMB items have far too many entries.
Right-clicking on:
a directory icon in a directory gives a menu with 20 entries.
a file icon in a directory gives 15-20 entries.
whitespace in a directory gives 18 entries.
whitespace in a webpage gives about 17 entries.
a linked image in a webpage gives 21 entries
a link in a webpage gives 18 entries
an image in a webpage gives 19 entries
with frames in webpages these numbers become even larger.
Too large menus are confusing to the user. This contradicts the KDE style guide:
"To be user friendly, software must be... task-suitable:
Don't offer so much functionality that it confuses the user or harms \
functionality."
</description>
<reproduction>
</reproduction>
<solution>
Ruthless weeding.
The following items should definitely go, IMO:
"Stop animations"
"View document source/info" EXCEPT where there are multiple frames (because then \
it's necessary) "Security"
"Set encoding"
"Select all"
"Create directory"
All of these are applicable to the web page in general
and do not need, IMHO, separate actions for each frameset (e.g. a single security \
dialog should show security info for the whole page, including all frames)
The following items should probably be changed:
"Open in background tab", "Open in new window", "Open in new tab". These should be \
replaced by a single entry. This could be configurable to be "new \
window/tab/background tab" via the settings dialog. "Forward" item should be removed \
when it doesn't apply, rather than blanked out. I know this goes against the style \
guidelines, but the RMB menu is so dynamic anyway that I don't think it matters. \
"Move to trash", "delete". I suggest again, these should be merged and an option made \
available to "move files to trash on delete" (although it shd be made clear that this \
applies to local filesystem only, or whatever the rule is)
"Copy to" and "move to". There should not need to be more than one method for \
copying and pasting on the RMB menu. IMHO the quick copy plugin is a workaround for \
the fact that Konqueror is too slow to use comfortably for normal file management \
tasks. In addition, it strongly violates the prohibition on deeply nested submenus.
"Open terminal here". Unless someone grumbles, I suggest that we ditch this, at \
least from the RMB.
With these changes, we would still have big context menus, but we would be \
returning to sanity :-)
</solution>
</issue>
<issue severity="medium">
<title>
No close buttons on sidebar, tabs, views
</title>
<description>
The sidebar, tabs and views (as in "split left/right" of Konqueror do not have close \
buttons. They can't be closed without either using a RMB, or a menu item.
In all these cases, there is plenty of screen real estate available for a close \
button. In fact, "views" utilize chrome to provide (1) a little green button for \
"active" and (2) a "lock view" checkbox, the semantics of which are obscure and its \
usefulness, I respectfully submit, doubtful.
Closing part of a view is pretty basic. In the case of tabs, it is implemented by \
both Mozilla and Galeon, and has been requested by several Konqueror users. \
</description> <reproduction>
<step>
</step>
</reproduction>
<solution>
Put close buttons in. There is a subissue with tabs - do we have one close button \
for the active tab, or one per tab? I don't have strong feelings about that. \
</solution> </issue>
<issue severity="critical">
<title>Slowness
</title>
<description>Konqueror is slow to start up, like all KDE apps. For web browsing \
this is not serious, but for everyday file management, it forces me to use the \
command line.
</description>
<reproduction>
<step>
Turn all the eye candy off, turn on the option to have spare copies of konqueror in \
the background, turn on "minimize memory usage". </step>
<step>Click on your home icon</step>
<step>Time how long it takes for a window to appear. On my PII 366 it is about \
10-15 seconds</step> <step>Try just opening a new window once konqueror has started \
with Ctrl+N. On my box: still 4 seconds
</step>
<step>Now try the same thing on Windows.</step>
</reproduction>
<solution>
Start up times are a well-known issue for all KDE apps. I flag them here because \
for file browsing and web browsing it is particularly important. I browse the web, \
and my file system, probably 50+ times each day. That is a lot of wasted time at \
10-15 seconds a shot.
I know that people are trying to optimize KDE, and indeed Linux and GCC. However, \
it is possible that these things still don't do enough. In that case, I think we may \
have to look at really radical solutions.
I for one would rather have a slimmed-down filemanager that started on time, than a \
"do everything" solution that I have to wait for. </solution>
</issue>
<issue severity="low">
<title>Oblique directory icons
</title>
<description>
It's a tiny detail, but all major icon themes for KDE have directories shown \
obliquely (as diamonds) rather than straight on (as rectangles). I think this tends \
to break up the flow of an icon view. </description>
<reproduction>
</reproduction>
<solution>
Rectangles would be easier on the eye. Just my 2c.
</solution>
</issue>
<issue severity="low">
<title>Square icons not aligned in multicolumn view
</title>
<description>Using multicolumn view, and the default Crystal icons, the left hand \
side of icons and previews are not aligned. This breaks up the flow of the column \
down the page. </description>
<reproduction>
<step>Change to multicolumn view
</step>
<step>Look at a directory which has many different text file types in it</step>
</reproduction>
<solution>
For icons and previews which have a square "document" component, the left hand of \
the square should always be at the same place. I.e. the "type" part of the icon \
should not jut out to the left at all. </solution>
</issue>
<issue severity="medium">
<title>Configure toolbars has confusing entries
</title>
<description>
The "configure toolbar" dialog has confusing entries
such as <Merge> and ActionList:viewMode_toolbar.
These are obscure and removing them is dangerous.
</description>
<reproduction>
</reproduction>
<solution>
We need to find a way to hide the implementation details of merged toolbars from \
the user. Or to present it in a way that the user can understand and control.
I don't understand the details of the underlying implementation myself. As a \
workaround, I suggest (1) replacing the strange non-english entries with something \
like "dynamic list" and (2) making it non-removable and greying it out to indicate \
this. </solution>
</issue>
<issue severity="high">
<title>
Confusing menu items
</title>
<description>
Konqueror has lots of cool features. However, some menu items are confusing and \
need rethinking. This issue goes with the "Confusing menu layout" issue in the same \
report.
* "Un/lock view" and "link view". These are dealt with in a separate issue of their \
own.
* "Use index.html". Do many people use this? It seems to have been imported from \
the world of Apache.
* Applications/Trash/Templates/autostart in the "Go" menu. "Applications" can be \
edited using the K menu editor; "Trash" can be visited by clicking the trash can on \
your desktop. "Templates" - I have no idea what these are or how a normal user would \
possibly gain anything from visiting them. "Autostart" applications would best be \
edited by a kcm module - this would enforce a correct separation between interface \
and implementation. (Will autostarting apps always b*e implemented by putting links \
in a folder?)
* Tools. Many of these plugins are cool, but specialized. Most users do not need to \
validate a dom tree or execute a shell command.
* Settings. "View properties saved in directory"; "remove view properties". Very \
hard to understand, as you can tell from the length of the menu text. </description>
<reproduction>
</reproduction>
<solution>
I suggest the following:
* "Use index.html": I suggest ditching it entirely; if that is too radical, \
perhaps we could move it to the settings menu. (There's little point having this \
option just for a specific directory - after all, you could just click on the \
index.html page if that's what you want. So if it's there, it should apply to all \
directory views. If so, it can be configured once off, in the \
settings dialog.)
* The "Go" items: ditch them.
* Tools: all turned off by default, except maybe "create image gallery". \
(Everyone's got porn.)
* "View properties saved in directory": definitely one for the settings dialog. \
"Remove view properties": no need for it. Just have either per-directory settings, or \
overall settings. </solution>
</issue>
<issue severity="high">
<title>Confusing menu layout
</title>
<description>
I've used Konqueror for 2 years and still regularly go
for the wrong menus.
Specifically:
- "Views" are created in the "Window" menu, not the View menu. But "View profiles" \
are saved in the "Settings" menu. OTOH, views are "locked" in the view menu. And \
"view filters" are in the tools menu!
- Opening a terminal is in the "tools" menu. So is the embedded find file command. \
But the terminal emulator is in the "Window" menu.
- "Most often visited" is in the "Go" menu, I suggest that this has more affinity \
with "Bookmarks"
- There's no "File" toolbar.
</description>
<reproduction>
</reproduction>
<solution>
I can actually see the underlying rationale behind some of these choices - for \
example, Konqueror deals with "locations", not just "files", so replacing "File" with \
"Location" makes sense. However, I think that we have ended up with a mess. Part of \
the solution lies in changing the menu items themselves (see another issue in this \
report). We could also reorganize the menus, however. My suggestion:
"File" menu
- much as "Location" now. I just think users are used to "File".
- This menu should contain stuff related to the current URL. See "View below"
"Edit" menu
- "Find file" should be moved here. I think having the two find actions on one \
menu will be less confusing. In fact, consider having a single find action, which \
defaults to "find within text" when text is being viewed, and "find file" when a \
directory is being viewed. "View"
- all items related to how we look at the current view. Move "view source", \
"document info" and "security" to "File", as they relate to the URL itself, rather \
than to a "way of looking at it". "Bookmarks", "Tools"
- as now. "Terminal emulator" should be in tools.
"Settings"
- as now. Rename the "view profiles" concept to "browsing profile" or "konqueror \
profile". This will remove the vocabulary confusion with the "view" menu. "Window"
- as now. Rename "views" (==subwindows of a main window) as "panes" (chimes with \
"window").
This is obviously just a starting point for discussion - in many ways this is very \
subjective. Check out Galeon, IE and Mozilla for different ideas.
</solution>
</issue>
<issue severity="low">
<title>Locking and linking views is confusing
</title>
<description>
The ability to split views is cool. Konqueror also has a feature whereby 2 views \
can be linked, so that moving in one view automatically moves in the other; and where \
one view can be locked so that it never actually moves.
The idea behind this (I think) is that you can link two views, then lock one so \
that clicking on your left view will actually show the new location in your right \
view.
However, the semantics are confusing. I can't think of any reason to link views, \
unless one view is locked (why would you want two identical views of the same thing? \
If you want to move something within a directory, this can be done without having two \
views - unless it is difficult to scroll around while using drag and drop, in which \
case that issue should be dealt with anyway.) Equally, locking a view is only useful \
if another view is linked to it.
</description>
<reproduction>
</reproduction>
<solution>
These two actions mostly make sense together, so let's put them together. Have a \
single action whereby one view is made the master. This view is locked and can be \
linked to another view which is the slave. Clicking in the master view alters the \
slave view. (By default all other open views would be "slave views")
OTOH, this still sounds confusing to me. The radical alternative is: we now have a \
sidebar with a tree view; this is perfectly good enough for advanced file management; \
let's ditch the whole concept of linked views. </solution>
</issue>
<issue severity="medium">
<title>
Window panes (views) don't respect window behaviour settings WRT mouseover
</title>
<description>
If I change my window behaviour settings to "focus follows mouse", I would expect \
this to apply to konqueror views also - the one with the mouse in gets activated. \
However, konqueror views are always "click-to-focus" </description>
<reproduction>
<step>Change your window behaviour to "focus follows mouse"</step>
<step>Open a konqueror window with two panes (views).
</step>
<step>Move the mouse over the panes.</step>
</reproduction>
<solution>
I suspect there are horrible underlying issues here, but if possible, could we have \
views becoming active according to the window behaviour settings? This actually also \
applies to e.g. Kate split windows. </solution>
</issue>
</report>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://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