[MUD-Dev] When the interface becomes the challenge.

[Edward Glowacki]

Quoted from J C Lawrence on Tue, Jul 03, 2001 at 08:14:48PM -0700:

>> ... but I don't feel as good using it as I did when I used PINE.
>> PINE just *felt* good to use, and I never felt like a stray
>> keystroke was going to hurt anything.  With Mutt, I'm not so
>> confident.
 
> I suspect the critical fact is that Mutt has a far larger feature
> set that you are comfortably familiar with and so you suspect that
> any errant action on your part may invoke a feature that you both
> do not know and do not know how to rescue/exit from.

I think it goes beyond the feature set and familiarity.  You
mentioned something above (which I cut from the reply) about "small
changes can have big effects", and I think that applies here.

Actually, PINE has a good design philosophy.  Here's a quote
from the PINE website (http://www.washington.edu/pine/overview/):

  "The guiding principles for Pine's user-interface were: careful
  limitation of features, one-character mnemonic commands,
  always-present command menus, immediate user feedback, and high
  tolerance for user mistakes.

  It is intended that Pine can be learned by exploration rather than
  reading manuals."

"careful limitation of features" seems to manifest itself by having
a configuration screen (or you can edit the rc file) that allows you
to turn off things you don't need.  If you think about having a
"high tolerance for user mistakes" when you're designing something,
then you're likely to end up with a product that responds better to
user input in the general case.  Finally, "learned by exploration"
is another very good design philosophy.  With PINE, you have a menu
of all available commands at the bottom of the screen, showing you
*visibly* what choices are available.  With Mutt, you have a very
small menu of visible actions and everything else is hidden.  You
can figure out what keys do, but you have to bring up the help
screen to do that, which of course has to be hidden again before you
can actually *do* the command.

>> They should be running the show, and the computer should be
>> adapted to the way *they* work instead of them adapting to the
>> way the computer works.

> I usually phrase this in terms of tool building and tool builders.
> I am a tool builder.  I make and use tools.  Many of the tools I
> use I built.  The computer is a tool that I use to build other
> tools.  As such, I use the computer to build tools to build other
> tools with, and I build the computer into a tool to enable me to
> work the

What I was referring to (in the nested first block of quote) is that
software should be designed for the way the user works, not the way
that's easiest to code or more directly translates into code or any
other technical reason.  When building software, it's necessary to
think from the end-user side, figure out what the flow of their work
is and how they conceptualize things, then build the software around
that, or at least with that in mind.

This includes things such as picking the right widget for the job.
For example, web forms that ask to fill in your state by using a 50
item pulldown menu.  Sure, it's easy to code, you don't really have
to validate the input because the user's choice is limited.  But
it's much easier for a user to just type it in, because they're
already typing everything in anyways, and they even probably have
some nice habits built in to enter "city [tab] state [tab] zipcode".
The interface is usable with the pulldown menu, it's just not as
nice to use because it was designed from the technical side instead
of the user side.

Building tools to do a task is fine, there's no problem with that.
If you're going to be the only user of that tool, then however works
best for you is the way to build it.  But if it's a program that's
going to be used by a large number of people, it needs to be
designed that way.  The problem with a lot of software today is that
it's written with functionality as its primary purpose, and the main
usability criteria is that it's usable by the program's author.
Programmers write programs for people like themselves.  It's enough
that something can *be* done (playing DVD's on Linux, having a
high-performance web server, etc.), it's not required that the same
tool also be usable by someone who doesn't understand what "rm -rf
*" will do.  (For reference, I'm primarily a Unix user, and I do
write code, usually only small projects though.  So a lot of what
I'm saying is aimed at Unix, though Microsoft has plenty of
usability issues of its own...)

If you're building tools to build tools, you still want to work in
an environment where the tools you are using are well designed.
Imagine trying to work inside a computer case with a screwdriver
with a long shaft that has a basketball for a handle: it might be
physically possible to remove a screw, but the design of the tool
makes the job unnecessarily difficult.  There's a reason
screwdrivers are the way they are, and there's a reason you can go
out and buy short stubby ones for working in tight spaces.  A lot of
software "tools" out there more closely resemble the
basketball-handled screwdriver end of the spectrum, they're hard to
use, and really not quite adaquate for the job, but for lack of
something better, they get used.  Software needs to evolve, the same
way hand tools have evolved over the years.

> way I deem best.  In the end everything is a tool and therefore
> subject to customisation and tailoring to the job at hand.

"customisation and tailoring to the job at hand" can mean a lot of
different things.  It can mean something simple like checking some
boxes in a preference screen, or it can be something as complex as
rewriting half the source code for a program, or even something
cosmetic like changing the color.  However, if you think about hand
tools again, how much customization is really needed to do the job
at hand?  Their design is good and therefore the tool can be used
immediately for a great variety of tasks.


ED

--
Edward Glowacki			glowack2 at msu.edu
"Speak softly and carry a +6 two-handed sword."  --fortune
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev