--=-qDGejI52Ya2n1Bf2B2hw
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


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


--=-qDGejI52Ya2n1Bf2B2hw
Content-Disposition: attachment; filename=konqueror-usability-report.xml
Content-Transfer-Encoding: quoted-printable
Content-Type: text/xml; charset=ISO-8859-1

<report date=3D"">
	<author name=3D"" email=3D"" />
	<application name=3D"Konqueror" version=3D"3.1" />
	<issue severity=3D"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 us=
ers.
		</description>
		<reproduction>
		</reproduction>
		<solution>
		Remove the button by default.=09
		</solution>
	</issue>
=09

	<issue severity=3D"medium">
		<title>
		Using previews causes icons in dirview to move =09
		</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
	=09
		</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>
=09
		<issue severity=3D"high">
		<title>
		Too many entries in RMB menus
		</title>
		<description>
		Konqueror RMB items have far too many entries.
	=09
		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
	=09
		with frames in webpages these numbers become even larger.
	=09
		Too large menus are confusing to the user. This contradicts the KDE style=
 guide:
		"To be user friendly, software must be... task-suitable:=20
		Don't offer so much functionality that it confuses the user or harms func=
tionality."
	=09
		</description>
		<reproduction>
		</reproduction>
		<solution>
		Ruthless weeding.
	=09
		The following items should definitely go, IMO:
		"Stop animations"
		"View document source/info" EXCEPT where there are multiple frames (becau=
se then it's necessary)
		"Security"
		"Set encoding"
		"Select all"
		"Create directory"
	=09
		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)
	=09
		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 blank=
ed 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 r=
ule is)
	=09
		"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 w=
orkaround for the fact that Konqueror is too slow to use comfortably for no=
rmal file management tasks. In addition, it strongly violates the prohibiti=
on on deeply nested submenus.
	=09
		"Open terminal here". Unless someone grumbles, I suggest that we ditch th=
is, at least from the RMB.
	=09
		With these changes, we would still have big context menus, but we would b=
e returning to sanity :-)
	=09
	=09
		</solution>
	</issue>
=09
	<issue severity=3D"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 h=
ave close buttons.  They can't be closed without either using a RMB, or a m=
enu item.
			=09
In all these cases, there is plenty of screen real estate available for a c=
lose 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 implemen=
ted 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 clos=
e button for the active tab, or one per tab? I don't have strong feelings a=
bout that.
		</solution>
	</issue>
=09
		<issue severity=3D"critical">
		<title>Slowness
		</title>
		<description>Konqueror is slow to start up, like all KDE apps. For web br=
owsing this is not serious, but for everyday file management, it forces me =
to use the command line.=20
=09
		</description>
		<reproduction>
		<step>
		Turn all the eye candy off, turn on the option to have spare copies of ko=
nqueror 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
=09
		</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 ca=
se, I think we may have to look at really radical solutions.=20
	=09
		I for one would rather have a slimmed-down filemanager that started on ti=
me, than a "do everything" solution that I have to wait for.=20
		</solution>
	</issue>
=09
		<issue severity=3D"low">
		<title>Oblique directory icons
		</title>
		<description>
		It's a tiny detail, but all major icon themes for KDE have directories sh=
own obliquely (as diamonds) rather than straight on (as rectangles). I thin=
k this tends to break up the flow of an icon view.=20
		</description>
		<reproduction>
		</reproduction>
		<solution>
		Rectangles would be easier on the eye. Just my 2c.
		</solution>
	</issue>
=09
		<issue severity=3D"low">
		<title>Square icons not aligned in multicolumn view
		</title>
		<description>Using multicolumn view, and the default Crystal icons, the l=
eft hand side of icons and previews are not aligned. This breaks up the flo=
w of the column down the page.
		</description>
		<reproduction>
		<step>Change to multicolumn view=20
		</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" par=
t of the icon should not jut out to the left at all.
		</solution>
	</issue>
=09
	<issue severity=3D"medium">
		<title>Configure toolbars has confusing entries
		</title>
		<description>
		The "configure toolbar" dialog has confusing entries
		such as &lt;Merge&gt; and ActionList:viewMode_toolbar.
		These are obscure and removing them is dangerous.
	=09
		</description>
		<reproduction>
		</reproduction>
		<solution>
		We need to find a way to hide the implementation details of merged toolba=
rs from the user. Or to present it in a way that the user can understand an=
d control.
	=09
		I don't understand the details of the underlying implementation myself. A=
s a workaround, I suggest (1) replacing the strange non-english entries wit=
h something like "dynamic list" and (2) making it non-removable and greying=
 it out to indicate this.
		</solution>
	</issue>
=09
=09
	<issue severity=3D"high">
		<title>
		Confusing menu items
		</title>
		<description>
		Konqueror has lots of cool features. However, some menu items are confusi=
ng 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 issu=
e of their own.
		* "Use index.html". Do many people use this? It seems to have been import=
ed 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. "Auto=
start" applications would best be edited by a kcm module - this would enfor=
ce a correct separation between interface and implementation. (Will autosta=
rting apps always b*e implemented by putting links in a folder?)
		* Tools. Many of these plugins are cool, but specialized. Most users do n=
ot 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 tex=
t.
		</description>
		<reproduction>
		</reproduction>
		<solution>
		I suggest the following:
		 * "Use index.html": I suggest ditching it entirely; if that is too radic=
al, perhaps we could move it to the settings menu. (There's little point ha=
ving 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-dire=
ctory settings, or overall settings.
		</solution>
	</issue>
=09
		<issue severity=3D"high">
		<title>Confusing menu layout
		</title>
		<description>
		I've used Konqueror for 2 years and still regularly go
		for the wrong menus.
	=09
		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.
	=09
		- "Most often visited" is in the "Go" menu, I suggest that this has more =
affinity with "Bookmarks"
	=09
		- There's no "File" toolbar.
	=09
		</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 repla=
cing "File" with "Location" makes sense. However, I think that we have ende=
d up with a mess.
		Part of the solution lies in changing the menu items themselves (see anot=
her 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".=20
			- This menu should contain stuff related to the current URL. See "View b=
elow"
		"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.=20
		"View"
			- all items related to how we look at the current view. Move "view sourc=
e", "document info" and "security" to "File", as they relate to the URL its=
elf, rather than to a "way of looking at it".
		"Bookmarks", "Tools"
			- as now. "Terminal emulator" should be in tools.=20
		"Settings"
			- as now. Rename the "view profiles" concept to "browsing profile" or "k=
onqueror profile". This will remove the vocabulary confusion with the "view=
" menu.
		"Window"
			- as now. Rename "views" (=3D=3Dsubwindows of a main window) as "panes" =
(chimes with "window").
		=09
	=09
	=09
		This is obviously just a starting point for discussion - in many ways thi=
s is very subjective. Check out Galeon, IE and Mozilla for different ideas.
	=09
		</solution>
	</issue>
=09
	<issue severity=3D"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 th=
e other; and where one view can be locked so that it never actually moves.
	=09
		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.
	=09
		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 o=
f the same thing? If you want to move something within a directory, this ca=
n be done without having two views - unless it is difficult to scroll aroun=
d 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.
	=09
	=09
		</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 loc=
ked and can be linked to another view which is the slave. Clicking in the m=
aster view alters the slave view. (By default all other open views would be=
 "slave views")
	=09
		OTOH, this still sounds confusing to me. The radical alternative is: we n=
ow have a sidebar with a tree view; this is perfectly good enough for advan=
ced file management; let's ditch the whole concept of linked views.
		</solution>
	</issue>
=09
=09
	<issue severity=3D"medium">
		<title>
		Window panes (views) don't respect window behaviour settings WRT mouseove=
r
		</title>
		<description>
		If I change my window behaviour settings to "focus follows mouse", I woul=
d 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, cou=
ld we have views becoming active according to the window behaviour settings=
? This actually also applies to e.g. Kate split windows.
		</solution>
	</issue>
	=09
</report>
--=-qDGejI52Ya2n1Bf2B2hw--

__________________________________________________
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