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

List:       kde-usability
Subject:    Notebook on Assorted KDE Usability Topics
From:       Irwin <emerald-arcana () rogers ! com>
Date:       2002-06-06 3:45:18
[Download RAW message or body]

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

Here is my notes on assorted KDE usability topics.  Apologies, it's about as 
messy as any notebook I'd normally keep.

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.

S. Edwards (2002-05-29)
Another (big) problem with user levels is that users will be at different
levels for different features in an app, at the _same time_. For example, a
user may be expert at the search feature (regex etc), but know very little
about the spell checker. Trying to put users into one of n pigeon-holes will
always cramp them in some way.


<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".


~Buttons and Tabbed Panels

I. Kwan (2002-06-01):
- - You have a "Defaults" button in KControl that appears at the bottom of every
tabbed panel.  When you click it, does it reset the defaults in only one tab,
or in the entire "thing"?  I wasn't sure when I looked at it.

Answer: It applies the defaults to every panel.


~Menus and hiding Least-Frequently-Used Menu Items

* Many People think it's bad.
* Some people end up likeing this idea after getting over how they thought it 
was bad.


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)

4. Tooltip behaviour on Kicker Panel (May be extended to all of KDE)

DESCRIPTION: Where should tooltips appear?  What should they look like?  When
should they appear?  When should they disappear?

They should appear:
1) On top of the panel
2) Below the mouse pointer
3) Above the mouse pointer

E. Ellsworth (2002-05-21): 
With Kicker at the bottom of the screen, you can't put the tooltips below
the mouse pointer, nor should you when the toolbar (of any sort) is
vertical - you'd be putting the tooltip over another button.  This says to
me that it's best to put it outside the toolbar altogether.


They should look like:
1) A rectangular yellow box
2) A "speech balloon"
3) A grey line pointing to a rectangular yellow box (so that it is out of the
way)

M. Collette (2002-05-21):
The real problem here is where the tooltip is showing up.  Right on top of the 
very thing a user is trying to see.  Instead of doing it like Windows, 
perhaps a page from either Mac or Enlightenment is in order here with them 
baloon style tooltips.  Okay, definitely not as big as either of those folks 
do it, but along a similar idea.  A cartoon like bubble with some very basic 
info about the icon pointing down to it.


E. Ellsworth (2002-05-21):
I'm for this, as long as it's lightweight - I was thinking of just adding a
little gray line from the tooltip down to the pointer.  This way the shape
of the tooltip wouldn't need to change for the line to follow the mouse.
Cartoon bubbles would let you do thinks like persistent and clickable
tooltips, which appear in the taskbar in Windows XP (other tooltips appear
over the icons in Windows...), but they'd need to have a shape which allowed
them to point towards the pointer, or at least the object being explained.

When should they appear:
1) Immediately
2) In half a second
3) In one second

When should they disappear:
1) Immediately upon mouse movement
2) After a certain time after mouse movement

M. Collette (2002-05-21):
First off, the tooltips should appear immediately upon having the mouse over 
an icon.  A user, even an experienced one, shouldn't have to wait to have an 
icon identified.  Additionally, that very same tooltip should immediately 
vanish upon the mouse leaving an icon.  That much isn't happening very well 
now.

S. Edwards (2002-05-21):
There is a *very* good reason why there is a delay between the mouse stopping 
and the tooltip appearing. If there is no delay, then tooltips will flicker 
on and off during normal button operation, which sucks big time. IIRC, 
tooltips are desendant from Mac balloon helps years ago. Balloon help used 
appear immediately too and no one really liked it. There is/was a switch on 
screen to turn it on/off I believe. MS took the idea and added a delay and 
left it always turned on. And the rest is well history...


General consensus appears:

* Tooltips should appear outside of the panel.
- -Corillary: does this mean that tooltips on toolbars should appear outside of 
the toolbar?
- -NOTE: KMail/Konqueror for example has its tooltips appear below the menu bar.
* Tooltips should use a balloon (or some other method to allow them from 
obscuring the icon: see point above).
* Tooltips should have a short delay before appearing (I. Kwan suggests about 
0.5 seconds)
- -NOTE: KMail/Konqueror use a short delay (1 second).  After the tooltip 
appears, if the user scrolls across the other buttons, there is no delay.
* Tooltips should disappear immediately.


KDE Menu Rollover Behaviour
~~~~~~~~~~~~~~~~~~~~~~~~~~~

S. Edwards: 2002-05-28
1) Disabled menu item go depressed when you mouse over them!

Greyed out menus item go depressed when you rollover them with the mouse. 
'Rollovers' like this indicate that an item is in fact active and ready to be 
used. This is a strong convention from the Web. KDE's menus should not give 
such mixed signals.

Recommendation: Inactive menu items should not have rollovers!

K. Szwed (2002-05-29)
I'll give another example why we need the hover effect: Take the case 
where a user is navigating the menus with a keyboard. They navigate onto 
disabled menu items (yes, Qt allows this!), and with your recommendation, 
they would have no feedback showing them what menu item they're currently 
at.. So I'm sorry but this must stay as is for now.

A. Davidson (2002-05-29)
Hmm, couldn't the disabled menu options ne highlighted in a different
way, say a change of colour with no depression, which would say both
"This is selected" and "This is an inactive option"

G. Tyler (2002-05-29)
The other alternative is to not allow selecting of disabled menu items at
all. Keyboard navigation would skip over disabled items and mouse-hover
wouldn't highlight them.

S. Edwards (2002-05-29)
Well not quite. Windows uses a compromise. No rollover if you use the mouse. 
But with a rollover if you use the keyboard. I think it's a good compromise.

Radio Buttons and Checkboxes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

S. Edwards (2002-05-29)
2) On/Off checkable menu items (ticks) look exactly the same as radio-button 
menu items.

Checkable menu items can be either like checkboxes, i.e. boolean, or like 
radio-buttons i.e one from the a group can be selected (like radiobuttons).
KDE's renders both type exactly the same. This is bad because the user now has 
to play with the menu items to work out which ones show mutual-exclusive 
behaviour, and which ones don't. Windows actually gets this right. Boolean 
items have ticks, while radio menu items use a bullet.

Recommendation: Radio menu items should be rendered with a bullet in front and 
not a tick.


Checkable Menu Items
~~~~~~~~~~~~~~~~~~~~

S. Edwards (2002-05-29)
For example "Konqueur->Window->Show Terminal Emulator".  Menu items with icons 
show the 'checked' state by using a depressed border and white background. 
This border easily gets visually lost amongst the icon itself, and makes it 
hard to quickly see the state of the menu item. Menu items without icons use 
a tick on the same depressed border to show the 'checked' state. I would have 
thought that most people recognise the 'checked' state more by the tick, than 
by the border/background.

Recommendation: suggestions?



 

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 spinner

- -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.

A. Seigo (2002-05-26):
unfortunately, configure toolbars has a few extra requirements: ordering of
the visible items, insertion of (multiple) seperators at user defined points.
the toolbar config dialig is indeed a big clumsy but the checkbox solution
probably isn't the fix :-/

perhaps something a bit more interactive, like DnD manipulation of an example
toolbar in the dialog *shrug*

2. Kicker

2.1 - Context Menus do not correspond to the  context.

2.2 - RMB on kicker applets

2.3 - Applet Handles

- -The handles, right-clicking on the handles, and the little up arrow

2.4 - Child Panel and Main Panel

A. Seigo (2002-05-26):
anoter example is the lack of consistency between the child panel and the main
panel. it was baffling to users why they could do some things with the child
panel but not others when compared to the main panel. users didn't see them
as two seperate types of things, even though programmatically they are quite
different.

2.5 - Group by Application

C. Samuels (2002-06-02):
Group-by-app should be disabled by default.  Users can't figure it out.  They 
don't know where their windows went.


3. KMail

~New Mail Notification

G. Tyler (2002-06-02):
1. Pressing Escape when composing a new email doesn't cancel/close the mail. 
This is most useful when I've pressed Ctrl-N in the wrong mailing list 
folder. Escape doesn't work when viewing a received email in a separate 
window either. I suppose I've gotten used to this from Outlook Express, so 
without even thinking about it I just whack the Escape key when I want to 
close an email.


On June 3, 2002 04:04 am, Irwin wrote:
> On June 2, 2002 18:07 pm, Gordon Tyler wrote:
> > 2. As far as I can tell, the only new mail notification in KMail is a
> > beep. I can't change the sound. I can't get a notification icon in the
> > Kicker dock area. I can't get a popup dialog (for those who like that)
>
> In my version of KMail (from KDE 3.0), I go to Settings -> Configure KMail.
>
> Under Network/Receiving, I see:
>
> New Mail Notification

Mmkay... I didn't look hard enough. Although I suppose this is an indication 
that it's not in the right place.

> While you still can't change the sound easily or get a notification in the
> dock, you can get a popup, apparently.

I could play a different sound using artsplay but that's kinda tacky. Why 
doesn't KMail use the KDE System Notifications stuff that's in the Control 
Center? In fact, hardly anything uses that.


2. As far as I can tell, the only new mail notification in KMail is a beep. I 
can't change the sound. I can't get a notification icon in the Kicker dock 
area. I can't get a popup dialog (for those who like that)

3. Shortcut keys (R to reply, F to forward, etc.) don't work when viewing an 
email in a separate window. Only the context menu is available.

4. The separate email window has no toolbar with commonly used actions.




4. Konqueror (File Manager)

4.1: Button submenus:

- -Action was taken on this problem.

5. Konqueror (Web Browser)

I. Kwan (2002-05-26):
1: Make "Find in Page" closer to the top in the Edit Menu.  It's way too far
at the bottom for such a commonly used feature (in my book, anyway).

antialias (2002-05-27):
'Find' is default icon on Konqi's toolbar and requires just one click te get 
pop-up window.

I. Kwan (2002-05-27):
I think I remember bringing this up: the magnifying glass with the footprints
doesn't cut it as a "Find".  It reminds me too much of either "Zoom" or "Font
Size Larger" or "Font Size Smaller".



2: Make "Find in Page" an item in the right-click context menu for an HTML
page (or file list, or other document...).  When I think of trying to find
text in a frame I always right-click only to realise that it isn't there.



6. KWord

- -KWord observations with table-handling:

1) Table menu doesn't allow you to create a table.  (You have to go to 
"Insert" instead).
2) Click on table: you cannot use the table menu.  You must highlight a cell.  
Not intuitive.
3) Resize columns/rows: there is no "dotted line" indicating where the cell 
boundaries will move to such a feature exists in Core Wordperfect and 
Microsoft Word).
4) Right-click on a table does not bring up table properties.  (You must 
highlight a cell first).
5) Move mouse over a cell border: finger pointer appears.  You can only 
highlight the cell above and to the left of the cursor.  You cannot drag the 
borders (as Wordperfect/Word users may be used to doing).  

I personally find that the Wordperfect way of handling tables is much more 
intuitive.  It allows you to drag to resize table borders with the mouse.  
When you are within a small amount of space from the border on the right and 
to the bottom (but not on it), you can highlight the entire cell.  There are 
shadowed borders and tooltip measurement popups to indicate what the results 
of your drag and drop action will be.

7. KSpread

8. KMenu Layout

Summary of E. Ellsworth (2002-05-29):
* To sort by application
* Every program type is represented by a program
* To have an item to allow "Try Other Programs" to replace the existing 
programs in the menu




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

iD8DBQE8/uQB4kwAe/yBEAIRAidiAJ9sNuyybHXzI2Kzh9fx+xHaRdHzRgCeL9VN
IYJATZiX0H4/klIF9W1d2NE=
=Fs6U
-----END PGP SIGNATURE-----

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