[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-06-22 17:46:44
[Download RAW message or body]
A while back me and some others put together an XML usability report for
Konqueror, and I submitted it to the usability.kde.org website. I looked
there recently and couldn't find it. Did it just vanish into the ether?
In any case, here it is and I am thinking that I would like to start
hacking in some of the simpler proposed changes, and submitting patches
to the developers. Is there anything in the existing report that you
would change or add?
Dave
["konqueror-usability-report-merged.xml" (konqueror-usability-report-merged.xml)]
<!DOCTYPE report SYSTEM "http://usability.kde.org/DTD/kde_usability_report.dtd">
<report date="">
<author name="David Hugh-Jones" email="hughjonesd@yahoo.co.uk" />
<author name="Philippe Fremy" email="pfremy@kde.org" />
<author name="Gerhard Hoogterp" email="gerhard@frappe.xs4all.nl" />
<application name="Konqueror" version="3.1" />
<os name="Linux" />
<interface name="KDE" />
<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>
<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>
<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="high">
<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>
<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>
<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>
<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>
<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>
<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>
<issue severity="medium">
<title>
Dumb bookmark navigation panel
</title>
<description>
The navigation panel can display bookmarks. The interface is very
similar to the bookmark editor, but it does not allow to manage
bookmarks.
Other browsers like Mozilla and Opera use this panel to manage
bookmarks. User will expect this kind of behaviour too. And the look
is not much different from the bookmark editor.
</description>
<solution>
Improve the bookmark panel so that it is more intelligent and allow to
manage bookmarks. In Opera, this panel is the only way to manage
bookmarks. In mozilla, you can use this or use the bookmark editors.
I suggest to:
- allow bookmarks to be moved and reordered directly in the panel
- allow bookmarks to be edited using a rmb menu 'properties'
- allow to add new folders with a link, like in the bookmark menu
entry
A problem arise because this bookmark panel is a one-click panel. If
you try to drag the bookmark, konqueror will assume it is clicked. It
should clearly distinguish between the two actions. Activating
bookmark only on mouse button release, would probably do
the trick.
</solution>
</issue>
<issue severity="low">
<title>
Drag'n drop of the location bar onto itself duplicates the URL
</title>
<description>
If by accident, the user starts to drag the URL from the location bar
and stops immediately, the URL is appended to itself in the location
bar. The url then does not work anymore.
</description>
<solution>
Detect that the dropped URL is the same as the one dispalyed, and don't do
anything.
</solution>
</issue>
<issue severity="medium">
<title>
Dropping text into the Location bar inserts text in the middle of the
URL
</title>
<description>
If the user is dragging some text containing an URL (for example
dot.kde.org typed into a konsole) into the location bar, a vertical
cursor is shown to make clear were the text will be inserted inside
the current URL. If the user drops the url text in the middle of the
URL, the text is being inserted in the middle of the URL.
But in this case, the user was expecting the URL to be replaced by the
new one he is dropping.
</description>
<solution>
Solution 1: detect if the text being dropped is an URL (begins with
http, www, ...). In that case, do not display the vertical cursor and
clear the location bar before dropping the text. The problem is that
you will never be able to fully detect an URL, especially if you add
the special search keywords that konqueror supports ("gg: blah"). This
is why I prefer solution 2.
Solution 2: if the user is dropping some text in the location bar,
this is certainly something that konqueror understands. So do
not display a vertical cursor and clear the location bar when dropping
the text. This would work with the URL dropped from konsole.
</solution>
</issue>
<issue severity="low">
<title>
Dropping text onto the Location bar label is not possible
</title>
<description>
If I have an URL as text (taken from konsole for example), the
location bar label does not accept it as a drop location. This is
inconsistent with the fact that the location bar label accepts URL.
</description>
<solution>
The location bar label should accept text for the location bar, just like
it accpets URL. The text dropping scheme of the location bar described
previously should apply as well.
</solution>
</issue>
<issue severity="high">
<title>
Can not drop URL onto the bookmark navigation panel.
</title>
<description>
Dragging an URL from the location bar to the bookmark navigation panel
is not allowed. This problem is marked as high because this is the way
mozilla and netscape manages the bookmarks. Users coming from these
program will be highly frustrated.
</description>
<solution>
Allow bookmark edition within the bookmark navigation panel, and allow
to receive bookmarks.
</solution>
</issue>
<issue severity="low">
<title>
Can drop a bookmark folder into the location bar
</title>
<description>
It is possible to drag and drop a bookmark folder onto the location
bar and label, although it does not do anything.
</description>
<solution>
Refuse the drop of a bookmark folder in the location bar and label.
</solution>
</issue>
<issue severity="medium">
<title>
No feedback when clicking on a bookmark
</title>
<description>
There is a delay when the user clicks on a bookmark in the navigation
panel and when the window changes to load the new page. If a page is
already being loaded, this delay can be long (few seconds) and the
user has no feedback that its click on the bookmark was accepted.
</description>
<solution>
Provide an immediate feedback when konqueror is asked for a new
location, like turning the cursor into the wait cursor, or displaying
something in the status bar ("opening www.blah.org"). That way, the
user knows that what he has asked for is being taken into account.
</solution>
</issue>
<issue severity="high">
<title>
Konqueror allows unknown bookmarks to be added.
</title>
<description>
Some web pages do not provide title. If the user adds such a page to
his bookmark file, it is added as 'Unknown'. Not very helpful,
especially if you have many of them.
</description>
<solution>
If the web page has no title, propose the user to supply a label for
this bookmark.
</solution>
</issue>
<issue severity="medium">
<title>
Allow user to edit URL title when adding them to bookmark.
</title>
<description>
By default, Konqueror uses the title of the page being displayed as a
bookmark name. However, this title is often not suitable for
a bookmark. It may be too long or not precise enough. In many cases,
the user needs to edit it. It must then open the bookmark editor,
click its bookmark, change the name, save the bookmark editor, quit
it. That's too much for such a simple and common operation.
</description>
<solution>
If the bookmark navigation panel allows to edit the bookmark names, it
will help with this problem. But the real solution is to propose the
user to edit the name of the bookmark he adds.
Please note that Apple does that with its Safari browsers. If Apple
does it, there is usually a very good reason for it.
</solution>
</issue>
<issue severity="low">
<title>
Dragging text of an URL on the Konqueror icon does not work.
</title>
<description>
If the user has a text representing an URL (let's say dot.kde.org) in
a konsole, he can not drag it to the Konqueror icon of Kicker, the
drop is refused. This works however if the user is dragging a URL.
But the distinction between "this text is an URL because an
application know it is an URL" and "this text is only text although it
has the same content as an URL" does not make sense for a user.
</description>
<solution>
Let Konqueror accept text drop and try to open the text whatever it
is. It is not possible to recognise if the text is something konqueror
understands or not, since konqueror understands so many syntax. So
just assume the user knows what he is doing.
</solution>
</issue>
<issue severity="low">
<title>
Bad URL icon in the bookmark editor.
</title>
<description>
When using the bookmark editor, if one adds an URL manually (by typing
it), a default icon is provided. However, this contrasts with the nice
icons that are provided when you bookmark the URL using the Konqueror
menus. This is confusing for the user, who does not understand why
some bookmarks have a nice icon and some have not.
</description>
<solution>
Possible solutions are:
1. When the user adds manually the URL, try to open it and fetch the
icon. Do not report any error in case of failure (RTC connection for
example).
2. When the user adds manually the URL, ask if he wants to fetch the
icon for this URL.
3. Provide a button 'scan all URL' that would open every URL, check
that they are still working, and update the icon for each URL. This
could open ideas for new features.
4. The first time the user uses this bookmark, update the URL icon.
5. When saving the bookmark file, find the URL that do not have any icon
and ask the user if he wants to find the icon for these URL.
</solution>
</issue>
<issue severity="medium">
<title>
"Cache policy" does not mean anything to a user.
</title>
<description>
Many browser have an 'Offline browsing mode' which exactly says what
it does. Konqueror too, however, this is hidden under 'Cache policy'.
Many users do not know what is a Cache, nor expect to find a feature
such as Offline browsing hidden in such a setting.
</description>
<solution>
We have here two different settings. Cache policy ("Use cache if
possible / keep cache in sync") is something you choose once and don't
change. Its right place is in Konqueror settings and nowhere else.
Offline browsing mode is something the user may use (i.e. switch)
often, on a per-session basis. It should hence be easily accessible
and easy to switch.
-> remove the cryptic "Cache policy" from the button "html settings" and
replace it with a checkable value "Offline browsing mode"
-> remove the "Offline browsing mode" from konqueror settings because
this is something the user wants to control on a session by session basis.
-> provide an easy way to switch the offline/online browsing mode. I
see it fit in the 'settings' menu. I have heard other browsers provide
a small plug in the right-hand bottom corner of the window to
display the state of the browsing mode.
</solution>
</issue>
<issue severity="low">
<title>
Can not easily adjust Java / Javascript policy
</title>
<description>
If you want to enable Java for a given site, you must open manually
the Konqueror settings and add the site by typing its name. Quite
tedious. The same applies to Javascript.
This contrast with the cookies settings which is very verstile. The
user expects the same level of fonctionality from cookies, Java and
Javascript.
</description>
<solution>
Provide the same interface for enabling/disabling Java, Javascript,
Cookies and Javascript popup. This will provide the user with a
unified comprehensive interface [ and it can probably share the same
code ]
This means to detect when a webpage is trying to use Java or
Javascript. If the user has chosen the policy of asking, ask him what
he wants to enable. This should be asked in a single dialog if
possible, even if he has to choose the setting for both Java and
Javascript, because popping dialogs is annoying.
</solution>
</issue>
<issue severity="medium">
<title>
Can not switch between tab using keyboard.
</title>
<description>
In Konqueror, when the user has many tab open, he sometimes wants to
switch quickly from one to another, without using the mouse. There is
no way to do that.
Opera and Mozilla provide a keyboard shortcut for this.
Update: It is possible to switch from one tab to another using CTRL-[
and CTRL-]. While this may appear as a good idea on an american
keyboard, this is completely useless on a french keyboard where you
already have to use a modifier (ALT-GR) to access the signs '[' and
']'.
</description>
<solution>
The first thing to do is to use something that does not rely on special
characters to switch between tab. Only modifiers and cursor or
function keys should be used for such a features.
KDE has to agree on a standard way of switching MDI windows and
implement it widely. Right now, Konqueror is one inconsistent app
amongst ksirc, kopete and konsole.
Right now however, it is possible to support both the mozilla and
opera way because these shortcuts are not taken within konqueror. I
suggest to do it.
</solution>
</issue>
<issue severity="medium">
<title>
No easy way to close a tab
</title>
<description>
Closing an open tab in Konqueror is a an action performed very often.
The user should be able to do it with one click. By default the 'close
tab' button is not available in toolbar. So the user has to edit the
toolbar, find the close tab button, add it, save the toolbar settings.
Besides, Mozilla and Opera both provide a close button at the right of
the tab row, to close the tab. This is a place where the user finds it
easily.
</description>
<solution>
The first step is to add the 'close tab' to the default konqueror toolbar.
Then, one need to think about the tab interface. I think the mozilla
one is quite good. With an open tab and a close tab button directly in
the tab bar, the user finds it very easily.
</solution>
</issue>
<issue severity="medium">
<title>
No feedback when opening a tab
</title>
<description>
There is a delay between the moment where the user middle clicks on a
link and the moment where a new tab is opened. This delay can extend
to a few seconds.
The user does not now if his tab is being opened or not. If he clicks
quickly on multiple links (typical case, in a google search, he wants
to open many links at once), only one of all the link is open in a new
tab [ this is a bug ].
</description>
<solution>
The new tab should be created as soon as the user middle-clicks on the
link, to provide a visual feedback. If this is not possible, turn the
cursor into a wait cursor, to notify the user that something is going
on.
</solution>
</issue>
<issue severity="low">
<title>
No feedback about loading progress in tab.
</title>
<description>
In the typical case of an image gallery, the user can open many tabs
with an image in each. In that case, each tab will take a few seconds
(sometimes a few minutes) to load. There is no feedback about which
tab has finished loading. The user has to switch between all tabs to
know their completion status.
</description>
<solution>
Mozilla address this problem by displaying an animated loading icon
(two arrows cirling) in the tab that are being loaded. I like the
concept but it could be improved. I suggest to use a pie chart in the
the tab. The percentage of the page loaded would be represented by the
pie turning into a full disc, and fading from red to green. Having an
animation would also be a good idea because you notice easily when
something stops being animated.
Another solution is to fill the name of the tab with a plain progress
bar, in the background. I don't remember which browser does that, but
I don't think it is a good idea because it reduces readability.
</solution>
</issue>
<issue severity="medium">
<title>
Tabs operations are hidden in the window menu.
</title>
<description>
The user does not know that Konqueror has tab browsing because nothing
is available in the Location menu [ it happened to me, really! ].
The location menu is the right place to put the tab operation, because
you already have the location/window related operation (open in new
window, ...). This is also where other browsers have put their tab
operations.
The window menu contains the entries for tab operations, but the tab
operations are not window operation. This remark applies to other
entries of the window menu, which should really be reworked, as
already pointed out.
</description>
<solution>
Rearrange the Konqueror menus. Tabs really belong to the menu
location. Most of the other settings of window probably belong to
view.
</solution>
</issue>
<issue severity="high">
<title>
Tabs are hidden when many are open
</title>
<description>
When the user opens many tab in konqueror, some tabs are hidden and
the user must use the buttons < and > to navigate between tabs.
It has the following bas consequences:
- it is difficult to navigate from tab to tab because some of them are
hidden.
- the scroll buttons are quite small and difficult to use.
- it is not possible to go easily from last tab to first tab and the
opposite. This require many manual operations.
- it is unclear if clicking the button will scroll one tab, one screen
of tab or just a small amount of space.
- the user does not know how many tabs are open
</description>
<solution>
To address this problem, the solution of mozilla is to make all tab
fit in the displayed row, by shrinking the size of the tab if
necessary. This is better than the choice of Konqueror because the
user had full control and view on all his tab. However, for a big
number or tab, none of them is readable because only a tiny part of
the tab is visible. I find this solution a lot better than the current
one.
Another solution is to stack tab into multiple rows when they do not
fit into one row. It is usually described as a bad idea usability-wise
to have many tab rows, but this advice is applied to a setting
panel. In this case, we differ from a setting panel because the user
is the one who has requested all these tabs. So the appliation is not
overwheelming the user, he is in control.
Using multiple rows of tab would provide an easy way to access every
open page (the goal of tab) while still allowing the user to read the
content of a tab title and close them if desired.
</solution>
</issue>
<issue severity="medium" bugreference="46855">
<title>Konqueror's history option is not very useful</title>
<description>
Showing only domainnames in the history window limits the usability to those \
sporadic cases
where one happens to remember the domainpart of the url. Sorting on date doesn't \
help a lot as
the date or the number of days or any other usefull indication of age is not \
shown. </description>
<solution>
Show page titles. Group them per day. Check mozilla's history and take the good \
ideas. Add (simple) search option or even better, a filter option or both.
</solution>
</issue>
</report>
_______________________________________________
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