[comp.human-factors] ap, Windows BASIC

mathew@mantis.co.uk (Giving C News a *HUG*) (06/26/91)

enag@ifi.uio.no (Erik Naggum) writes:
> Can you imagine a telephone which is so easy to use that you don't
> need any time learning how to use it?  [...]
>               Now think of all the incredible losers in the world who
> could actually _need_ a menu-based phone.

You certainly picked a bad example there.

Telephones are *incredibly* badly designed; everything from the upside-down
keypad to the stupid numeric "star 2 6 hash" commands.

There are week-long training courses for secretaries to teach them to use
their telephones, because the telephones are so appallingly badly designed.
Most businessmen have no idea how to use their telephones for even a quarter
of the things they can be used for.

I used to use a telephone with features like forward call, redial, multiple
lines, and so on; it had oodles of those little dinky calculator-style
buttons all over it, and loads of multi-coloured LEDs.  It was like Wesley's
control panel in Star Trek.

In order to make it useful, there was a one-page "Quick Reference Card",
listing all the stupid numeric codes you were supposed to remember in order
to do everyday things like tranferring calls.

I sat and looked at the card, doodled on some paper for a bit, and worked out
that you could encode just about every function supported by this telephone
into about ten or twenty buttons.  The buttons would have words on them, and
you'd indicate what you wanted to do by pushing buttons to make a sentence. 
The buttons would be arranged in columns going from left to right, so you'd
pick no more than one from each column.

Of course, it would be trickier to decode internally.  So we have telephones
with "[*] [5] [6] [#] [2] [3]" instead of "[Transfer call] [to] [2] [3]",
because it's easier for the hardware people to handle.  And we have telephones
with one button for each combination of operations, rather than a smaller set
of buttons which you can push more than one of.

It was almost enough to make me want to buy a Mac just so that I could use
Hypercard to design a proper telephone front-end and have the Mac beep the
correct tones into my bozo-phone.


mathew

 

gorman@acsu.buffalo.edu (anne-marie k gorman) (06/27/91)

In article <PLi6424w164w@mantis.co.uk> mathew@mantis.co.uk (Giving C News a *HUG*) writes:

>Telephones are *incredibly* badly designed; everything from the upside-down
>keypad...

Actually, from the point of view of the phone company, teh upside-down keypad 
is very well designed.  Back when push-button phones were being invented,
extensive testing was carried out to see which configuration of buttons gave
the lowest number of incorrectly dialed numbers.  Since the phone company
gives you credit when you dial a wrong number, but it still cost them money
to put the call through, they wanted to minimize their costs by minimizing
teh number of calls that they would have to issue credits for.  Their experi-
ments showed that the 'upside-down' layout minimized errors, even though it
was different from teh 'standard' adding-machine style layout.

Anne-Marie

mcgregor@hemlock.Atherton.COM (Scott McGregor) (06/28/91)

In article <PLi6424w164w@mantis.co.uk>, mathew@mantis.co.uk (Giving C
News a *HUG*) writes:
>enag@ifi.uio.no (Erik Naggum) writes:
>> Can you imagine a telephone which is so easy to use that you don't
>> need any time learning how to use it?  [...]
>>               Now think of all the incredible losers in the world who
>> could actually _need_ a menu-based phone.

You certainly picked a bad example there.

> Telephones are *incredibly* badly designed; everything from the upside-down
> keypad to the stupid numeric "star 2 6 hash" commands.

I don't have the reference, but I once read a number of articles about the
design of the touch tone key pad.  Both the adopted style (1 top left, 9
bottom right) and the "calculator style" (1 bottom left, and 9 bottom
right) were
tried.  The adopted style was heavily preferred over the calculator style.
Some reasons were that at the time, only a small minority of people
regularly used calculators at the time.  Additionally, many prefixes
were still given in alphabetic mode: (PEnnsylvania 6-5000!) and people
were confused looking for the ABC (already associated with number 2 from
dial days) at the bottom middle position.  So while the keypad may seem
backward today, it may have been a victim of "backward compatability" to
dials, and the typical knowledge skills of yesteryear.  (It is also
interesting to note that children often have a hard time learning to use
calculator style keyboards because they are used to looking for the "1"
at the top!

> There are week-long training courses for secretaries to teach them to use
> their telephones, because the telephones are so appallingly badly designed.
> Most businessmen have no idea how to use their telephones for even a quarter
> of the things they can be used for.

Don Norman has written and lectured considerably about the reduced
features in todays all electronic (12 or 13 key) phones where features
are all overloaded 
on the numeric keys,  vs. the old days with the multiple button -multi line
mechanical sets, with the blinking hold button, etc.  His comments are
great.

> I sat and looked at the card, doodled on some paper for a bit, and worked out
> that you could encode just about every function supported by this telephone
> into about ten or twenty buttons.  The buttons would have words on them, and
> you'd indicate what you wanted to do by pushing buttons to make a sentence. 
> The buttons would be arranged in columns going from left to right, so you'd
> pick no more than one from each column.

> Of course, it would be trickier to decode internally.  So we have telephones
> with "[*] [5] [6] [#] [2] [3]" instead of "[Transfer call] [to] [2] [3]",
> because it's easier for the hardware people to handle.  And we have 
> telephones with one button for each combination of operations, rather than a
> smaller set of buttons which you can push more than one of.

Not so hard to decode as you might think.  I once visited with a manager
who purchased a ten memory autodialer. It was connected on the line just in
front of his normal phane, had ten keys each with a label area. The first one
was hand labelled HOLD (CALL PARK), the second was UNHOLD (CALL RETRIEVE), then
CALL TRANSFER, CALL FORWARD ON, CALL FORWARD OFF, AREA PICKUP,
VOICEMAIL, SECRETARY, BOSS, and finally HOME.  Obviously, the first 6
were all just telephone features of the *56#23 variety, and only the
last 4 actual other phones to call.  An obvious solution to the problem
of remembering those codes, but one that seems seldom used.  He said he
got the autodialer himself from some electronics store Radio Shack for a
few bucks of his personal money, and he felt they were well spent.

Scott McGregor
Atherton Technology
mcgregor@atherton.com

 

mathew@mantis.co.uk (Industrial Poet) (06/28/91)

gorman@acsu.buffalo.edu (anne-marie k gorman) writes [about telephone
keypads]:
>                                                                Their experi-
> ments showed that the 'upside-down' layout minimized errors, even though it
> was different from teh 'standard' adding-machine style layout.

I think that's probably because it slows people down; which is also a good
idea from the telephone company's point of view (here in the UK we are only
now getting rid of the last mechanical exchanges.)


mathew

 

msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) (06/28/91)

In <81437@eerie.acsu.Buffalo.EDU> gorman@acsu.buffalo.edu (anne-marie k gorman) writes:

>Actually, from the point of view of the phone company, teh upside-down keypad 
>is very well designed.  Back when push-button phones were being invented,
>extensive testing was carried out to see which configuration of buttons gave
>the lowest number of incorrectly dialed numbers.  Since the phone company
>gives you credit when you dial a wrong number, but it still cost them money
>to put the call through, they wanted to minimize their costs by minimizing
>teh number of calls that they would have to issue credits for.  Their experi-
>ments showed that the 'upside-down' layout minimized errors, even though it
>was different from teh 'standard' adding-machine style layout.

I for one mess up on phone keypads all the time.  I'm always hitting 3
when I mean 9, or whatever.  In any case, the reasons for choosing the
telephone layout back in the semi-distant past may have been good, but
why must *all* phones today use it?  Why can't I get any phone with a
keypad laid out like the computers and calculators that I and so many
other people use so much?  

Why not a little switch so I can have it either way, like the switch
on the bottom of my Northgate computer keyboard to swap the caps lock
and control from the historically correct layout to the usable layout?
Of course, then you'd have a keycap problem.  I'm sure that could be
overcome.  We could call it the programmer's phone.  The phone mortal
lusers wouldn't understand.


--

< Michael Pereckas  <>  m-pereckas@uiuc.edu  <>  Just another student... >
``You can be real patient if you don't have a central nervous system''
                                                       ---Dr. Ronald Pine

mrs@netcom.COM (Morgan Schweers) (06/29/91)

Some time ago mathew@mantis.co.uk (Giving C News a *HUG*) happily mumbled: 
>enag@ifi.uio.no (Erik Naggum) writes:
>> Can you imagine a telephone which is so easy to use that you don't
>> need any time learning how to use it?  [...]
>>               Now think of all the incredible losers in the world who
>> could actually _need_ a menu-based phone.
>
>You certainly picked a bad example there.
>
>Telephones are *incredibly* badly designed; everything from the upside-down
>keypad to the stupid numeric "star 2 6 hash" commands.
>
>[much support for Erik's comment deleted]
Greetings,
    Heh heh heh...  So let me get this straight.  You would prefer a
mildly powerful but 100% unportable development system over a VERY
powerful and portable system.  Right?

    To clarify...  VB is, evidently, a reasonable adaptation of BASIC.
Claiming, however, that this legitimizes BASIC is like putting a powerful
engine in a VW Bug to convince people to buy VW Bugs.  All these new features
are 'bags on the side' of BASIC.  It makes it 'better', but doesn't change
the important information about the language.  (Like it's lack of pointers,
and it's lack of proper syntax checking.)

    If you do use VB as a language, you'll never be able to port your
application to another environment.  If you use C[++] as a language
you'll be able to port to *FAR* more systems, easily.  If portability
isn't an issue *AND* pointers aren't needed, then you're not likely
doing much real programming.  Either that, or you're a wee bit short-
sighted.  (There comes a time in most projects when someone says,
"Oooh!  Wouldn't it be Neat-O-Keen if we could sell this under the
XYZZY platform as well?"  Either that or, "Oh!  The LOS (Little Operating
System) isn't the Hot Thing(tm) anymore!  I guess we'll all port our
software to the BOS (Bigger Operating System)!")
    In summary, Get A Real Language!  (*heh heh heh*  I love comp.flame... I
can say things like that!)

    The person who claimed that C and Pascal wouldn't warn you about mistyped
variables made me laugh...  I love it when people rail against languages
they've clearly never used.  *grin*  C assumes that the programmer is right,
but also assumes that the programmer *CAN BE WRONG*!  If it didn't assume that
then there wouldn't be any compile-time error messages.  As someone else said,
the 'Oh!  A new variable!  No problem!' approach went out with some random
early version of Fortran.

    I'm reading this from comp.flame, so I don't want to hear about
inappropriate crossposting!

>mathew
                                                    --  Morgan Schweers

P.S.  If YOUR site doesn't get comp.flame, COMPLAIN TO YOUR ADMINISTRATOR!
-- 
mrs@netcom.com   |   Morgan Schweers   |  Good code, good food, good sex.  Is
ms@gnu.ai.mit.edu|   These messages    |  anything else important?  --  Freela
Kilroy Balore    |   are not the       +--------------------------------------
Freela           |   opinion of anyone.|  I *AM* an AI.  I'm not real...

feustel@netcom.COM (David Feustel) (06/29/91)

I'm not sure what proper syntax checking is, but VB does some
checking.  Also, the big plus of VB is the ease of putting together
windows-interfaced applications. You can write DLLS in C++ and call
them from VB to do the computation, letting VB handle the windows.
-- 
David Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805, (219) 482-9631
EMAIL: feustel@netcom.com  

I voted for Bush once.  As it's turning out, once was once too often.