Re: Word Processors

[Quantum Seep <qseep technojunkie com>]

I am talking more about live configuration - after the product has been
installed and run several times.  My configuration system could be used
while the application is running or while it's down, since it can be
accessed via an external program.  Of course, experts might want to use it
to set up their system, but Q&A dialogs (aka wizards) might work better for
newbies.

I happen to be a big detractor of "wizards" or "project templates."  They
are too linear, and usually not reversible.  They provided an illusion of
power in the product.  When you use one to create a new project or setup a
program, you are forced to wade through a series of dialogs, even if you can
click "Don't care" on each one.  They seem to provide a sort of
"meta-control" over the resulting project.  However, once you're in the
middle of the project, if you change your mind about one of the wizard
selections, you'll have to either create a new project, or manually make all
the miniscule changes yourself, thus defeating the "power" of the wizard. 
IMHO, it is more challenging for the programmer, but ultimately more
satisfying for the user if you skip the wizard and give them powerful
controls over the parameters the wizard would have tried to set.  You can
even track their usage of these controls to create defaults for new projects
(prototypes).

You also argue that a user might screw up their setup using my "under the
hood" system.  We can ameliorate that possibility in two ways.  First, we
can make it an "expert mode" and discourage them from using it.  Second, we
could provide them with an "undo" or "revert" option to take their setup
back to a resonable state.  If they have created custom modules, they would
not lose them - they would just be disconnected from the "sockets."

Frankly, I am tired of giving up power in the name of so-called "ease of
use."  If we followed that rule with shells, we would never have had pipes
because they are just "too confusing."  Developers should not be creating a
padded cell for the users - they should be providing them with basic,
powerful and natural tools to manipulate information.

When I use software, I want to feel like I'm in the kitchen, not at 
McDonald's being asked if I would like "to SuperSize that."  Except there's
more than just knives and sieves in this kitchen - there are pasta makers,
and burger makers, and some prepackaged tortellini salad, and freeze-drying
machines.  And they're all right where they should be.  So when Tim Allen
walks into the kitchen without a scrap of culinary knowledge, he pushes some
buttons on that burger-maker and he's done.  Then Julia Child walks in and
fashions some fantastic plate.  The kitchen for everyone.  The key thing is
that there's no menu, and no dumb waiter asking you if you want a salad, and
what kind of dressing, and so forth.  You do it yourself, but you don't need
to know how.

Recommended reading:
  About Face: The Elements of User Interface Design by Alan Cooper
    (I don't always agree with him, but he sure makes you think)
  Design Patterns by the Gang of Four
    (can provide many ideas on how to implement configurability)

/-------- Quantum Seep, qseep@iname.com ---
  "His funny bone's connected to the M-bone"
   PGP fingerprint: 5B 3B 7B EC AA 5B 4B 7F  65 7D 2A CD 69 11 29 2A

On Thu, 17 Sep 1998, Reklaw wrote:

> 
> I like the idea of cobra objects (baboon hopefully) for everything.
> I keep saying flexiblity is key.
> I think the user should NEVER see a setup or "wiring panel" for
> the objects though. Let the user select "page layout view" or "outline
> view" and switch rendering objects under the hood.
> Sure, you could provide a wiring panel for setting the wiring
> for each view, but....
> 1) Sooner or later, some nimrod is going to tell an end user to go
> fiddle with the "wiring panel" and  they will have a mess.
> 2) Clearly written question and answer session style configuration
> is easier for newbie (as long as they can click a "Don't Care" button 
> and the app still works). I don't care how you cut it - Drag-N-Drop
> is not intuitive to newbies. These people have trouble clicking on
> buttons much less drag-n-drop. even if newbies arn't the target users,
> some will still try to use it - might as well attempt give them
> something easy to use so they don't give the project a bad rep.
> 3) I think "task-oriented object switching" will give them/us enough
> flexiblity. If someone wants to install an alternate "normal view
> render engine" then making the connections to the right "sockets" 
> should be an issue for that engines install. Don't force the end user
> to acknowledge that they have a "weird" setup.