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

List:       kde-usability
Subject:    Re: Beginnings of a summary of some of the repeatedly occuring topics + Updates
From:       Irwin <emerald-arcana () rogers ! com>
Date:       2002-05-26 16:18:06
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 25, 2002 07:27 am, Aaron J. Seigo wrote:
> On May 25, 2002 11:38 pm, Irwin wrote:

> this would make for an excellent FAQ type document. the user level topic,
> in particular, gets brought up with alarming regularity. compiling these
> summaries and then posting them somewhere so as to be publicly available
> (usability.kde.org, obviously =)  would, IMO, be very worthwhile.

In a way it's similar to a usability report in that we explore some "general 
usability concept", and justify why or why not it should be applied.

So yes, if we had a FAQ saying, "Why doesn't KDE use User Levels?", we can add 
this, along with our discussions, and preferably with some supporting 
research from experts in the field.  If anyone HAS research about this PLEASE 
send it to me.

I'm going to try to keep a "notebook" about KDE usability topics.  It'll 
probably continue to look like this unless I think of a better format.

~~

I updated the topics with a heuristic observation about the Kicker KCM 
changes.  I noticed a few things that were common with the changes.  I 
haven't followed all of the ML threads lately so you guys probably discussed 
it already, but I would like to see WHY the changes were made and HOW they 
increase usability to be recorded somewhere.

As a summary of my findings I reported the elimination of scrolling Sliders 
(in favour of the Combobox Wheel-widget thing), favouring vertical layouts 
over horizontal, and so forth.


- -- 
- -- Irwin 
(Arcana)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE88RSZ4kwAe/yBEAIRAk4qAJ4z1KAN6muIKPhwgNxHEinJDqJSBQCdFKSK
XzmN9VDr/OiOoqgpkFxWq64=
=7i4q
-----END PGP SIGNATURE-----

["topics.txt" (text/plain)]

KDE Usability Topics and Viewpoints
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

General Usability Discussions
-----------------------------

1. User Levels

DESCRIPTION: KDE should have user levels to allow new users to be better integrated \
into the environment.  User levels will hide the advanced features so any one with a \
certain level of expertise will not feel overwhelmed by the number of options.

COMMENTS: 
A. Seigo (2002-05-20): the goal should not be to remove things that people aren't \
familiar with (otherwise we may as well remove computers altogether; no one is \
familiar w/computing until they use them for an extended time). rather the goal \
should be to limit those things which are beyond the grasp of the average person.

K. Koehntopp (2002-05-22): Looking at the kcontrolcenter, I am overwhelmed. There are \
far to many switches and dials, and most of them are essentially unused. Most of them \
really should not be there, but go away into some panel which is normally invisible, \
and only available by clicking at some button labelled "advanced".

T. Zander (2002-05-20): The complexity you point at has little to do with the amount \
of features being turned on at the same time.  As long as they have a good default \
the user will never even try to change the features.

<incomplete>

CONCLUSION: User levels do not achieve the intended purpose because users first
have to figure out their expertise.  They never get the opportunity to learn more \
advanced features.  In addition, users of different classes will end up dealing with \
"different" user interfaces which leads to confusion from support lists.


2. Application Plugins





General "Computer" Applications
-------------------------------

1. The Apply Button

DESCRIPTION: The behaviour of the "Apply" button.


S. Edwards (2002-04-16):
Hi all,

A quick question I guess. Consider this:

1. User starts a program (a Firewall program for example).
2. User changes settings.
3. User presses 'Apply' and the settings immediately take effect on the 
system.
4. User presses 'Cancel'. The program exits.

What state is the system's setting in now?

a) Same as before point 1.
b) Same as just before point 4.
c) none of the above.

What do people expect here?

I. Kwan (2002-04-16): 
I think that as soon as you hit 'Apply', you should grey out the 'Cancel'
button.  Notice an application like KControl does NOT have cancel buttons,
probably precisely this reason.

In this instance, I would put the program in the 'Applied' state with the new
user settings that were chosen when you selected 'Apply'. (Same as before
Point 4).

C. January (2002-04-16):
1. Cancel should be called Exit if it exits the whole program.
2. Apply buttons are a horrible addition to dialogs. First of all, most
Apply buttons appear next to Ok and Cancel buttons which close the
dialog...except Apply doesn't actually close the dialog. Secondly, with most
implementations once you press Apply your changes are fixed; pressing the
Cancel button does not, usually, undo your changes. Preview is probably a
better choice for environments where this actually matters (e.g. look and
feel settings). The rest of the time (e.g. with firewall settings), an Apply
button makes little sense anyway.

A. Seigo (2002-04-16):
if anything, i could see the term "Ok" being changed to something more in line 
with "Apply" and "Cancel" as it is ambiguous until one learns what "Ok" 
actually means. perhaps something like "Apply and Close", although that is 
long, would require people used to "Ok" to relearn the interface, etc... 

C. January (2002-04-16):
When I said Preview I actually meant that the button would really preview
the settings rather than change them there and then like the usual behaviour
of Apply.

A. Seigo (2002-04-16):
how do you preview a user agent change in konqueror?

or, to fall back to our original saw: how do you preview a firewall rule 
change?

because "Preview" doesn't apply to all types of settings having "Preview" 
there sometimes and "Apply" there others would suck. additionally, previews 
(if at all possible) should be in the dialog itself. cf: kde3's style and 
color kcms

I. Kwan (2002-05-26):
I noticed that when watching people use a dialog with "OK", "Apply" and "Cancel", \
they usually hit Apply before using "OK" to close the window.  This suggests that \
there is confusion because people are using apply to "be sure" that their \
application's settings are saved.

POSSIBLE SOLUTIONS:

* Rename "OK" to "Apply and Close".
* "Preview" to see changes without saving them, OK, and Cancel
* Status quo: OK = "Apply changes and close window", Cancel = "Cancel all changes and \
close window", Apply = "Apply changes and leave window open".


3. Static Window Placement Policies

DESCRIPTION: There should be a window placement policy that places a window in a \
pre-set location on your desktop.

SUMMARY OF DISCUSSIONS:

-Current window placement policies place windows dynamically on the screen so that a \
                user does not know where to find them.
-Static window placement policies will allow a user to predict exactly where the \
                window will be placed so he/she can move it to the desired location.
-Static window placement policies will end up "stacking" windows, which means it is \
more difficult to find them under a number of windows.

-"Paper on a Desk Analogy".  How you arrange the paper on your desk; a new window is \
equivalent to a co-worker placing a new sheet of paper on your desk.

POSSIBLE SOLUTIONS:

* Add an option for placement of new windows in "Center"
* Add an option for placement of new windows in "Upper-left Corner"
* Status quo (do nothing)
 

Specific KDE Applications
-------------------------

1. kicker kcmshell

-Action was taken on this item.

General Comments when redesigning other kcmshells(I. Kwan, 2002-05-26):
-From a quick heuristic analysis, it is MUCH nicer to have everything laid out \
vertically as opposed to horizontally.  For example the "tile" buttons on the Panel \
(kicker kcmshell Look and Feel tab) were changed from being a 2x3 grid to a 1x6 grid, \
for a much nicer effect.

-The verb "Enable" was removed from the kicker kcmshell.  Instead of "Enable \
automatic hide animation", we have "Animate panel hiding".

-Removal of redundant sliders in favour of a number-counter widget (find name)

-Use of checkboxes for "On-Off" rather than two panels indicating "Available items" \
                and "Visible items".  
**NOTE: Configure Toolbars could take a lesson from this.


3. KMail

4. Konqueror (File Manager)

4.1: Button submenus:

-Action was taken on this problem.

5. Konqueror (Web Browser)


_______________________________________________
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]