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

List:       kde-look
Subject:    Re: The KDE status gear
From:       "Steven D'Aprano" <dippy () mikka ! net ! au>
Date:       2000-04-25 3:39:42
[Download RAW message or body]

Magnus Ihse wrote:
> 
> On Mon, 24 Apr 2000, Steven D'Aprano wrote:
> 
> > There's a place for double clicking, in certain types of application,
> > as a shortcut. Lets not throw away *usability* for the sake of
> > *purity*.
> 
> I think I agree with you, if I understand you right. You mean that
> double clicking should always be a shortcut (ie there should always
> be another way of doing the same thing as double clicking). And you
> mean that double clicking should be different from single clicking,
> in these applications.

Yes. If d-clicking is used, there should always be another way of
doing it. But I think you will find, once people start to use it, they
won't go back.

(This is not to say that the single-click paradigm is wrong. I'm
keeping an open mind about that.)
 
> For this to make any sense, single clicking could not be an _action_,
> but must be a selection. If you use single click (as is currently
> done in kfm) as a shortcut for "select and perform default action
> upon", then there is really no way to select things without
> simultaneously performing some kind of action. And it wouldn't make
> sense to have double click being some kind of shortcut in this case.

You are right. The way kfm uses single-clicks has some advantages, and
it matches the UI of browsers and (eg) Hypercard on the Mac. But it
makes *selecting* icons rather non-intuitive. And even once the user
learns that they can ctrl-click to select icons, I bet they fall for
the trap of then clicking on a single selected icon when they want to
open them all at once (I know I do, repeatedly). It doesn't work.

Do I understand that kfm is on the way out? That konquorer is the next
generation of file browsers? If so, we need to look at how konquorer
does things, not kfm.


> > I've been playing around with a GUI application development system,
> > Metacard. It uses two distinct modes for "using" and "creating"
[snip]
> What do you think about this separation in Metacard? Is it useful or
> just unnatural? (Anyway, it seems as I have to try to play around a
> bit with this Metacard...)

I'm coming from an extensive Hypercard background, so in broad terms
it didn't worry me at all (some of the specific differences b/w
Hypercard and Metacard still cause me trouble, but that seems to be
mostly because MC does so much more than HC).

For the benefit of those who have haven't used either HC or MC, the
basic paradim is that you have a window which displays (one at a time)
multiple cards. Cards contain UI widgets like buttons, fields,
graphics etc. Most of the UI basic functionality of the widgets is
built in, the developer simply programs the widgets with message
handlers (eg on mouseUp, do this). This is a gross
over-simplification. HC is relatively limited in what it can do, but
MC is not.

Anyway, this isn't meant to be a MC advocacy session (contact me off
list if you want that :-). As far as the UI goes, MC uses seperate
modes for creating and for using. The user/developer enters these
modes by choosing a tool from a toolbar - a browse tool (hand) for
using, a pointer tool (arrow) for manipulating objects/widgets, a
button tool etc for creating widgets.

Remember, MC is not meant for the average user. It is a development
system, even if perl and C++ gurus will turn their nose up at it :-)
In general, its easy to tell the current mode. MC uses the mouse
heavily, and the shape of the cursor tells you instantly the mode you
are in.

The difficulty I have with MC is that it doesn't use some of the
extremely helpful shortcuts that Hypercard uses for editing widgets
while still in using mode. (ie HC uses a special spring-loaded edit
mode, which lets the developer *quickly* drop into a limited creating
mode and edit a widget's code while still being in using mode. Trust
me, while an application is under development this is a life saver!)
MC looses a little usability for the sack of purity.

By default, widgets don't respond to double clicks, although the
developer can script that behaviour in if required. But under creating
mode, with the pointer tool, a single click *selects* the widget, for
manipulation (eg cut/copy/paste, edit properties, resize, move,
delete, etc). A double-click with the pointer tool by-passes the need
to select and choose a menu command, and just immediately goes to the
edit properties window. It works well.

It seems to me that this sort of paradigm is well worth keeping for
two major categories of application. The first is development
applications, eg application builders like Applix's SHELF or Metacard.
The second is vector graphics programs, where the user has to be able
to select objects for further manipulation, and it is useful to have a
short cut to commonly used commands.

I will leave the issue open as to whether interacting with files in a
file system is more like interacting with vector graphics or browsing
the web.


-- 
Steven D'Aprano

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