(None -- partial burst of Info-Mac Digest V7 #20)
Posted: November 21st, 1989, 1:42 am
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!aplcen!haven!udel!rochester!cornell!batcomputer!rpi!rpiburst!rpi!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!SUMEX-AIM.STANFORD.EDU!Info-Mac-Request
From: [email protected] (Tom Coradeschi)
Newsgroups: comp.sys.mac.digest
Subject: (None -- partial burst of Info-Mac Digest V7 #20)
Message-ID:
Date: 1 Nov 89 15:08:11 GMT
Lines: 129
Approved: [email protected]
This was posted to the risks-digest today. An interesting evaluation of what
it takes to make system of this kind work, and an outstanding look at what
can be done with Macs, if one takes the time to pull it all together
properly...
tom c
----- Forwarded message # 1:
Date: Mon, 30 Oct 89 04:03:27 EST
>From: [email protected] (Alexis Rosen)
Subject: Work processes which are done faster by hand than by machine
I'm a newcomer to risks (not the net) but I've followed the discussion of
slow computer vs. fast manual systems. This is a subject which I've some
familiarity with, and right now I'm just finishing the installation of a
very high-volume POS (point of sale) system implemented on (can you believe
it?) a network of Macintoshes, with receipt printers, cash drawers, and
bar-code scanners.
I have done other systems before which demanded speed, but this job was the
most interesting and difficult I have faced. From it I have learned a
number of things about the speed that can be achieved with computer systems
in the face of real-world problems.
Problem #1: Careless and unintelligent employees.
Many employees, especially in the kinds of positions that wind up being
automated (cashiers, tellers, etc.) are somewhat less than brilliant. If they
were smarter they'd be rocket scientists, right?
There are many who are
not dumb, and they can be worse, because boredom can make them incredibly
careless.
Solution: Management has to be involved in maintaining a decent workplace,
but there are still many things you can do to keep new technology from adding
to the trouble (which would exist no matter what). I followed the "spirit"
of the Mac interface, which really just means being aware of human factors-
I could not use a mouse *at all*, so goodbye menus and icons. In general,
_everything_ has to be 100% bulletproofed and idiotproofed. These are not the
same thing at all- one protects against illegal values completely, while the
other warns against (but usually doesn't forbid) stupid values.
Example: After a couple of days, employees become aware of the general flow
of events in the program, so they stopped looking at the messages for them
on the screen- in fact they often didn't look at all. They were often unaware
of conditions that required immediate action (bad price entered, for example).
One solution to this particular problem was to create three distinct sounds
that notified users of acknowledgement, notification, and error conditions.
Problem #2: Forgotten Features (and other training issues)
If the system can do so much, how come it's used for so little? Because nobody
remembers how to do this, that, and the other thing. So they all do _this_
instead of _that_ and simply keep paper notes, or figure out some other way
to do less work and screw up the system. Don't fight it, because you'll lose.
Solution: Make sure everything is accessible. Write software that requires
a minimum of training. You want specifics? Start with the Apple Human Interface
Guidelines, and then there's _lots_ of other literature. But to begin with,
don't hide features, don't use cryptic codes when simple english will do, and
don't expect your users to know what they're doing- literally. Either tell
them where they are at all times (unobtrusively, of course) or failing that,
allow them to back out gracefully. *** BE CONSISTENT *** and don't expect
users to be the same.
Example: My POS system replaces standard cash registers. It does much much more
and yet takes one-quarter the time to learn. And the features aren't forgotten.
One Mac-ish thing it does is use title bars on all of the windows which aren't
instant-response windows (modal dialogs). The title bars say who is logged in
and what they're doing at all times.
Problem #3: Slow and/or increased data entry
Many computer systems require the tracking of much more information than the
old manual systems. This can create the illusion of lethargic system speed
even if the hardware is quite fast. Users can be frustrated by the extra
load, which may well feel like makework to them. The speed of entry itself
may be slow if data is validated on-the-fly as it's entered.
Solution: First, tune the software. You can acheive remarkable things by
using (or, unhappily more often, faking) multi-threading -- do the validation,
but _don't_ stop data entry while you're validating. Overlap various hard
delays- print while you're writing to disk, or calculate while verifying a
credit number with a remote machine.
After all this helps, but isn't good enough, start buying hardware. This
may well be the best part of the system to invest in. Special data-entry
hardware can make a _huge_ difference.
Example: After tuning the POS software, there was still an inevitable slowdown
since the cashiers were entering price and item information instead of just
the price (as on the old registers). This was costing up to fifteen seconds
_per item_, which was completely intolerable. The solution was to buy bar-code
scanners, which could enter both item # and price (both of which are typically
on the item to begin with). This dramatically improves the performance of the
item-entry process.
Problem #4: Lazy programming.
Yes, I am as lazy as the next guy. Often, I'd like the real world to fit a
neat conceptual model I have developed for it. When a case comes up that I
can't handle, I'd rather contort it to fit my code rather than the other way
around. Sometimes this is feasible, and once in a while, it can lead to
marked improvements- but if so, it just identifies an improvement that should
have been realized earlier in the design process. Most of the time, shoehorning
real procedures into flowcharts is a recipe for disaster.
Solution: In that case, recode. It's as simple and as painful as that.
Sometimes you'll wind up with pages and pages of code to deal with a handful
of exceptions that won't come up but once a year. Tough luck- that's what
being a good programmer is all about.
Example: I designed the POS system so that every item sold would already be
in the database. I went to great lengths to insure this, since it would make
life much easier for both myself and all of the users. Unfortunately this
can't always work- at times items may be checked in with faulty item codes,
for example. Modifying the system to deal with unexpected item codes was
one of the most annoying and inelegant things I have ever had to do, but now
it works, and people no longer complain about having to work around a system
which is supposed to make their work easier, not harder.
There is more, but I think that this is more than enough for my first risks
posting. The point of this is that the system I built is not only more
capable and useful than the old, but is considerably more efficient up front,
as well. I think that this achievement could easily be duplicated elsewheres
if programmers were more aware of the real-life processes they are trying to
model, and the real-life problems their systems will have to deal with.
Alexis Rosen, President, Arete Corp. (Hat #1)
Sysadmin/Owner, PANIX public access Unix (Hat #2)
cmcl2!panix!alexis -or- [email protected]
----- End of forwarded messages
From: [email protected] (Tom Coradeschi)
Newsgroups: comp.sys.mac.digest
Subject: (None -- partial burst of Info-Mac Digest V7 #20)
Message-ID:
Date: 1 Nov 89 15:08:11 GMT
Lines: 129
Approved: [email protected]
This was posted to the risks-digest today. An interesting evaluation of what
it takes to make system of this kind work, and an outstanding look at what
can be done with Macs, if one takes the time to pull it all together
properly...
tom c
----- Forwarded message # 1:
Date: Mon, 30 Oct 89 04:03:27 EST
>From: [email protected] (Alexis Rosen)
Subject: Work processes which are done faster by hand than by machine
I'm a newcomer to risks (not the net) but I've followed the discussion of
slow computer vs. fast manual systems. This is a subject which I've some
familiarity with, and right now I'm just finishing the installation of a
very high-volume POS (point of sale) system implemented on (can you believe
it?) a network of Macintoshes, with receipt printers, cash drawers, and
bar-code scanners.
I have done other systems before which demanded speed, but this job was the
most interesting and difficult I have faced. From it I have learned a
number of things about the speed that can be achieved with computer systems
in the face of real-world problems.
Problem #1: Careless and unintelligent employees.
Many employees, especially in the kinds of positions that wind up being
automated (cashiers, tellers, etc.) are somewhat less than brilliant. If they
were smarter they'd be rocket scientists, right?
There are many who arenot dumb, and they can be worse, because boredom can make them incredibly
careless.
Solution: Management has to be involved in maintaining a decent workplace,
but there are still many things you can do to keep new technology from adding
to the trouble (which would exist no matter what). I followed the "spirit"
of the Mac interface, which really just means being aware of human factors-
I could not use a mouse *at all*, so goodbye menus and icons. In general,
_everything_ has to be 100% bulletproofed and idiotproofed. These are not the
same thing at all- one protects against illegal values completely, while the
other warns against (but usually doesn't forbid) stupid values.
Example: After a couple of days, employees become aware of the general flow
of events in the program, so they stopped looking at the messages for them
on the screen- in fact they often didn't look at all. They were often unaware
of conditions that required immediate action (bad price entered, for example).
One solution to this particular problem was to create three distinct sounds
that notified users of acknowledgement, notification, and error conditions.
Problem #2: Forgotten Features (and other training issues)
If the system can do so much, how come it's used for so little? Because nobody
remembers how to do this, that, and the other thing. So they all do _this_
instead of _that_ and simply keep paper notes, or figure out some other way
to do less work and screw up the system. Don't fight it, because you'll lose.
Solution: Make sure everything is accessible. Write software that requires
a minimum of training. You want specifics? Start with the Apple Human Interface
Guidelines, and then there's _lots_ of other literature. But to begin with,
don't hide features, don't use cryptic codes when simple english will do, and
don't expect your users to know what they're doing- literally. Either tell
them where they are at all times (unobtrusively, of course) or failing that,
allow them to back out gracefully. *** BE CONSISTENT *** and don't expect
users to be the same.
Example: My POS system replaces standard cash registers. It does much much more
and yet takes one-quarter the time to learn. And the features aren't forgotten.
One Mac-ish thing it does is use title bars on all of the windows which aren't
instant-response windows (modal dialogs). The title bars say who is logged in
and what they're doing at all times.
Problem #3: Slow and/or increased data entry
Many computer systems require the tracking of much more information than the
old manual systems. This can create the illusion of lethargic system speed
even if the hardware is quite fast. Users can be frustrated by the extra
load, which may well feel like makework to them. The speed of entry itself
may be slow if data is validated on-the-fly as it's entered.
Solution: First, tune the software. You can acheive remarkable things by
using (or, unhappily more often, faking) multi-threading -- do the validation,
but _don't_ stop data entry while you're validating. Overlap various hard
delays- print while you're writing to disk, or calculate while verifying a
credit number with a remote machine.
After all this helps, but isn't good enough, start buying hardware. This
may well be the best part of the system to invest in. Special data-entry
hardware can make a _huge_ difference.
Example: After tuning the POS software, there was still an inevitable slowdown
since the cashiers were entering price and item information instead of just
the price (as on the old registers). This was costing up to fifteen seconds
_per item_, which was completely intolerable. The solution was to buy bar-code
scanners, which could enter both item # and price (both of which are typically
on the item to begin with). This dramatically improves the performance of the
item-entry process.
Problem #4: Lazy programming.
Yes, I am as lazy as the next guy. Often, I'd like the real world to fit a
neat conceptual model I have developed for it. When a case comes up that I
can't handle, I'd rather contort it to fit my code rather than the other way
around. Sometimes this is feasible, and once in a while, it can lead to
marked improvements- but if so, it just identifies an improvement that should
have been realized earlier in the design process. Most of the time, shoehorning
real procedures into flowcharts is a recipe for disaster.
Solution: In that case, recode. It's as simple and as painful as that.
Sometimes you'll wind up with pages and pages of code to deal with a handful
of exceptions that won't come up but once a year. Tough luck- that's what
being a good programmer is all about.
Example: I designed the POS system so that every item sold would already be
in the database. I went to great lengths to insure this, since it would make
life much easier for both myself and all of the users. Unfortunately this
can't always work- at times items may be checked in with faulty item codes,
for example. Modifying the system to deal with unexpected item codes was
one of the most annoying and inelegant things I have ever had to do, but now
it works, and people no longer complain about having to work around a system
which is supposed to make their work easier, not harder.
There is more, but I think that this is more than enough for my first risks
posting. The point of this is that the system I built is not only more
capable and useful than the old, but is considerably more efficient up front,
as well. I think that this achievement could easily be duplicated elsewheres
if programmers were more aware of the real-life processes they are trying to
model, and the real-life problems their systems will have to deal with.
Alexis Rosen, President, Arete Corp. (Hat #1)
Sysadmin/Owner, PANIX public access Unix (Hat #2)
cmcl2!panix!alexis -or- [email protected]
----- End of forwarded messages