Sebastian Biot looks at KDE Usability in the first of a series of studies. "While some participants noted that KDE looked different from Windows, none seemed bothered by the differences and the look-and-feel of KDE. Users identified all the elements of the interface without any trouble including KDE's Konqueror and KMail icons. Most users seemed to understand the K menu's presence and function intuitively and they used it much more than I had anticipated. This test conducted in early July 2002 with four participants outlines of some of KDE 3.0's shortcomings including inconsistencies in KFileDialog and the difficulties of working with Konqueror's embedded viewers." It's good to see people stepping up to do this kind of work -- the good news is that discussion of the study has already been started (kde-usability, kde-cafe).
Comments
Just to make sure everybody understands: this can hardly be called a usability study.
Rather, it's a test of how well KDE conforms to what the user is used to.
KDE could have the worst UI in existence, but if these users had been used to that UI, they'd have done better than they did.
No, user familiarity with a given interface shouldn't be discounted. But, yes, just because they're used to something doesn't mean it's better.
Tab-completion, for instance, has got to be the closest any user interface has come to reading a user's mind. If there was some way to work that into a UI ... :)
Mozilla just got a new feature: link-text autocomplete. Start typing the text of the link you want to go to, and it progressively looks through the document to match a link text to the stuff you're typing. That's neat :)
Maybe soon we will see totally new concepts of the desktop
or user interface for KDE, based upon everything else that is
also KDE.
Wouldn't it be possible to ask the user during the installation whether (s)he wants a Windows like or an Unix like environment.
Windows like would mean:
- double-clicking behavior
- login as root by default
- Ctrl-V/Ctrl-C cut-n-paste
- no need to mount or unmount anything
...
Unix like would mean:
- single-click behavior
- login in as user
- X-Windows cut-n-paste
- mount and unmount
...
I think that would be the easiest way to serve both groups.
Cheers
Lukas
KDE has already something like this and it is well done.
To extend this to the whole system is just stupid. I like to use double click with KDE as I have not yet figured out our to make efficient selection with the one click option. But I will never used my PC logged as root for normal work. And the way KDE handle clipboard since QT3 is perfect.
HOWTO select icons without clicking:
Go to Peripherals/Mouse in the Control Center
Check 'Automatically select icons' under the header icons.
In windows this is the default, if you enable Single-click in windows. By the way, single-click has been in windows since Windows 95. It was an extention to Internet Explorer.
Good luck, Jos
I think the average Win98 user expects to be root maybe even without entering a password and I think there are good reasons for that. Logging in as user makes certain tasks more difficult and the only reason for this is securety. However, the average Win98 user doesn't gain much securety by logging in as user. I mean reinstalling my system costs me about an hour of work but loosing all the data in my home directory would be a real problem. But if for instance a virus would attack my system it wouldn't make any difference if I'm just a user or root on my system. In any case the virus could delete my personal data.
Not if you have a special account just for surfing...
Yes, but that doesn't mean that your default working account can't be root.
Default login of "root" should NEVER be considered in any Unix-like operating environment. Root simply leaves the user, and the user's system, entirely too open to external action that could be injurious or user mistakes that could be at the very least, frustrating. Root should be available, a desktop should never default to root.
Because Unix interface sounds 'difficult & foreign interface'. It should be something that a power user can switch.
Call it:
Simple interface
vs
Improved Unix interface
vs
Legacy Windows interface
This would put clear that the first should be better than the other
Simple interface
Should have a simplified KControl, single-click to launch apps, drag to
select, no terminal on Kicker.
Improved Unix interface
Complete KControl, single-click, terminal easy to reach, etc
Legacy Windows interface
Exactly the same as Win98 default. This can be useful for people which have to switch frecuently, for people who are old win users and don't like to change, etc
Put an easy way change on this on KC, and to save a configuration to "return" in case of exploring alternatives.
No no no. Unix is a unique O/S and should never be made like Windows!
He's saying that there should be an option to make all the configurations "Windows like" - which makes sense to me. I've seen plenty of KDE desktops arranged like Windows, Mac or NeXT desktops. It's the same thing as chaging a style and window decoration, only deeper - keystrokes, kicker layout and configuration, menubar setting, etc... all would change.
Having these options would also be nice for another reason - you could have "KDE Simplified", "KDE Poweruser", "Windows Style", "Mac Style", "NeXT Style", "Amiga Style" and "Integrate with OSX" for people running KDE under OSX, so that Kicker avoids the Dock, keystrokes mirror OSX conventions, etc.
--
Evan (Who tossed in Amiga style for a friend who is a Workbench diehard)
> - login as root by default
Are you nuts?! o_0
We should *not* encourage insecure usage, no matter how "userfriendly".
> Unix like would mean:
> - mount and unmount
/me looks down and shakes head
Having to tell the computer when you've inserted removable media in a drive is *bug*, not a feature.
--
Simon
Here-here, Simon!
If the default is supposed to be single click, would it not make sense to catch double clicks anyway and pop an error dialog to explain the situation and indicate ways in which it can be customized?
Yes, this would actually help people. It's the same behavior of ICQ: if it's configured to use the left mouse button, it displays a help dialog box when you try to use the right button.
Sounds good to me, just be sure there is a way to disable that dialog box after seeing it the first time :-)
Tim
That is one of the most irritating behaviors I've seen in a program. Now I have to dismiss some condescending dialog box for my apparent wrongdoing. Maybe it should just do nothing. And maybe it should be designed such that a left click is the obvious choice. Or maybe it should default to right click as that is what everyone is doing anyways.
Maybe a hint from what the major web browsers do (don't know if Konqueror does this while browsing) is needed. If you double-click on a link, it ignores the second click. I see people double-clicking on links all the time. Sure they don't completely understand when to single and when to double click, but it doesn't hurt for the most part because of this behavior. In Konqueror (file browsing at least) you end up with two copies of the file open. Almost certainly not what was intended.
Usability is not only a subject for beginners.
Typcal studies create tasks for a beginner a try to assess how they survived.
But they does not care whether the participants understood what they were doing.
This is the typical MS-Windows mistake, which leads to the annoying "we care for you" GUI. One of these mistakes is the attempt to hide the file system.
This lead to my main topic:
The normal (non beginner) user wants to know what goes on in the file system.
As long as you work with your documents everything is fine, because of the clear structure of the "home" directory.
But when you install SW the horror beginns.
An application is spread over whole filesystem, if you try to compile from the sources with no chance of uninstalling.
So the user is afraid of installing because he does not know whats going on.
The alternativ are application directorys, where everthing for an application is stored in one directory.
The ROX-Desktop realised it (http://rox.sourceforge.net/), see the explanation of application directorys on (http://rox.sourceforge.net/appdirs.php3).
Thats what I call usability.
I know that this is a big task to do, but this would also boost the development of new applications, because it will be easier to find beta-tester.
Apps folders was definitely one of my favorite things about the Mac, I have been meaning to try ROX for a while...
Yes very good point. I think that installing/removing software is THE usability issue left to address on the linux desktop. Whenever this is brought up it is always brushed off as a distro issue. Well the distros have not fixed it. Something with kde's size would stand a much better chance at doing it. Go together with gnome and others and set it up like the other standards on freedesktop.org.
The problem as I see it is caused by the lack of distinction between apps and os. Sure we have great tools for managing packages that come with the os (apt, emerge, urpmi) but these tools do not help well for packages a user downloads. Having a common install system for desktop apps that works in parallel to the existing solutions would be nice. This way a user can download a distro independent package and install it without having to worry about the rest of the system. This way my brother could download something like bonsai-buddy, install it in only his account so it does not effect the rest of my system, and then easily uninstall it when he comes to his senses. No root passwords, no dealing with a giant list of packages that he does not understand, and no trying to figure out which package is the right one.
This is also something that I think is holding back commercial application support. Right now for most users the app has to come with the os, or they can't install it. Most distros prefer open source software to ship with, so the commercial apps do not ship with it. So a commercial software company has the choice of a) open source the app to try to get it included with distros, or b) let the user download install the app (limiting to a small group of users from and already small linux user base) or c) don't support linux.
1) KDE is not linux software, KDE is Unix, Linux, BSD, MacOS X and Windows software
2) The independent packaging you are talking about is the goal of the Linux Standard Base. The reason why it's still not working is because it's not that easy
Well, the problem with easy installation of applications not included in ypur distro is that it's the number 1 source for viruses !
I know you'll say that, as long it's not done as root, it is not risked but that's totally wrong !
What's the worse for your brother ? Breaking the whole system or just losing all his work ?
I think that doesn't make any difference for him. Remember that the only thing taht counts for users is their work and their configuration/customization because it's not that hard to re-install the system.
SO I think you just should never trust anyone except your favourite distro's packagers. That's the way to security.
Now, distros have to provide every good apps...
> if you try to compile from the sources with no chance of uninstalling.
make uninstall...
As a result of reading this (and since I remember seeing problems in this area for a long time), I have changed the default settings for embedded viewers in Konqueror.
Only PS, PDF, HTML and images now trigger an embedded viewer, by default.
Anything I missed?
(The article mentions mp3s, but I think separate apps do the job better
for those, don't they? Monopolizing a whole konq window for an mp3 player's slider looks like a waste of screen space)
Of course it's still possible for any user to change those settings in the File Association dialog, to preview them in Konqueror (even for koffice files).
Note that the "right click paste" bug is already fixed in CVS too.
"ged in CVS" is missing from the title.
Hmm, I see MAXLENGTH=50 SIZE=50 in the HTML code, it looks like KHTML isn't ensuring that one can't type more than MAXLENGTH chars. It should, right?
(Damn, I see bugs everywhere ;)
Oh, khtml _does_ truncate. But one doesn't see it when inserting chars at the beginning of the title.
Ok, dot bug then: why limit to 50? ;-)
We have to limit it to *something*. :-)
That's kinda odd, but... :: shrug :: Okay.
--
Evan
What's kinda odd exactly?
The fact that you limit the Title to just "*something*". Is the Re: okay? I didn't add it.
--
Evan (Pssst. It's a joke.)
har har :-)
Ok....if khtml does stop at 50 characters, it should not let us insert ANYWHERE in the text (that means beginning too). So it's not just a dot bug, is it?
Sorry...
Well, 50 characters is a bit long for a title, but maybe the limit should not be looking at what is a reasonable length, but rather what is starting to get unreasonable.
If you feel that 50 characters is starting to become unreasonable, then by all means keep that limit. Anyways, it saves us some reading by forcing some people to shorten long titles that are not well written, and takes a while to read.
Tim
i haven't yet rebuilt to check out your changes (so apologies in advance if this is already taken care of), but:
perhaps anything text related (office docs, text files, etc) or image related (pngs, jpegs, etc) via the http protocol (or any other protocol that is read only)?
i would also wonder about images stored locally .. are they more often viewed or editted? if they are more often viewed, then perhaps they should be shown in an embedded view ...
maybe i should read the cvs commits? ;-)
kdebase/libkonq konq_settings.cc,1.47,1.48
Author: faure
Modified Files:
konq_settings.cc
Log Message:
We want to use the embedded viewer for images, too, by default.
return (serviceTypeGroup=="image"); // embedding is false by default except for image/*
Sure. I haven't changed what happened over HTTP.
Sorry, I should have mentionned it more clearly: this is about "what happens when clicking on a file in a FILE MANAGEMENT view (iconview, listview, textview, treeview)".
So it's only about protocols which support listing (file, ftp, fish, webdav etc.), and unrelated to HTTP.
ah, that makes tons of sense. of course, this is David we're talking about so i'm not surprised in the least. ;-)
Just a modest proposal:
Left click, view (embedded, when possible), middle click, edit, right click properties of the file. That is, realistically, how I mentally see things (with the exception of web browsing, where I use middle click for opening a link in a new window), since middle click usually opens an editor for me.
Still, the view/edit/properties system seems to be a bit more logical than the current random/new window/properties. YMMV, I'm just one guy with an opinion, etc. :)
--
Evan
Sounds like a reasonable proposal, but it seems to me that it is not half that simple. Different filetypes do have different properties, and are used for different purposes, so it is difficult to just have a "one size fits all" for all filetypes.
I have nothing against embedded viewer for .doc, .txt, and those types of files that would normally be edited, just as long as #1 - I can save the document somewhere else from within the viewer, and #2 - when I press "backspace" it goes to the previous page, and does not trap my konqueror commands.
In another words, the problem I have with embedded viewer is not that they look bad or anything, it is that they are trapping too many konqueror shortcut keys (most notably, the backspace should be available no matter what).
Tim Vail
> Left click, view (embedded, when possible), middle click, edit, right click properties of the file.
Funny, that's *exactly* konqueror's behaviour.
Not quite (and yes, I know who I'm talking to, David :) ).
Left click does quite a few different things. Middle click seldom edits, more often opens the target of the click in a new window. Right click does, almost always (okay, I can't think of a time when it doesn't) bring up properties.
My proposal is to formalize left click as "view", never "edit", and use middle click as a "edit" default, rather than "alternate program, usually in a different window". Right now, left click sometimes edits, sometimes views, and often to do the common task of editing, you have to right click, and Open With.... Since the two most common activities you do with files are view and edit, and generally the two applications are seperate (a image viewer vs. an image editor, a sound editor vs. a sound editor, a text viewer vs. a text editor, etc), it would make sense to move these two activities to the "top" of the selection tree, and assign them very consistant behaviour, no matter what the file is.
Left click: View
Middle click: Edit
Right click: Properties
Right now, it sometimes works that way, sometimes doesn't. All I'm saying is "formalize and make it consistant". And if the developers all agree that it's a good idea, I'll go through and do the grunt work of making sure that it is configured consistantly along those lines.
--
Evan
Left click does - what the user expects, view if this kind of file is generally viewed, liked images, PDFs etc., and launches the app (to edit OR view) otherwise.
Middle click launches the app, always. I don't see what you mean by "seldom edits". For files that can
be edited, middle click launches the app to edit them. Always.
"New window" - did you mean a Konqueror window? Show me one file (not a dir, and not HTML) which opens a konq window when middle-click it, I'll be very surprised. (dirs and HTML are handled by
konq, so it's logical they open a new window ;). In all cases, MMB = launch app.
Your idea isn't as consistent as you think, and surely not practical.
1) VERY FEW users know about middle-clicking. On mouses with 2 buttons it means pressing both buttons at the same time. How ergonomic is that? My wife doesn't know MMB, my parents don't know MMB, and they surely don't want to have to press both buttons just to edit a kword doc.
2) Not all files can be edited. What happens if you MMB a sound file, in your suggestion? Given that I have no sound editor installed?
3) Sometimes you don't really know if you want to view or edit. You want something that shows you the stuff, and then you'll see if you need to change it or if it's fine.
4) This change comes after a complain that "clicking on a text file views it, but users don't
know how to edit it". Your suggestion goes _back_, re-introduces this behaviour, and even more of it (clicking on a kword document would only show it, readonly. "How do I edit it??").
People don't want to have to learn how to use a file manager all over again.
They don't care if "it's formalized and consistent" under the hood. It has to behave
in a way that they expect, that's the most important thing. We already have/had too
many usability bugs that were due to the developer's own notion of consistency.
:: Left click does - what the user expects, view if this kind of file is generally viewed, liked images, PDFs etc., and launches the app (to edit OR view) otherwise.
In other words, it does something different for each icon clicked. That's confusing. When most users click on an item, they want to view it. That's what 85% or so of the KDE left click actions are assigned to do, view the file. Why not just formalize it?
:: Middle click launches the app, always. I don't see what you mean by "seldom edits". For files that can be edited, middle click launches the app to edit them. Always.
Not always - for instance image files are loaded in KView and html files are loaded in a KHTML view in Konqueror. Again, in 65% or so of the cases, it does open in an editor - all I'm saying is formalize the already accepted behaviour of KDE and make it consistant.
The notion of a difference between a "embedded app" and "fully realized app" is nonexistant to a user. Users work with files, and they don't care if it's inside Konqueror or running as it's own app. There is a difference, however, between viewing and editing.
:: 1) VERY FEW users know about middle-clicking.
Very few users knew about double clicking. And yet several million of them figured it out over the past couple of decades.
:: 2) Not all files can be edited. What happens if you MMB a sound file, in your suggestion? Given that I have no sound editor installed?
Then you've identified a lack in KDE's base of applications. If the file format is standard, there should be an editor. Until then, use a viewer, or search for a 3rd party editor like Audacity installed on the system.
:: 3) Sometimes you don't really know if you want to view or edit. You want something that shows you the stuff, and then you'll see if you need to change it or if it's fine.
True. It would be nice if viewers had an option "Edit" under the File menu that looked to the File Type db and launched the preferred editor for that type of file. That would also allow quick viewing of files to find the one you want to edit. Again, I would be willing to do the grunt work in making sure all viewers in CVS match this behaviour, if this proposal becomes accepted as a good idea.
:: 4) This change comes after a complain that "clicking on a text file views it, but users don't know how to edit it". Your suggestion goes _back_, re-introduces this behaviour, and even more of it (clicking on a kword document would only show it, readonly. "How do I edit it??").
Yes it does go back to that behaviour, which was primarily inexplicable because it was one of the only files that did that. But then, sometimes you want to just view a textfile - configuration files, most notably. And yes, you *are* introducing a seperation between viewing and editing. Is that difficult? Well, the seperation already exists in the applications... KView versus Gimp, Noatun versus Audacity, Konqueror KHTML versus Quanta, Konqueror tar: versus Ark. IMO, it clarifies that already existing seperation and allows users to clearly choose if they want to view or edit a file.
As for confusion: Left Click, View - Middle Click, Edit. It's really quite simple, and easy to explain both to totally new computer users and new KDE users. Easier than the current "sometimes you get a viewing program, sometimes you get an editor, sometimes it's embedded, sometimes it's seperate".
--
Evan
(Opinions? Please don't think I'm flogging this for myself or out of a belief that this is the One True Way. I think it's a good idea, yes, but I'd like to hear some other reasons why it's bad. Reason number 4 up there is my personal tweak that gave me serious pause. I think if it were clearly "Left/View, Middle/Edit", that issue would be negated.)
Evan, maybe you can help with something. Recently, my
konqueror stopped viewing the contents of tar.gz and
tar.bz2 files as though they were folders. Now it always
opens ark instead. I have no idea what happened, but what
are the correct settings to put it back the way it was?
Thanks.
I find the embedded Noatun butt ugly. Especially when you get to larger resolutions like 1280x1024 and a maximized Konq. You have a whole screen of grey with 4 (I think) "little" buttons and a slider. I understand I can change the file associations, but that is kinda annoying.
What about using a split view for embedded viewers, such that the viewer would not replace the icon view but appear in a separate (sub) view? People could then select more documents while the (pre)view area is reused.
Try the "file preview" konqueror profile, it does exactly that.
Hi all
While there are a few things in KDE that could use improvement, the over all operation IMHO is much better than windows.
Please don't change KDE because of a small study carried out using computer-illiterates. The "single click thing threw me" isn't a valid argument. The single click is easier and more consistant than Windows. BTW click on apps in the panel bar at the bottom of Windows 2000. A single click will start the app.
People have learned certian behaviors as a result of exposure to Windows. If a usability study were done on windows by users who had only been exposed to KDE then perhaps we would find that the results would be equally opposed to those things that windows does differently.
In short we get used to something, decide that it is the "right way" and then set out to impose this on others.
KDE is fine. It took me an hour or so to get used to the differences and now I find it much preferable to Windows. In additon the whole Linux environment IMHO is far superior to Windows.
John
John