Re: Magical Thinking

Subject: Re: Magical Thinking
From: "Wing, Michael J" <mjwing -at- INGR -dot- COM>
Date: Fri, 16 Jan 1998 08:44:55 -0600

<snip>

> For instance, in response to Mike Wing's multi-variable example, Geoff
> pointed out that tables, flowcharts and decision trees can all be
> effective ways to present the schema. However, these structures can be
> presented in a million different styles - cartoons, clinical, folksy,
> cool, authoritative, cosy, illustrated (in Mike's map example, is it
> feasible to illustrate the outputs instead of labelling or describing
> them), numerical, and so on.
>
> Sandra
>
> My words, not Masterpack's
>
Flowcharts, cartoons, decision trees, and so forth aid in learning the
sequence of what to choose and in which order to choose them but still
does not satisfy the need for the user to understand the ramifications
of combining choices. It is not always possible to illustrate the
outputs. If a GUI has two parameters (each with only two settings),
there are four possible outputs; add another two-setting parameter and
there are now eight possible outputs. If two parameters each have ten
settings, there are a hundred possible outputs. Now, illustrate the
outputs for 10 parameters with a selection of settings ranging from 2 to
25.

It is my point that in some applications, the user needs a theoretical
understanding of what the software does with the input selections so
that they can interpolate the expected results. Often, these types of
applications use successive approximations in which the user gets within
range of the expected results on the first iteration and then tweaks the
input parameters to reach the goal. In my map example, what will
setting the line width to 0.002 do if my scale is 1:50000? What if I
select to display only by scale and use these settings? How about if I
change my azimuth while displaying by scale and using a line width of
0.002? Just providing "press this, key-in that, and then press this"
instructions are only the mechanics to perform after the decisions have
been made. The complexity of possible outcomes precludes charting the
outcomes. Therefore, the user must understand how the software
processes the parameter data so that they can arrive at the expected
results at some other means than trial and error.

Mike

Michael Wing (mailto:mjwing -at- ingr -dot- com)
Principal Technical Writer
Intergraph Corporation; Huntsville, Alabama
http://www.ingr.com/iss/products/mapping/
(205) 730-7250




Previous by Author: Re: Magical thinking?
Next by Author: Re: Programming Languages for Technical Communication
Previous by Thread: Re: Magical Thinking
Next by Thread: Dynopage


What this post helpful? Share it with friends and colleagues:


Sponsored Ads