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

List:       kde-look
Subject:    RE: Usability and open source
From:       "Ben Last" <ben () last ! uk ! com>
Date:       2000-01-31 15:34:47
[Download RAW message or body]

> From: Tyler Regas [mailto:tyler@regas.net]
> > * dual mice.  Use one for each hand.
> Too radical. It takes the element of freedom away from the user by having
> them use both hands. It's also motion-intensive in that the user would have
> to move both hands to the keyboard and back. Integrating a BAT-type
> chording keyboard may be a solution, but the learning curve would be steep.
But for some tasks it "rocks" (as I believe the Americans say).

> Mousing (or the many popular variants such as trackballs and trackpads) is
> the most direct method of free input. It also doesn't draw on any
> pre-existing metaphors. Drawing pads mimic paper.
Okay, try working for one hour at a real-world task using only one hand.  See
how often you use the secondary hand to manouver something for the primary hand
to do detailed work on.

> > * scalable desktop.
> This has a great deal of potential, but it's document centric.
Well, I find a similar approach very useful for having four or five kvt
"tail -f /var/log/messages" windows open, zooming one up if I need to (by
changing the font size).  Yes, it's document-centric, but then an awful lot of
pc use is.

> most graphic and document creation software implements something like this
> already. Word can scale documents to many percentages in and out without
> modifying the type size.
But that misses the point.  The application is unaware that it's been shrunk.
You're able to zoom the whole desktop.  I probably explained it badly; think of
standing next to a desk, looking at documents on it.  To see one better, you
pick up that one and bring it up closer to your eyes.  Having looked, you put
it back down.  Similarly one would be able, with a single click, to zoom a
window up and down.

> Of course, this is only really useful in document environments where there
> is a large scale to see.
It's surprisingly useful just to be able to see an overview of a document with
a single pixel per letter.

> > * getting away from the lousy Start menu idea
> Though I'm not clear on what you're describing here specifically (I'm
> seeing the menuing system from The Secret Of Mana for Super Nintendo) I do
> understand the concept of multidimensional interface. Interestingly enough,
> one of the finer examples of a working 2D interface is GNOME. The
> Dock-concept allows one icon to iconically identify a group of functions.
I wasn't going for multidimensional, just 2d.  The thing I really dislike about
the STart menu is that to select individual programs requires you to carefully
work your way through a bunch of submenus.

I thought of a better alternative last night; well, nicked it from Apple.
Recent versions of MacOS allow you to drag an open folder to the edge of the
screen.  When you do that, it hides itself, turning into a tab at the edge of
the screen.  A click on that tab opens it up (slides out from the edge of the
screen whilst remaining attached) so that you can activate any of the items
inside it.  Several people here use it to holds sets of shortcuts to apps and
documents.  They end up with many tabs arranged along an edge of their screen;
each one has a name (the name of the folder) and acts as a quick popup menu.

> Apple developed a 3D navigation system for the web called HotSauce that
> worked as a plug-in and required some scripting but allowed you to "fly"
> through the site. Quite inventive.
True, but 3d interfaces have, in general, not made much of an impact.  I
suspect this is partly because there's much evidence that we actually see in
2-and-a-half-d, where the third dimension is much compressed.

> > * moving away from the document/view paradigm
> Windows 2000 already does it. It's simplistically called Configure Your
> Server and starts automatically when you first boot after an install. It
> uses an iconic bar on the left (ala OutlookBar) to list functions and it
> arranges them in first to last order, loosely. In the right-hand pane it
> gives clear textual explanations and more iconic links to configuration
> dialogs.
Hmmm - haven't seen that.  I'll have to take a look.

> Dialogs are for changing options. Wizards are for adding things.
Nope - I disagree.  Wizards are supposed to be process oriented - to guide you
through the steps you need to do to get a job done.  Yes, MS tend to use them
for adding things, but that doesn't mean they're using them right :-)

> You place the
> Wizard functionality in a Linuxconf-type environment and you will please
> newcomers but anger hackers.
Only if I assume that one interface excludes the other.  Personally I consider
myself a hacker, but I find the Linuxconf interface annoying.  For some things
I would actually like a Wizard - I really don't have the time to learn sendmail
configuration in depth and it'd be useful to have a quick guide through it for
the one day per year I need to worry about it.  But there are other places
where I want direct access to the config section for an app, and resent having
to arrow-key my way around a tree of options (I do most of my linuxconf via
telnet or sshd).
Having said all that, hackers are a bad user set for our discussions, 'cos our
understanding of the basic functions of the system is too great.  For the naive
user in front of a KDE desktop, a wizard or the equivalent may be the most
appropriate way to guide them through a complex process.

I think the point I'm making is better explained a different way (avoiding the
linuxconf example which was a lousy choice of mine in the first place); there
are apps for which the existing ways to display information are a bad choice,
yet those interface metaphors are used because they're familiar.  The most
popular break down into:
* document/view - like word processors, spreadsheets
* tree control - windows explorer, most MS management tools
* mimic a "real world" device - most MP3 or CD players

There are More Ways To Do It (pace, Larry Wall) :-)

One way to address this is to build a richer collection of high-level widgets
into the base KDE set.  In addition to a tree control, for example, have an
interactive flowchart (yes, I still contend that where you need a wizard, the
flowchart approach is better).

regards,
ben

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