1969 networked word processor "Astrotype"

[hanc...@bbs.cpcn.com]

[I have no idea how well the product described below sold in the market, nor how it fared against IBM's MagTape Selectric. I've found other references to this particular device--see below for links.]

From Jan 1969 C&A:

SECRETARIES GET A COMPUTER OF
THEIR OWN TO AUTOMATE TYPING

The Automatic Office Div. of
Information Control Systems, Inc.,
Ann Arbor, Mich. recently introduced
their new Astrotype system
-- a small desk drawer computer
linked to a group of typewriters
to give each of the typewriters
automatic, error-editing capability.

The typewriters can produce
perfect, error-corrected letters
as a result of the link-up. Corrections
in a letter are made automatically
when the typist strikes
over the wrong character while typing,
or when she gives the computer
a special footnote to the letter.
The computer follows up by driving
the typewriter through an automatic,
high speed re-type of the
letter which has been refined to
100% perfection.

A whole network of typewriters
can simultaneously share the control
capability of the tiny computer,
meaning that every typist
in an office can be using her machine
for perfect typirig at once.
Since letters are filed in the
computer's memory and can be recalled
at any time, the office's
physical correspondence file can
be eliminated.

David Carlson, president of the
Automatic Office Div. of I.C.S.,
said the controller is "a true
programmable computer which has
most of the same capabilities
found in larger systems." The
computer is, however, "dedicated"
to the automatic, error-editing
typing function by its special
software.

The low cost of the system derives
from two points: the software
makes ingenious use of the
computer's small (4K) core memory;
and the new computer utilizes space
and cost saving integrated circuits.
The desk drawer control unit measures
only 16 x 20 x 9 inches.

The Astrotype system accepts all
editing requests via the standard
typewriter keyboard, and can be operated
by any typist with only an
hour's instruction.

see also:
http://technologizer.com/2009/08/21/word-processing-circa-1968/

http://www.ltu.edu/leaders/bio_050509.asp

source:
http://bitsavers.informatik.uni-stuttgart.de/pdf/computersAndAutomation/196901.pdf

[jmfbahciv]

Now find a secretary who used it. Ask her how many swear words she
invented. ;-)

/BAH

[Shmuel Metz]

In <PM0004E02...@aca22c0e.ipt.aol.com>, on 06/27/2013

at 01:09 PM, jmfbahciv <See....@aol.com> said:

>Now find a secretary who used it. Ask her how many swear words she
>invented. ;-)

Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
then the developers would have had more resources to make it user
friendly. But then it would have cost more.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[John Levine]

>Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>then the developers would have had more resources to make it user
>friendly. But then it would have cost more.

Depends more on the developers. There was a newspaper typesetting
system based on a PDP-8 that the users all loved. I hear it was a
great improvement over the PC based systems that followed it.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Walter Bushell]

In article <kqihtr$30uc$1...@leila.iecc.com>,

John Levine <jo...@iecc.com> wrote:

> >Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
> >then the developers would have had more resources to make it user
> >friendly. But then it would have cost more.
>
> Depends more on the developers. There was a newspaper typesetting
> system based on a PDP-8 that the users all loved. I hear it was a
> great improvement over the PC based systems that followed it.

Except for cost, of course.

--
Gambling with Other People's Money is the meth of the fiscal industry.
me -- in the spirit of Karl and Groucho Marx

[Rich Alderson]

John Levine <jo...@iecc.com> writes:

>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>> then the developers would have had more resources to make it user
>> friendly. But then it would have cost more.

> Depends more on the developers. There was a newspaper typesetting
> system based on a PDP-8 that the users all loved. I hear it was a
> great improvement over the PC based systems that followed it.

Umm, TYPSET-8 was the front end for TYPSET-10, which ran on (wait for it) a
PDP-10. The Chicago Tribune used it, for example; my bridge partner at
UChicago was the former system manager for the Tribune's setup.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[Rich Alderson]

Walter Bushell <pr...@panix.com> writes:

> In article <kqihtr$30uc$1...@leila.iecc.com>,
> John Levine <jo...@iecc.com> wrote:

>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>>> then the developers would have had more resources to make it user
>>> friendly. But then it would have cost more.

>> Depends more on the developers. There was a newspaper typesetting
>> system based on a PDP-8 that the users all loved. I hear it was a
>> great improvement over the PC based systems that followed it.

> Except for cost, of course.

Especially when you add in the DECsystem-10 doing the backend processing.

[John Levine]

>> Depends more on the developers. There was a newspaper typesetting
>> system based on a PDP-8 that the users all loved. I hear it was a
>> great improvement over the PC based systems that followed it.
>
>Except for cost, of course.

The problem was more likely that they couldn't get parts for the old
system any more.

[John Levine]

>> Depends more on the developers. There was a newspaper typesetting
>> system based on a PDP-8 that the users all loved. I hear it was a
>> great improvement over the PC based systems that followed it.
>
>Umm, TYPSET-8 was the front end for TYPSET-10, which ran on (wait for it) a
>PDP-10. The Chicago Tribune used it, for example; my bridge partner at
>UChicago was the former system manager for the Tribune's setup.

I gather that was the large model. For small shops, the PDP-8 did it all.

http://research.microsoft.com/en-us/um/people/gbell/Digital/timeline/1968-3.htm

[jmfbahciv]

Rich Alderson wrote:
> Walter Bushell <pr...@panix.com> writes:
>
>> In article <kqihtr$30uc$1...@leila.iecc.com>,
>> John Levine <jo...@iecc.com> wrote:
>
>>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>>>> then the developers would have had more resources to make it user
>>>> friendly. But then it would have cost more.
>
>>> Depends more on the developers. There was a newspaper typesetting
>>> system based on a PDP-8 that the users all loved. I hear it was a
>>> great improvement over the PC based systems that followed it.
>
>> Except for cost, of course.
>
> Especially when you add in the DECsystem-10 doing the backend processing.
>

You didn't have to have a PDP-10 in the backend but newspapers had
typeset-10 running on the -10. I suppose some setups may have had
Typeset-8s in "lcoal" areas which then transferred the end product
to the -10 for page setup.

The typesetting products for the 10 and 8 were two different
products. We didn't run Typeset-8 in Marlboro; we did run
Typeset-10.

/BAH

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:
> In <PM0004E02...@aca22c0e.ipt.aol.com>, on 06/27/2013
> at 01:09 PM, jmfbahciv <See....@aol.com> said:
>
>>Now find a secretary who used it. Ask her how many swear words she
>>invented. ;-)
>
> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
> then the developers would have had more resources to make it user
> friendly. But then it would have cost more.
>

I'm not talking about user-friendly. I'm talking about whiz-bangs
which the coder thought neat and the secretary had to wrestle the
system to the ground to get what she needed on the piece of paper.

/BAH

[jmfbahciv]

John Levine wrote:
>>Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>>then the developers would have had more resources to make it user
>>friendly. But then it would have cost more.
>
> Depends more on the developers. There was a newspaper typesetting
> system based on a PDP-8 that the users all loved. I hear it was a
> great improvement over the PC based systems that followed it.
>

Typesset-8. People liked Typeset-10, too.

/BAH

[Anne & Lynn Wheeler]

jmfbahciv <See....@aol.com> writes:
> You didn't have to have a PDP-10 in the backend but newspapers had
> typeset-10 running on the -10. I suppose some setups may have had
> Typeset-8s in "lcoal" areas which then transferred the end product
> to the -10 for page setup.
>
> The typesetting products for the 10 and 8 were two different
> products. We didn't run Typeset-8 in Marlboro; we did run
> Typeset-10.

in the early 90s worked with atex to port from vax/cluster to ha/cmp
http://www.atex.com/

past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

past posts mentioning atex:
http://www.garlic.com/~lynn/2002m.html#22 DOS history question
http://www.garlic.com/~lynn/2002m.html#23 DOS history question
http://www.garlic.com/~lynn/2002o.html#1 Home mainframes
http://www.garlic.com/~lynn/2007.html#21 DOS C prompt in "Vista"?
http://www.garlic.com/~lynn/2009m.html#57 Ikea type font change
http://www.garlic.com/~lynn/2009m.html#58 Ikea type font change
http://www.garlic.com/~lynn/2009m.html#60 Ikea type font change

--
virtualization experience starting Jan1968, online at home since Mar1970

[Charlie Gibbs]

In article <PM0004E03...@ac810abc.ipt.aol.com>, See....@aol.com

The more things change, the more they stay the same...

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[hanc...@bbs.cpcn.com]

On Thursday, June 27, 2013 9:09:32 AM UTC-4, jmfbahciv wrote:

>Now find a secretary who used it. Ask her how many swear words she invented.

Undoubtedly there was some learning curve. In those years, a person had to be trained to understand the basic differences between using a typewriter and a computer keyboard--there were big differences in set up and 'command' structure. We always had to train new users to hit [enter] when they were finished typing a field or a line, as well as whatever the backspace character was (arrowhead on Teletypes).

Also, machines of that era tended to have very terse commands and responses, so training in the command structure was required, too. But for a reasonably intelligent secretary and a good teacher, this was not a big deal.

>I'm talking about whiz-bangs
>which the coder thought neat and the secretary had to wrestle the
>system to the ground to get what she needed on the piece of paper.

This kind of problem varied greatly by product, and remains a problem to this day in some areas.

But it was by no means certain to happen in products of that time. Plenty of products were well thought out and operated intuivity. They were designed not only by a techie, but also someone who understood the end uer's needs.

I have no idea how well this particular product performed in the marketplace. In 1969 secretarial labor, especially a plain typist, was relatively cheap compared to computer hardware, so a substantial productivity gain was required to justify the purchase. Such a system would of course need a typewriter connected to it, and the quality of that machine affected marketability.

I think for cruder paper-tape based word processing the Friden company had a line of Flexowriters. Around 1970 these could be had with some computing capability, such as adding up the contents of several fields. There were simpler models which were essentially a paper tape offline teletype with u/l case. I've seen them in service in insurance companies in that era.

[Charles Richmond]

"Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
news:mddy59v...@panix5.panix.com...

> John Levine <jo...@iecc.com> writes:
>
>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or PDP-10
>>> then the developers would have had more resources to make it user
>>> friendly. But then it would have cost more.
>
>> Depends more on the developers. There was a newspaper typesetting
>> system based on a PDP-8 that the users all loved. I hear it was a
>> great improvement over the PC based systems that followed it.
>
> Umm, TYPSET-8 was the front end for TYPSET-10, which ran on (wait for it)
> a
> PDP-10. The Chicago Tribune used it, for example; my bridge partner at
> UChicago was the former system manager for the Tribune's setup.
>

Was that David Long???

--

numerist at aquaporin4 dot com

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:1043.962T2...@kltpzyxm.invalid...

> In article <PM0004E03...@ac810abc.ipt.aol.com>, See....@aol.com
> (jmfbahciv) writes:
>
>> Shmuel (Seymour J.) Metz wrote:
>>
>>> In <PM0004E02...@aca22c0e.ipt.aol.com>, on 06/27/2013
>>> at 01:09 PM, jmfbahciv <See....@aol.com> said:
>>>
>>>> Now find a secretary who used it. Ask her how many swear words she
>>>> invented. ;-)
>>>
>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or
>>> PDP-10 then the developers would have had more resources to make
>>> it user friendly. But then it would have cost more.
>>
>> I'm not talking about user-friendly. I'm talking about whiz-bangs
>> which the coder thought neat and the secretary had to wrestle the
>> system to the ground to get what she needed on the piece of paper.
>
> The more things change, the more they stay the same...
>

Charlie, don't you have some COBOL coding to do.. to encorporate the latest
tax changes for next year??? ;-)

[Charlie Gibbs]

[John Savard]

On Wed, 26 Jun 2013 07:58:45 -0700 (PDT), hanc...@bbs.cpcn.com wrote,
in part:

>see also:
>http://technologizer.com/2009/08/21/word-processing-circa-1968/
>
>http://www.ltu.edu/leaders/bio_050509.asp
>
>source:
>http://bitsavers.informatik.uni-stuttgart.de/pdf/computersAndAutomation/196901.pdf

Google led me to
http://www.retrotechnology.com/restore/linc_astrotype.html

John Savard
http://www.quadibloc.com/index.html

[jmfbahciv]

Charlie Gibbs wrote:
> In article <PM0004E03...@ac810abc.ipt.aol.com>, See....@aol.com
> (jmfbahciv) writes:
>
>> Shmuel (Seymour J.) Metz wrote:
>>
>>> In <PM0004E02...@aca22c0e.ipt.aol.com>, on 06/27/2013
>>> at 01:09 PM, jmfbahciv <See....@aol.com> said:
>>>
>>>> Now find a secretary who used it. Ask her how many swear words she
>>>> invented. ;-)
>>>
>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or
>>> PDP-10 then the developers would have had more resources to make
>>> it user friendly. But then it would have cost more.
>>
>> I'm not talking about user-friendly. I'm talking about whiz-bangs
>> which the coder thought neat and the secretary had to wrestle the
>> system to the ground to get what she needed on the piece of paper.
>
> The more things change, the more they stay the same...
>

Yea. Most of the developers we had were pretty reasonable w.r.t.
keeping the user and everyone else who would have to babysit their
machines in mind. We had a couple people who were absolute idiots
w.r.t. not understand how a person uses a system. they didn't
last long.

JMF and CDO were assigned the task of writing a TPS architectural
spec. I spent hours and hours correcting and reminding how
data entry people work. JMF typed with two fingers and CDO
never had to type fast.

One of my extra jobs in Tape Prep was to help with a PDP-8
demo presented to Nabisco for their order entry people.
The TTY was a VT05 and the programmer insisted that the <TAB>
be typed at the end of each number. I finally convinced him
to take a space as the character to advance to the next form
space. It speeded up my data entry by 100% and I wasn't an
expert; their experts would have improved a lot more.
The manager of the product watched one of our practice sessions,
and congratulated the programmer on coming up the idea of
using the space instead of <TAB>. He accepted the praise
as his idea.

Data entry, done well, is an art form.

/BAH

[Charlie Gibbs]

In article <1445.962T2...@kltpzyxm.invalid>,

cgi...@kltpzyxm.invalid (Charlie Gibbs) writes:

> In article <kqkkfc$28b$1...@dont-email.me>, nume...@aquaporin4.com
> (Charles Richmond) writes:

>> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
>> news:1043.962T2...@kltpzyxm.invalid...
>>
>>> In article <PM0004E03...@ac810abc.ipt.aol.com>,
>>> See....@aol.com (jmfbahciv) writes:
>>>
>>>> Shmuel (Seymour J.) Metz wrote:
>>>>
>>>>> In <PM0004E02...@aca22c0e.ipt.aol.com>, on 06/27/2013
>>>>> at 01:09 PM, jmfbahciv <See....@aol.com> said:
>>>>>
>>>>>> Now find a secretary who used it. Ask her how many swear words
>>>>>> she invented. ;-)
>>>>>
>>>>> Well, it ran on a PDP-8; had Astrotype been done for a PDP-6 or
>>>>> PDP-10 then the developers would have had more resources to make
>>>>> it user friendly. But then it would have cost more.
>>>>
>>>> I'm not talking about user-friendly. I'm talking about whiz-bangs
>>>> which the coder thought neat and the secretary had to wrestle the
>>>> system to the ground to get what she needed on the piece of paper.
>>>
>>> The more things change, the more they stay the same...
>>
>> Charlie, don't you have some COBOL coding to do.. to encorporate
>> the latest tax changes for next year??? ;-)

[And I thought the line eater was dead...]

Nah, I got out of payroll. As we speak I'm tracking down a case
of GIGO at a customer's site, and trying to determine whether it
was a bug of mine or a corruption of the file system. (My money's
on the file system - that version of my software has been running
flawlessly there for two years, the problem appeared suddenly in
both input and output files, and disappeared when they rebooted
the machine. Bloody Windows...)

Once I get that one put to bed, it's back to my current projects:
adding whiz-bangs which potential customers think are neat enough
to bring them on board. (Mind you, as the coder, I think they're
pretty neat too...)

[hanc...@bbs.cpcn.com]

On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:

> Data entry, done well, is an art form. /BAH

Sometimes it's as simple as sitting down with the data entry people and discussing the plans for the application--what data will be needed, what their recommendations are for a source document, and what their keydata machines can edit and reformat.

It's amazing--and sad--that so few analysts bothered to do that in the old days, or even check with today's terminal users.

[jmfbahciv]

hanc...@bbs.cpcn.com wrote:
> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:
>
>> Data entry, done well, is an art form. /BAH
>
> Sometimes it's as simple as sitting down with the data entry people and
discussing the plans for the application--what data will be needed, what their
recommendations are for a source document, and what their keydata machines can
edit and reformat.

A lot of times, talking isn't the important thing. Watching how they work
is. For instance, my example of Nabisco caused the data enterer to remove
the fingers from the keypad and use the pinkie finger. It's faster to be
able to use the thumb. How the data pages are set up and used is important
too.

>
> It's amazing--and sad--that so few analysts bothered to do that in the old
days, or even check with today's terminal users.

It's called arrogance. The "expert" in expert systems, a precursor to AI,
is the person who does the data entry or whatever, not the programmer.
Some programmers do not have enough humility to be able to objectively
design a hard/software system for the customer. It's the customer who
is the expert of what the system is going to be for, not the architect
nor the designers nor the implementers.

this is the lesson which had to be learned by every OS developer in
our shop if they aspired to become a bit god to their peers. Not many
figured this one out.

/BAH

[Dan Espen]

jmfbahciv <See....@aol.com> writes:

> hanc...@bbs.cpcn.com wrote:
>> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:
>>
>>> Data entry, done well, is an art form. /BAH
>>
>> Sometimes it's as simple as sitting down with the data entry people and
> discussing the plans for the application--what data will be needed, what their
> recommendations are for a source document, and what their keydata machines can
> edit and reformat.
>
> A lot of times, talking isn't the important thing. Watching how they work
> is. For instance, my example of Nabisco caused the data enterer to remove
> the fingers from the keypad and use the pinkie finger. It's faster to be
> able to use the thumb. How the data pages are set up and used is important
> too.
>>
>> It's amazing--and sad--that so few analysts bothered to do that in the old
> days, or even check with today's terminal users.
>
> It's called arrogance. The "expert" in expert systems, a precursor to AI,
> is the person who does the data entry or whatever, not the programmer.
> Some programmers do not have enough humility to be able to objectively
> design a hard/software system for the customer. It's the customer who
> is the expert of what the system is going to be for, not the architect
> nor the designers nor the implementers.

Wow, reliable like Old Faithful.

> this is the lesson which had to be learned by every OS developer in
> our shop if they aspired to become a bit god to their peers. Not many
> figured this one out.

I can't even parse this paragraph, and yet I disagree with it no matter
how it parses.

Just about every analyst in the field (including programmer analysts)
knows how to design a data entry process. If they don't, they're going
to hear about it and learn.

I think you're the one that's arrogant.

--
Dan Espen

[Patrick Scheible]

jmfbahciv <See....@aol.com> writes:

> hanc...@bbs.cpcn.com wrote:
>> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:
>>
>>> Data entry, done well, is an art form. /BAH
>>
>> Sometimes it's as simple as sitting down with the data entry people and
> discussing the plans for the application--what data will be needed, what their
> recommendations are for a source document, and what their keydata machines can
> edit and reformat.
>
> A lot of times, talking isn't the important thing. Watching how they work
> is. For instance, my example of Nabisco caused the data enterer to remove
> the fingers from the keypad and use the pinkie finger. It's faster to be
> able to use the thumb. How the data pages are set up and used is important
> too.

Yes... I am depressed about the design of our library's new online
circulation system from the usability standpoint. The most routine
tasks require more shuffling with the mouse than should be required, for
instance checking in books: some situations cause a popup box which
can't be dismissed except with the mouse. It's so much slower to switch
hands to the mouse, move the cursor to the "ok" button, and click, than
it would be to reach for the spacebar. The mouse can only be controlled
by the right hand without rearranging the workspace, but the spacebar
can be reached with any finger of either hand.

The most efficient library system we've used was the one we had from
about 1992 to 2002. Generations since are all GUIs and mouses and
subtle bugs and slowing down processes that should be fast.

-- Patrick

[Dave Garland]

On 6/30/2013 10:09 AM, Dan Espen wrote:

> Just about every analyst in the field (including programmer
> analysts) knows how to design a data entry process. If they
> don't, they're going to hear about it and learn.

They may know how to design a data entry process, but they are often
surprisingly bad at doing so in a way that users like. Or is that
"surprisingly often bad"? Hard to decide. Both, I think.

And especially with stuff developed in the "aulden days" when Barb
was at DEC. Back then, the excuse was usually "the computer needs
it that way".

It's sort of like, every programmer thinks they can write
instructions. After all, they know how to do the task, right?
Maybe, but that doesn't mean they can write instructions worth
squat. (In another field) the company I worked for employed a
professional editor to translate what the pros wrote into something
that other people could understand without ambiguity. IMHO it was
money well spent.

[Dan Espen]

Dave Garland <dave.g...@wizinfo.com> writes:

> On 6/30/2013 10:09 AM, Dan Espen wrote:
>
>> Just about every analyst in the field (including programmer
>> analysts) knows how to design a data entry process. If they
>> don't, they're going to hear about it and learn.
>
> They may know how to design a data entry process, but they are often
> surprisingly bad at doing so in a way that users like. Or is that
> "surprisingly often bad"? Hard to decide. Both, I think.
>
> And especially with stuff developed in the "aulden days" when Barb
> was at DEC. Back then, the excuse was usually "the computer needs
> it that way".

I started in the field in 1964.
I remember lots of articles about well designed data entry
and lots of review of input forms with users.

From my small porthole into the process, it seemed like we were
aware of the issues and addressed them.

> It's sort of like, every programmer thinks they can write
> instructions. After all, they know how to do the task, right?
> Maybe, but that doesn't mean they can write instructions worth
> squat. (In another field) the company I worked for employed a
> professional editor to translate what the pros wrote into something
> that other people could understand without ambiguity. IMHO it was
> money well spent.

I've seen a few projects with tech writers.

Sometimes they were okay.

I had one group that refused to make the changes I specified.
I had them thrown off the project.

They couldn't understand how a re-write of a process turned a
one inch manual into a pamphlet.

--
Dan Espen

[jmfbahciv]

How ugly. I talked with a clerk at OfficeMax Saturday. She couldn't
believe that I would be able to do 10x-20x more things by typing.
Programmers today haven't had exposure to more efficient methods we
were used to when playing with TTYs. There isn't any way they're going
to implement facile user interfaces.

>
> The most efficient library system we've used was the one we had from
> about 1992 to 2002. Generations since are all GUIs and mouses and
> subtle bugs and slowing down processes that should be fast.

Too bad you don't have access to the programmer's back door....
or watering hole.

/BAH

[Shmuel Metz]

In <86li5q3...@chai.my.domain>, on 06/30/2013

at 09:47 PM, Patrick Scheible <k...@zipcon.net> said:

>Yes... I am depressed about the design of our library's new online
>circulation system from the usability standpoint.

But a web interface is so much sexier than a user friendly interface
that actually works.

>The most efficient library system we've used was the one we had from
>about 1992 to 2002. Generations since are all GUIs and mouses

The FCPL had a perfectly usable GUI interface to the catalog until
they decided to replace it with a web interface. GUI doesn't have to
be poorly designed, although it admittedly often is.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <kqr4u0$bre$1...@dont-email.me>, on 07/01/2013

at 12:48 AM, Dave Garland <dave.g...@wizinfo.com> said:

>And especially with stuff developed in the "aulden days" when Barb
>was at DEC. Back then, the excuse was usually "the computer needs it
>that way".

Was that back when companies would blame incorrect bills on computer
errors even when they weren't using computers to process the bills?
Google for "bedbug letter".

>(In another field) the company I worked for employed a
>professional editor to translate what the pros wrote into something
>that other people could understand without ambiguity. IMHO it was
>money well spent.

BTDT, GTS. Sturgeon's Law well and truly applies to tech writers. A
good one is a treasure, but the typical tech writer simplifies your
prose to something that clearly describes a product different from the
one that you're actually developing and documenting. Sort of like the
printer that insisted on rewrapping sample JCL in a news letter.

[Dave Garland]

On 7/1/2013 8:50 AM, Shmuel (Seymour J.) Metz wrote:

> BTDT, GTS. Sturgeon's Law well and truly applies to tech writers.
> A good one is a treasure, but the typical tech writer simplifies
> your prose to something that clearly describes a product
> different from the one that you're actually developing and
> documenting.

That certainly can happen. It is important to keep in mind that
tech writers/editors are not interchangeable, that they should know
the particular field well. And the writing is, or should be, an
interactive affair. (It does help if the group is small, and their
office is two doors down the hall from the author.)

But if the tech writer could not grasp the essence of what you were
saying from your prose (even if they can ask you questions), that
clearly suggests that _somebody_ needs to be working on the written
material.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004E07...@ac810653.ipt.aol.com...

That’s just plain wrong with cellphone texting alone.

> There isn't any way they're going
> to implement facile user interfaces.

It happens anyway, most obviously with linux.

>> The most efficient library system we've used was the one we had from
>> about 1992 to 2002. Generations since are all GUIs and mouses and
>> subtle bugs and slowing down processes that should be fast.

> Too bad you don't have access to the programmer's back door....
> or watering hole.

There are still plenty of well implemented systems.

[Rich Alderson]

"Charles Richmond" <nume...@aquaporin4.com> writes:

> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
> news:mddy59v...@panix5.panix.com...

>> Umm, TYPSET-8 was the front end for TYPSET-10, which ran on (wait for it)
>> a PDP-10. The Chicago Tribune used it, for example; my bridge partner at
>> UChicago was the former system manager for the Tribune's setup.

> Was that David Long???

David Long was a computer operator at the UChicago Graduate School of Business
computer facility. I knew him casually; he gave me a copy of the parser from
Adventure because I'm a linguist, but wouldn't give up the rest of the source.

My bridge partner Jim Krema was manager of internal audit for the Comptroller's
Office, later manager of the ISDEV group at the UofC Comp Center. I remember
him saying to me, "I want you to forget you ever heard the word 'redouble'!"

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

[jmfbahciv]

Dan Espen wrote:
> Dave Garland <dave.g...@wizinfo.com> writes:
>
>> On 6/30/2013 10:09 AM, Dan Espen wrote:
>>
>>> Just about every analyst in the field (including programmer
>>> analysts) knows how to design a data entry process. If they
>>> don't, they're going to hear about it and learn.
>>
>> They may know how to design a data entry process, but they are often
>> surprisingly bad at doing so in a way that users like. Or is that
>> "surprisingly often bad"? Hard to decide. Both, I think.
>>
>> And especially with stuff developed in the "aulden days" when Barb
>> was at DEC. Back then, the excuse was usually "the computer needs
>> it that way".
>
> I started in the field in 1964.
> I remember lots of articles about well designed data entry
> and lots of review of input forms with users.

Designing forms is just a part of the project. Taking a good look
at how the data enterers work is also very important. If the form
is 8x11 and the place for the enterer's pile is 3x4, there is going
to be a problem. If a group is all left-handed, there may be adjustments
to the keyboard layout. I would enter data with my right hand and flip
the papers with the hen scratches with my left. At times, I needed
to set up another surface when the forms were too large for the table
provided. Even in my office when I was a developer, I would have the
TTY set up so that the listings could be on my desk and available to
my left hand.

If you set down with someone who does the work and allow them to chat,
you can tell which areas need improvements even if it's not in the
spec. Everyone always has their own ideas about "wouldn't it be
nice if the code could do ....". Those are important. If the group
is greater than 5, you can figure out a general solution which can
make them all happy and improve their page count.


<snip>

/BAH

[jmfbahciv]

It was the responsibility of the developers to make sure the tech
info was correct down to the last bit in our shop. If a poorly
written doc every got out, it was our fault, not the writer's.
It was also the writer's responsibility to ensure that thier
writings were reviewed by at least 3 developers.

With so much work, most coders had a pile of stuff to review
teetering off their credenza. The solution to this problem
was to "assign" primary review responsibility of a manual
to one developer. It was his/her job to make sure it was
correct. If the manual "owner" didn't know some of the
material, s/he would find the developer who did and make
sure that part was reveiwed by the real expert.

/BAH

[jmfbahciv]

You are equating cell phone texting with getting real work done
on a data base?

>
>> There isn't any way they're going
>> to implement facile user interfaces.
>
> It happens anyway, most obviously with linux.

The GUIs? If you're talkinga bout monitor mode, there is still
no documentation which will help people other than Unix weenies.

>
>>> The most efficient library system we've used was the one we had from
>>> about 1992 to 2002. Generations since are all GUIs and mouses and
>>> subtle bugs and slowing down processes that should be fast.
>
>> Too bad you don't have access to the programmer's back door....
>> or watering hole.
>
> There are still plenty of well implemented systems.

Since you use the plural....name three.

/BAH

>

[Charlie Gibbs]

In article <fa6747ea-f424-43ae...@googlegroups.com>,

hanc...@bbs.cpcn.com (hancock4) writes:

> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:
>
>> Data entry, done well, is an art form. /BAH
>
> Sometimes it's as simple as sitting down with the data entry people
> and discussing the plans for the application--what data will be
> needed, what their recommendations are for a source document, and
> what their keydata machines can edit and reformat.

I learned this the hard way - my first design almost got me lynched.

> It's amazing--and sad--that so few analysts bothered to do that
> in the old days, or even check with today's terminal users.

But the screens today are so _pretty_!

[Charlie Gibbs]

In article <51d187c5$9$fuzhry+tra$mr2...@news.patriot.net>,

spam...@library.lspace.org.invalid (Seymour J.) writes:

> In <86li5q3...@chai.my.domain>, on 06/30/2013
> at 09:47 PM, Patrick Scheible <k...@zipcon.net> said:
>
>> Yes... I am depressed about the design of our library's new online
>> circulation system from the usability standpoint.
>
> But a web interface is so much sexier than a user friendly interface
> that actually works.

Sad but true. It's designed to impress the managers to do the buying,
rather than the grunts who have to actually work with it. :-(

>> The most efficient library system we've used was the one we had from
>> about 1992 to 2002. Generations since are all GUIs and mouses
>
> The FCPL had a perfectly usable GUI interface to the catalog until
> they decided to replace it with a web interface. GUI doesn't have to
> be poorly designed, although it admittedly often is.

A well-designed GUI will have keyboard equivalents so that skilled
touch typists don't have to move their hands from the home row.
I say "skilled" because even if such options exist, many users
insist on reaching for the mouse to do things like go to the next
field (instead of pressing <tab>) or clicking the "OK" button
(instead of pressing <enter>). These people are their own worst
enemies - and if they influence developers to remove keyboard
shortcuts then they're my enemies too.

[Michael Black]

That happens with web pages too.

I remember when I got full internet access in August of 1996, I spent some
time looking over the webpages of non-profit groups. They had no purpose
except "get on the internet", they were like markers and a phone book
would have been more useful. The groups were sold the internet, and then
some volunteer made them a webpage. But the groups didn't know the
internet, so they could't say anything, the third party volunteer didn't
know the group, so they couldn't lead the group, so you had a webpage that
had no real value, made no real use of the internet.

And that's the foundation of so much almost 20 years later. The webpages
get glossier, so they are even harder to make in house. I've seen groups
send out email with webpages in the email, rather than actually use their
webpage properly. And since the foundation isn't there, it's easy to put
a twitter feed on a webpage, rather than make sure the webpage has a place
for "hot news" and the group can easily toss things up there as needed.

Some of the facebook trend is simply people thinking "making webpages is
too technical" or "usenet is too technical" so they go with something
that's really easy, rather than spend a few minutes learning that a simple
webpage is really easy. I've posted about local used book sales since
1997, first to the local newsgroup, then eventually to a webpage since we
were't gaining people to the local newsgroup. One book sale a few years
ago announced "we have a facebook page, and suddenly we had better sales".
But, I remember the first time I knew they had a sale, I saw a poster, the
day after the sale. ANd things havent' improved much. They weren't in
the newspaper listings (before those disappeared), they didn't post to the
local newsgroup, they don't use craigslist. If I want the date, I have to
go by that library and hope there's a poster up. So no wonder a facebook
page seems like magic, because it's a vast improvement over what they were
doing before. Yet too often facebook doesn't appear in searches, so it's
all about an expectation that everyone does facebook. The ironic part is
that the use of facebook often causes that near universal use, because
the groups go to facebook rather than webpages. I can see the value of a
facebook page in parallel with a real webpage, but since the rush to the
internet didn't include much thought about how to use it, the groups think
"if it's on facebook, that's good enough".

Michael

[Ibmekon]

The public internet now resembles a highway with end to end
advertising hoardings on both sides. Nearly all the signs for turnoffs
to local roads are also sponsored.

My old TV is a Mitsubishi 26 inch CRT - and it is showing signs of
impending failure.
Recently I saw an ad for a flat screen TV in a local paper by a local
retailer, Sean Hennessy.

So I checked the shops website - and got a decent look at the TV and
also tech specs. The shortcoming of a flat screen TV is the sound
quality - unless you buy a separate sound bar or speaker set.

So I decided to search for some evaluation of the audio performance of
the 39 inch Hannspree.
After a half hour all I found was the same details repeated ad
infinitum - and paid for reviews written by people who had never seen
the product.

It seems to me that the hoardings company Google has made the internet
a highway you just want to leave behind you.

Must drive to the shop tomorrow and have a listen.

Carl Goldsworthy

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E08...@aca28718.ipt.aol.com...

No, its clearly doing pure text entry with no mouse involved at all
and in fact going further with abbreviations than is feasible with
TTYs etc because there is a human reading it at the other end.

>>> There isn't any way they're going
>>> to implement facile user interfaces.

>> It happens anyway, most obviously with linux.

> The GUIs?

Nope, the CLIs.

> If you're talkinga bout monitor mode, there is still no
> documentation which will help people other than Unix weenies.

Bullshit. There has been more than man pages for a long time now.

>>>> The most efficient library system we've used was the one we had from
>>>> about 1992 to 2002. Generations since are all GUIs and mouses and
>>>> subtle bugs and slowing down processes that should be fast.

>>> Too bad you don't have access to the programmer's back door....
>>> or watering hole.

>> There are still plenty of well implemented systems.

> Since you use the plural....name three.

iOS, Linux, Win7.

iOS doesn’t even have a mouse at all.

[Bernd Felsche]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>hanc...@bbs.cpcn.com (hancock4) writes:
>> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:

>>> Data entry, done well, is an art form. /BAH

>> Sometimes it's as simple as sitting down with the data entry people
>> and discussing the plans for the application--what data will be
>> needed, what their recommendations are for a source document, and
>> what their keydata machines can edit and reformat.

>I learned this the hard way - my first design almost got me lynched.

>> It's amazing--and sad--that so few analysts bothered to do that
>> in the old days, or even check with today's terminal users.

>But the screens today are so _pretty_!

Mollasses is sweet, but you don't want to wade through it to get
your job done.
--
/"\ Bernd Felsche - Somewhere in Western Australia
\ / ASCII ribbon campaign | For every complex problem there is an
X against HTML mail | answer that is clear, simple, and wrong.
/ \ and postings | --HL Mencken

[Shmuel Metz]

In <1654.966T2...@kltpzyxm.invalid>, on 07/02/2013

at 08:20 AM, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> said:

>A well-designed GUI will have keyboard equivalents so that skilled
>touch typists don't have to move their hands from the home row.

I would not consider it well designed unless it was easily scriptable.

[jmfbahciv]

Rod Speed wrote:
>
>
> "jmfbahciv" <See....@aol.com> wrote in message

> news:PM0004E08...@aca28718.ipt.aol.com...

<snip>

>> If you're talkinga bout monitor mode, there is still no
>> documentation which will help people other than Unix weenies.
>
> Bullshit. There has been more than man pages for a long time now.

I worked at DEC. We were ksnown for excellent documentation. I know
bad docs when I see them. I also know how to recognize docs which
were written for experts even if the title has the word "dummy" in it.

There are no comprhensive docs about Unix systems and how to run them.
Unix was never exposed to the scrutiny of the full range of "users"
for the same publications. There weren't any SPRs on those docs and
nobody had to fix misunderstandings or, especially this one, absence
of documentation. There is not an operator's manual. There is not
a system administrator's manual. There are oodles of "dumb users'"
manuals but they only cover the interfaces from the p.o.v. of the author,
not from the p.o.v. of the reader.

It is clear that those who reviewed those docs already knew more than
the average unix weeny.

/BAH

[Charlie Gibbs]

In article <ollcaax...@innovative.iinet.net.au>,

ber...@innovative.iinet.net.au (Bernd Felsche) writes:

> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> hanc...@bbs.cpcn.com (hancock4) writes:
>>
>>> On Saturday, June 29, 2013 8:34:52 AM UTC-4, jmfbahciv wrote:
>>>
>>>> Data entry, done well, is an art form. /BAH
>>>
>>> Sometimes it's as simple as sitting down with the data entry people
>>> and discussing the plans for the application--what data will be
>>> needed, what their recommendations are for a source document, and
>>> what their keydata machines can edit and reformat.
>>
>> I learned this the hard way - my first design almost got me lynched.
>>
>>> It's amazing--and sad--that so few analysts bothered to do that
>>> in the old days, or even check with today's terminal users.
>>
>> But the screens today are so _pretty_!
>
> Mollasses is sweet, but you don't want to wade through it to get
> your job done.

I don't - but I can just hear the office twinkie looking up from her
smart phone and saying, "Oh, like, that's just soooo last week!"

[Patrick Scheible]

There are docs, not as good as the ones for DEC back in the day but when
you're selling a $100,000 worth of product it's easy to include a few
thousand $ worth of technical writer's time. When it's a $500 PC, not
so much. There are also a lot of resources now that weren't available
in the 1970s.

-- Patrick

[Anne & Lynn Wheeler]

Patrick Scheible <k...@zipcon.net> writes:
> There are docs, not as good as the ones for DEC back in the day but when
> you're selling a $100,000 worth of product it's easy to include a few
> thousand $ worth of technical writer's time. When it's a $500 PC, not
> so much. There are also a lot of resources now that weren't available
> in the 1970s.

csay @$50 on 200,000 $500 PCs is same as $10,000 on 1,000 $100,000
machines ... one could claim that good documentation is more important
when it is 200,000 customers ... might actually be closer to 2,000,000
machines.

--
virtualization experience starting Jan1968, online at home since Mar1970

[Charles Richmond]

"Dave Garland" <dave.g...@wizinfo.com> wrote in message
news:kqr4u0$bre$1...@dont-email.me...
>
> [snip...] [snip...]
> [snip...]

>
> It's sort of like, every programmer thinks they can write
> instructions. After all, they know how to do the task, right?
> Maybe, but that doesn't mean they can write instructions worth
> squat. (In another field) the company I worked for employed a
> professional editor to translate what the pros wrote into something
> that other people could understand without ambiguity. IMHO it was
> money well spent.
>

In the book _Zen and the Art of Motorcycle Maintenance_, the author had once
been a tech writer. He pointed out that when he had a job to (for example)
write an instruction manual for assembling a barbaque unit, he'd go where
the units were being manufactured to find out how the assembling worked.
When he got there, the foreman would send over Joe Schmoe, the guy who
hardly ever did anything and was least useful, to tell the tech writer how
to assemble the unit.

Consequently, the assembly manual would turn out badly... because the Joe
Schmoe did *not* know what he was talking about and cared even less.

--

numerist at aquaporin4 dot com

[Charles Richmond]

"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
news:m3obajy...@garlic.com...

>
> Patrick Scheible <k...@zipcon.net> writes:
>> There are docs, not as good as the ones for DEC back in the day but when
>> you're selling a $100,000 worth of product it's easy to include a few
>> thousand $ worth of technical writer's time. When it's a $500 PC, not
>> so much. There are also a lot of resources now that weren't available
>> in the 1970s.
>
> csay @$50 on 200,000 $500 PCs is same as $10,000 on 1,000 $100,000
> machines ... one could claim that good documentation is more important
> when it is 200,000 customers ... might actually be closer to 2,000,000
> machines.
>

But out of the 200,000 PC owners, the vast majority are "computer
illiterate". Even the DEC manuals were useless to people who do *not*
understand the first thing about how a computer works.

[Charles Richmond]

"Rich Alderson" <ne...@alderson.users.panix.com> wrote in message

news:mdda9m5...@panix5.panix.com...

> "Charles Richmond" <nume...@aquaporin4.com> writes:
>
>> "Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
>> news:mddy59v...@panix5.panix.com...
>
>>> Umm, TYPSET-8 was the front end for TYPSET-10, which ran on (wait for
>>> it)
>>> a PDP-10. The Chicago Tribune used it, for example; my bridge partner
>>> at
>>> UChicago was the former system manager for the Tribune's setup.
>
>> Was that David Long???
>
> David Long was a computer operator at the UChicago Graduate School of
> Business
> computer facility. I knew him casually; he gave me a copy of the parser
> from
> Adventure because I'm a linguist, but wouldn't give up the rest of the
> source.
>
> My bridge partner Jim Krema was manager of internal audit for the
> Comptroller's
> Office, later manager of the ISDEV group at the UofC Comp Center. I
> remember
> him saying to me, "I want you to forget you ever heard the word
> 'redouble'!"
>

It sounds like Mr. Krema was *not* entirely happy with your bidding strategy
in bridge... ;-)

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:969.966T21...@kltpzyxm.invalid...

> In article <fa6747ea-f424-43ae...@googlegroups.com>,
> hanc...@bbs.cpcn.com (hancock4) writes:
>

> [snip...] [snip...]
> [snip...]

>
>> It's amazing--and sad--that so few analysts bothered to do that
>> in the old days, or even check with today's terminal users.
>
> But the screens today are so _pretty_!
>

It may seem funny, but I *liked* the old green-screen terminals... the ones
that had green characters on a dark background. I *never* really cared for
the look of the amber characters... it's green for me!!! I thought those
displays were very pretty!

[Rod Speed]

jmfbahciv <See....@aol.com> wrote

> Rod Speed wrote
>> jmfbahciv <See....@aol.com> wrote

>>> If you're talkinga bout monitor mode, there is still no
>>> documentation which will help people other than Unix weenies.

>> Bullshit. There has been more than man pages for a long time now.

> I worked at DEC. We were ksnown for excellent documentation.

And then the real world moved on just like it always does and that
was a lot more than just what the manufacturer chose to provide.

> I know bad docs when I see them. I also know how to recognize docs
> which were written for experts even if the title has the word "dummy" in
> it.

You've now slithered off to something entirely different to your original.

The bulk of what DEC produced documentation wise was aimed at weenies too.

> There are no comprhensive docs about Unix systems and how to run them.

Bullshit.

> Unix was never exposed to the scrutiny of the full range of "users"
> for the same publications.

Even sillier.

> There weren't any SPRs on those docs

Irrelevant to your original stupid claim.

> and nobody had to fix misunderstandings or,
> especially this one, absence of documentation.

But that happened anyway.

> There is not an operator's manual.

The world moved on on that with personal computers.

> There is not a system administrator's manual.

The world moved on on that with personal computers.

> There are oodles of "dumb users'" manuals

So your original is just plain wrong.

> but they only cover the interfaces from the p.o.v.
> of the author, not from the p.o.v. of the reader.

Even sillier.

> It is clear that those who reviewed those docs
> already knew more than the average unix weeny.

Even sillier.

[jklam]

"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
news:m3obajy...@garlic.com...
>

> Patrick Scheible <k...@zipcon.net> writes:
>> There are docs, not as good as the ones for DEC back in the day but when
>> you're selling a $100,000 worth of product it's easy to include a few
>> thousand $ worth of technical writer's time. When it's a $500 PC, not
>> so much. There are also a lot of resources now that weren't available
>> in the 1970s.
>
> csay @$50 on 200,000 $500 PCs is same as $10,000 on 1,000 $100,000
> machines ... one could claim that good documentation is more important
> when it is 200,000 customers ... might actually be closer to 2,000,000
> machines.

DEC's documentation for stuff like the Rainbow as nothing special.

[Patrick Scheible]

The DEC manuals started with pretty basic stuff. This is the control
key....

-- Patrick

[jmfbahciv]

Those people used the commands manual.

/BAH

[jmfbahciv]

I spent many, many days working with a writer doing the actual work
which she had written about. Even managed to find monitor bugs.

/BAH

[jmfbahciv]

It was a lot more than a few K.

> When it's a $500 PC, not
> so much. There are also a lot of resources now that weren't available
> in the 1970s.

the $500 PC is the hardware, not the OS. The problem with today's biz
is that there is no feedback mechanism to improve one manual. No SPRs
and no incentive to answer them nor get the material corrected. The
authors get their royalties even if there are a thousand bugs in the
manual and 10,000 typos.

I remember our PDP-10 writers spent 4 years and two major monitor
releases and IIRC three iterations to figure out which was THE
best way to describe how to type <CTRL>C and how to signify the
character on paper.

/BAH

[jmfbahciv]

Rod Speed wrote:
> jmfbahciv <See....@aol.com> wrote
>> Rod Speed wrote
>>> jmfbahciv <See....@aol.com> wrote
>
>>>> If you're talkinga bout monitor mode, there is still no
>>>> documentation which will help people other than Unix weenies.
>
>>> Bullshit. There has been more than man pages for a long time now.
>
>> I worked at DEC. We were ksnown for excellent documentation.
>
> And then the real world moved on just like it always does and that
> was a lot more than just what the manufacturer chose to provide.
>
>> I know bad docs when I see them. I also know how to recognize docs
>> which were written for experts even if the title has the word "dummy" in
>> it.
>
> You've now slithered off to something entirely different to your original.

No, I have not.

>
> The bulk of what DEC produced documentation wise was aimed at weenies too.

It was aimed at the person who would need help which included systems
analysts, hardware types, operators, programmers, typists, and any other
job which required exposure to the machine.

>
>> There are no comprhensive docs about Unix systems and how to run them.
>
> Bullshit.

OK. Which one? I'm not even asking for two.

>
>> Unix was never exposed to the scrutiny of the full range of "users"
>> for the same publications.
>
> Even sillier.
>
>> There weren't any SPRs on those docs
>
> Irrelevant to your original stupid claim.

It is completely relavant.

>
>> and nobody had to fix misunderstandings or,
>> especially this one, absence of documentation.
>
> But that happened anyway.
>
>> There is not an operator's manual.
>
> The world moved on on that with personal computers.

IMO it has regressed. Now the "dummies" are computer
_owners_ and they have even less documentation to help
them when they need it. Previously, people were trained
to do specific jobs which the PC owner now automagically
has to know.

>
>> There is not a system administrator's manual.
>
> The world moved on on that with personal computers.

And each system owner needs that info.

>
>> There are oodles of "dumb users'" manuals
>
> So your original is just plain wrong.

No. Those docs contain very little help.

>
>> but they only cover the interfaces from the p.o.v.
>> of the author, not from the p.o.v. of the reader.
>
> Even sillier.
>
>> It is clear that those who reviewed those docs
>> already knew more than the average unix weeny.
>
> Even sillier.
>
>

And you show your silliness by claiming that system
owners don't need to know about every aspect of their
system.

/BAH

[Peter Flass]

On 7/4/2013 9:22 AM, jmfbahciv wrote:
> Rod Speed wrote:
>> jmfbahciv <See....@aol.com> wrote
>>> Rod Speed wrote
>>>> jmfbahciv <See....@aol.com> wrote
>>
>>>>> If you're talkinga bout monitor mode, there is still no
>>>>> documentation which will help people other than Unix weenies.
>>
>>>> Bullshit. There has been more than man pages for a long time now.
>>

Don't feed the trolls.

--
Pete

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E0A...@aca254e6.ipt.aol.com...

Hordes of them ever did. They just got someone else to show them
how to do what they wanted to do. And still operate like that today
even when there is quite decent documentation available for most stuff.

[Rod Speed]

jmfbahciv <See....@aol.com> wrote
> Rod Speed wrote
>> jmfbahciv <See....@aol.com> wrote
>>> Rod Speed wrote
>>>> jmfbahciv <See....@aol.com> wrote

>>>>> If you're talkinga bout monitor mode, there is still no
>>>>> documentation which will help people other than Unix weenies.

>>>> Bullshit. There has been more than man pages for a long time now.

>>> I worked at DEC. We were ksnown for excellent documentation.

>> And then the real world moved on just like it always does and that
>> was a lot more than just what the manufacturer chose to provide.

>>> I know bad docs when I see them. I also know how to recognize docs
>>> which
>>> were written for experts even if the title has the word "dummy" in it.

>> You've now slithered off to something entirely different to your
>> original.

> No, I have not.

Corse you have. There are plenty of other than Unix weenies
that use the Dummy books alone quite effectively.

And not just with their PC either, with their cellphone etc too.

We've just had the analog TV turned off forever here and
the digital TV channels rearranged to use some of the freed
up UHF channel space and all the VHF channel space freed
up and most have managed to use the documentation that
comes with their TV to scan for channel changes.

I've had to do that for one of my neighbours who just gives
up too easily, but his wife who he has just divorced managed
to do it fine by herself. And the woman who he appears to be
about to change over to did too.

>> The bulk of what DEC produced documentation wise was aimed at weenies
>> too.

> It was aimed at the person who would need help which included
> systems analysts, hardware types, operators, programmers, typists,
> and any other job which required exposure to the machine.

That’s just plain wrong with the PC products like the Rainbow.

And I still have the documentation, so don’t try telling me whats in there.

>>> There are no comprhensive docs about
>>> Unix systems and how to run them.

>> Bullshit.

> OK. Which one? I'm not even asking for two.

There are plenty for the most common Linux distros like Ubuntu.

>>> Unix was never exposed to the scrutiny of the
>>> full range of "users" for the same publications.

>> Even sillier.

>>> There weren't any SPRs on those docs

>> Irrelevant to your original stupid claim.

> It is completely relavant.

Like hell it is. You don’t need to have SPRs to provide
useful documentation for other than Unix weenies.

>>> and nobody had to fix misunderstandings or,
>>> especially this one, absence of documentation.

>> But that happened anyway.

>>> There is not an operator's manual.

>> The world moved on on that with personal computers.

> IMO it has regressed.

Whatever you think about that, even DEC did that with the Rainbow.

> Now the "dummies" are computer _owners_ and they have
> even less documentation to help them when they need it.

Bullshit with the Dummies books alone. That leaves
what DEC provided for the Rainbow for dead.

> Previously, people were trained to do specific jobs
> which the PC owner now automagically has to know.

Even sillier. There is plenty of training available right now for PCs.

And that’s not the documentation you were
pig ignorantly talking about anyway.

>>> There is not a system administrator's manual.

>> The world moved on on that with personal computers.

> And each system owner needs that info.

Bullshit. They just get someone who knows how
to do it to do it for them now. The world's moved
on, just like it always does with technology.

>>> There are oodles of "dumb users'" manuals

>> So your original is just plain wrong.

> No. Those docs contain very little help.

Bullshit. You are just doing you usual, if it isnt
done the way DEC used to do it, you proclaim
that it contains very little help.

>>> but they only cover the interfaces from the p.o.v.
>>> of the author, not from the p.o.v. of the reader.

>> Even sillier.

>>> It is clear that those who reviewed those docs
>>> already knew more than the average unix weeny.

>> Even sillier.

> And you show your silliness by claiming that system owners
> don't need to know about every aspect of their system.

Corse they don’t when they can get someone
who does to do the most difficult stuff.

That’s always been the case even with DEC hardware.

While say the Rainbow documentation did tell you how
to add a hard drive to a Rainbow that did not have a
hard drive, very few Rainbow owners ever tried to do
that sort of thing themselves, they got someone like
me to do it for them.

Apple doesn’t even bother to tell you how to change
the battery in your iphone or ipad, and deliberately
makes it hard for you to do that yourself, but there
is a wealth of much better documentation on how
to do that if you want to do yourself than DEC
ever provided for the Rainbow or even the PDP8,
essentially because there is so much youtube video
that leaves printed manuals for dead on stuff like that.

And with stuff like backups, what documentation
do you need more than a page that tell you to plug
the external hard drive into your PC with a USB
cable and press the red backup button on the drive ?

Even you should be able to manage that.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E0A...@aca254e6.ipt.aol.com...

Bullshit. It’s the web, stupid.

> No SPRs

Because the real world has moved on and those of
us with even half a clue use the web to do that now.

> and no incentive to answer them

Plenty of the majors do that anyway.

> nor get the material corrected. The authors get
> their royalties even if there are a thousand bugs
> in the manual and 10,000 typos.

Even sillier. Those sell fuck all of the books that
are that bad and so fuck all in the way of royaltys.

> I remember our PDP-10 writers spent 4 years and two major
> monitor releases and IIRC three iterations to figure out which
> was THE best way to describe how to type <CTRL>C and how
> to signify the character on paper.

And we now see FAR more man hours go into how the
user interface in iOS alone is done so you don’t have to
fart around with that sort of shit in some printed manual.

[Lon]

That may have made a good story, but it seems unusual for the era.
Our tech writers were always paired up with the experts in the area of
the doc, to include having both a manufacturing tech and a support tech
provide input for the doc. Then, to audit the result, we'd pick a VP
and have them try to follow the doc.

[Lon]

To shift the paradigm slightly, with the capabilities of modern hardware
and interfaces, a truly good product really shouldn't need a separate
document. To a large part, the user interface should pretty much
explain itself, and if the user has a question, context sensitive help.

Even for installation, once you have a display method, the darn thing
should be able to guide the installer thru the rest of the process
including flagging incorrect assembly and guidance of where to move the
incorrectly connected doohickey.

[Lon]

With the disclaimer that I only ran into a fairly small subset of DEC
documentation, I don't recall ever running into any documentation from
any other vendor that could match the IBM stuff such as FAPLs, 3270
guides, OEM channel interface, etc. You could design a matching
product from scratch just using those docs... and it would work pretty
much like the blue ones.

[jklam]

"Lon" <lon.s...@comcast.net> wrote in message
news:cuKdnfeefpAeU0jM...@giganews.com...

> On 7/3/2013 2:10 PM, jklam wrote:
>>
>>
>> "Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
>> news:m3obajy...@garlic.com...
>>>
>>> Patrick Scheible <k...@zipcon.net> writes:
>>>> There are docs, not as good as the ones for DEC back in the day but
>>>> when
>>>> you're selling a $100,000 worth of product it's easy to include a few
>>>> thousand $ worth of technical writer's time. When it's a $500 PC, not
>>>> so much. There are also a lot of resources now that weren't available
>>>> in the 1970s.
>>>
>>> csay @$50 on 200,000 $500 PCs is same as $10,000 on 1,000 $100,000
>>> machines ... one could claim that good documentation is more important
>>> when it is 200,000 customers ... might actually be closer to 2,000,000
>>> machines.
>>

>> DEC's documentation for stuff like the Rainbow was nothing special.

>
> With the disclaimer that I only ran into a fairly small subset of DEC
> documentation, I don't recall ever running into any documentation from any
> other vendor that could match the IBM stuff such as FAPLs, 3270 guides,
> OEM channel interface, etc. You could design a matching product from
> scratch just using those docs... and it would work pretty much like the
> blue ones.

And even with stuff like the original IBM PC and XT, it was so completely
documented that you could trivially steal the entire design and plenty did
just that given that it had full circuit diagrams and the complete bios
listing.

[jmfbahciv]

Right. The dearth of documentation is in the areas of system analysis,
operations, and field service-ish maintenance.

I've given up on the commands piece. I sure wish the TOPS-20 command
interface would be "reinvented".

/BAH

[jmfbahciv]

<grin> Nice choice for the Token Dummy. that was our name for the
person who did the MIG (monitor installation guide) checkout. We made
it so it was an honor to be the one for the release.

/BAH

[Shmuel Metz]

In <cuKdnfSefpBOUEjM...@giganews.com>, on 07/04/2013

at 01:32 PM, Lon <lon.s...@comcast.net> said:

>To shift the paradigm slightly, with the capabilities of modern
>hardware and interfaces, a truly good product really shouldn't
>need a separate document. To a large part, the user interface
>should pretty much explain itself,

In half a century of computer experience, I have yet to find anything
touted as self documenting or user friendly that actually was. That
applies to interfaces and languages.

>To a large part, the user interface should pretty much explain
>itself,

But never does.

>and if the user has a question, context sensitive help.

It would be nice if the context sensitive help actually answered the
user's question; it often doesn't.

>Even for installation, once you have a display method, the darn
>thing should be able to guide the installer thru the rest of the
>process

It would be nice if someone gave me $1,000,000,000.00; it hasn't
happened yet. Typically, what happens is that the designers
anticipated a small set of questions and if you need answers to
anything else, you're SOL.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <PM0004E0A...@aca254e6.ipt.aol.com>, on 07/04/2013

at 01:22 PM, jmfbahciv <See....@aol.com> said:

>the $500 PC is the hardware, not the OS. The problem with today's
>biz is that there is no feedback mechanism to improve one manual. No
>SPRs

That's true for the PC world, but not for the mainframe world.

[Walter Banks]

"Shmuel (Seymour J.) Metz" wrote:

> In <cuKdnfSefpBOUEjM...@giganews.com>, on 07/04/2013
> at 01:32 PM, Lon <lon.s...@comcast.net> said:
>
> >To shift the paradigm slightly, with the capabilities of modern
> >hardware and interfaces, a truly good product really shouldn't
> >need a separate document. To a large part, the user interface
> >should pretty much explain itself,
>
> In half a century of computer experience, I have yet to find anything
> touted as self documenting or user friendly that actually was. That
> applies to interfaces and languages.
>
> >To a large part, the user interface should pretty much explain
> >itself,
>
> But never does.
>
> >and if the user has a question, context sensitive help.
>
> It would be nice if the context sensitive help actually answered the
> user's question; it often doesn't.

The best documented projects I have been part of is when
tech writers are part of the design process documenting the
user requirements and usage. Engineers then have a dynamic
implementation document tied to the user document. These
type of products tend to at least do what is documented.

w..

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <cuKdnfSefpBOUEjM...@giganews.com>, on 07/04/2013
> at 01:32 PM, Lon <lon.s...@comcast.net> said:
>
>>To shift the paradigm slightly, with the capabilities of modern
>>hardware and interfaces, a truly good product really shouldn't
>>need a separate document. To a large part, the user interface
>>should pretty much explain itself,
>
> In half a century of computer experience, I have yet to find anything
> touted as self documenting or user friendly that actually was. That
> applies to interfaces and languages.
>
>>To a large part, the user interface should pretty much explain
>>itself,
>
> But never does.
>
>>and if the user has a question, context sensitive help.
>
> It would be nice if the context sensitive help actually answered the
> user's question; it often doesn't.

Not sure why you would claim that.
ISPF is full of very useful help panels.

I know a lot of developers that are biased toward criticizing
the work of other developers. I try to hold my criticism for
cases where it's really deserved.

--
Dan Espen

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E0C...@ac8109c6.ipt.aol.com...

That is just plain wrong with the vast range of stuff on the net in those
areas now.

You just ignore all that completely. Doesn’t mean it doesn’t exist tho.

> I've given up on the commands piece. I sure wish the TOPS-20 command
> interface would be "reinvented".

The world's moved on, just like it always does with computing now.

Now that so many of the most portable systems don’t even have a
keyboard at all for other than bulk text input, it makes absolutely no
sense at all to be using the keyboard for the most basic ops anymore.

You don’t even need the keyboard for small amounts of text input
anymore, Siri with iOS does a very decent job of voice recognition
to text with notes etc.

[jklam]

"Shmuel (Seymour J.)Metz" <spam...@library.lspace.org.invalid> wrote in
message news:51d69b56$3$fuzhry+tra$mr2...@news.patriot.net...

> In <cuKdnfSefpBOUEjM...@giganews.com>, on 07/04/2013
> at 01:32 PM, Lon <lon.s...@comcast.net> said:
>
>>To shift the paradigm slightly, with the capabilities of modern
>>hardware and interfaces, a truly good product really shouldn't
>>need a separate document. To a large part, the user interface
>>should pretty much explain itself,

> In half a century of computer experience, I have yet to find anything
> touted as self documenting or user friendly that actually was.

Quite a bit is, most obviously with phones, cellphones and cars
for the most basic operations like making a call or driving the car.

Sure, it's hard to do that with getting an outside line with an
office phone system, but quite a bit is pretty user friendly once
you understand the most basic concepts of phone numbers etc
and having the most basic stuff like the gear shift pattern
marked on the top of a manual gearstick etc.

Sure, there are certainly some quirks like with my manual car
that you have to put your foot on the clutch before you can
start the engine, but it isnt hard to document those quirks.

> That applies to interfaces and languages.

There is very little documentation provided with an iphone
and few have any real difficulty with using them and there
are very decent manuals online for those who need that
level of documentation.

>> To a large part, the user interface should pretty much explain itself,

> But never does.

That’s overstated. It often does in fact with the best systems.

>> and if the user has a question, context sensitive help.

> It would be nice if the context sensitive help actually
> answered the user's question; it often doesn't.

Often it does too, most obviously with the question marks
on forms that give you more detail on what that box is for,
like with the security digits on the back of a credit card etc.

>> Even for installation, once you have a display method,
>> the darn thing should be able to guide the installer
>> thru the rest of the process

> It would be nice if someone gave me $1,000,000,000.00;
> it hasn't happened yet.

There is plenty of stuff that would be
nice with technology has happened now.

You don’t even need to type notes to yourself with an iphone
anymore, Siri does a fucking good job of voice recognition and
can do notes to yourself, notes to others, reminders with dates
and times on them all by voice.

Dinosaurs demand that the TOPS-20 CLI be used for stuff like that.

> Typically, what happens is that the designers anticipated a small set
> of questions and if you need answers to anything else, you're SOL.

And now the web means that what the designers anticipated is
irrelevant and you are nothing even remotely like SOL anymore
when the web is always available on that device.

With the best implemented systems you can see something
on offer in Craig's List or one of the Facebook Buy Sell Swap
groups that have replaced Craig's List, tap on the physical
address and have it pop up the built in GPS that tells you
how to get there and tells you when you have got there.
And the only documentation you need for that is to tell
the user that tapping on an address will get it to do that.

[hanc...@bbs.cpcn.com]

On Sunday, June 30, 2013 11:09:16 AM UTC-4, Dan Espen wrote:

> Just about every analyst in the field (including programmer analysts) knows how to design a data entry process. If they don't, they're going to hear about it and learn.

With all due respect, you would be surprised at how many analysts* fail to take into account data entry considerations when they design a new source document or input process. Even if the process is designed properly, the data entry people still appreciate it when the analyst sits down and _listens_ to them rather them simply hand off a form for a new application. Further, advanced data entry systems had both quirks to be avoided and processing facilities that the analyst typically would not know about, but the keydata people would know--it's what they deal with every day. jmfbahciv was right.

Years ago, when I implemented a new CICS application, I brought the lead users in to meet our network support staff, whom they'd be in contact with for day-to-day issues (network hardware reliability wasn't as good in those days). Both sides greatly appreciated meeting "the voice on the other end of the telephone" and the this was a win-win for all. I don't think we'd even be _allowed_ to do that today.

*Computer analysts are human, and like other humans, their skillset is varied with strengths and weaknesses. Dealing with data entry and other operations-support staff was a skill that many people in the business could've used some improvement.

[hanc...@bbs.cpcn.com]

On Monday, July 1, 2013 1:48:40 AM UTC-4, Dave Garland wrote:

> And especially with stuff developed in the "aulden days" when Barb was at DEC. Back then, the excuse was usually "the computer needs it that way".

Well, going back far enough computers had very little memory, so the kind of verbage we accept today wasn't possible. Name and address fields were quite short and pretty much everything else was coded numerically. There wasn't much that was intuitive.

Indeed, one common frustration with computerized systems of those years was a "none of the above" answer for which there was no entry. There was no space to spare for comment fields. And of course, the infamous "invalid entry" response message--with no further information.

(Previously a posted a link to a 1960s computerized reservation system description that had extremely terse command and response strings. I'll repost it if anyone is interested.)

A lot of the pioneer programmers of those early days were engineers and mathemeticians. They were great with bits and bytes and packing a lot of functionality into 16k, but not so good at the human element. Plus, time was a factor and developers were under pressure to get a [usually unexpectedly late] system out the door.

[hanc...@bbs.cpcn.com]

On Monday, July 1, 2013 8:22:21 AM UTC-4, Dan Espen wrote:


> I started in the field in 1964. I remember lots of articles about well designed data entry and lots of review of input forms with users. From my small porthole into the process, it seemed like we were aware of the issues and addressed them.

You were fortunate to work in good facilities.

At college, in a computer design class, our first assignment was to bring in an example of a poor computer system. Well, every kid brought in _multiple_ examples of lousy systems and horror stories of being a customer trying to pay a bill, an employee trying to get their pay check, make a reservation, deal with their bank, and so on. Some kids who had real world job experience talked about the frustration and being a clerk in a business with a screwed up system.

Then our professor told us about systems where managers ignored the reports of their company's million dollar machine and depended instead of a private 3x5 card index.

The systems we would design in class would have to avoid all the problems cited. It was not easy.

[Shmuel Metz]

In <ic4nc9x...@home.home>, on 07/05/2013

at 12:46 PM, Dan Espen <des...@verizon.net> said:

>Not sure why you would claim that.
>ISPF is full of very useful help panels.

1. ISPF is highly atypical. In fact, mainframe documentation in
general is highly atypical.

2. IBM publishes thousands of pages in ISPF manuals;
they don't claim that the help panels are self contained.

>I know a lot of developers that are biased toward criticizing the
>work of other developers. I try to hold my criticism for cases
>where it's really deserved.

When did I criticize ISPF documentation?

[Shmuel Metz]

In <PM0004E0C...@ac8109c6.ipt.aol.com>, on 07/05/2013

at 01:05 PM, jmfbahciv <See....@aol.com> said:

>I sure wish the TOPS-20 command interface would be "reinvented".

And patented by m$?

[Dan Espen]

hanc...@bbs.cpcn.com writes:

> On Sunday, June 30, 2013 11:09:16 AM UTC-4, Dan Espen wrote:
>
>> Just about every analyst in the field (including programmer
>> analysts) knows how to design a data entry process. If they don't,
>> they're going to hear about it and learn.
>
> With all due respect, you would be surprised at how many analysts*
> fail to take into account data entry considerations when they design a
> new source document or input process. Even if the process is designed
> properly, the data entry people still appreciate it when the analyst
> sits down and _listens_ to them rather them simply hand off a form for
> a new application. Further, advanced data entry systems had both
> quirks to be avoided and processing facilities that the analyst
> typically would not know about, but the keydata people would
> know--it's what they deal with every day. jmfbahciv was right.

I would be surprised.

But I don't think this is a discussion that can be settled,
no one has access to the information. How many badly designed
data entry processes are there? The answer is going to depend
entirely on your individual experience.

I do remember my own experience, I remember articles about data
entry forms. Most recommended that the form have some sort of
boxes, each box for one character. The height and width had ideal
sizes. Of course the fields are entered into the computer system
in the same sequence they are on the form.

It always seemed to me that this was universally known.

It doesn't seem like a complicated science to me, and my perspective is
that "most" of the industry did not suffer from bad data entry
procedures.

I have vague memories of a computer system that was designed to use
existing data forms, ones that were not designed for computer
processing.
Some fool laid out a card where the data entry person had to skip from
field to field in a different order than the data shown on the form.
I remember yelling and cursing, and a new card format created.
It wasn't all that hard to fix. I just don't think that bad data entry
processes were common.

If you saw something different, I can't account for that.

--
Dan Espen

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <ic4nc9x...@home.home>, on 07/05/2013
> at 12:46 PM, Dan Espen <des...@verizon.net> said:
>
>>Not sure why you would claim that.
>>ISPF is full of very useful help panels.
>
> 1. ISPF is highly atypical. In fact, mainframe documentation in
> general is highly atypical.
>
> 2. IBM publishes thousands of pages in ISPF manuals;
> they don't claim that the help panels are self contained.

Yes they do.

I don't remember finding anything in those manuals that I couldn't find
in the help system.

>>I know a lot of developers that are biased toward criticizing the
>>work of other developers. I try to hold my criticism for cases
>>where it's really deserved.
>
> When did I criticize ISPF documentation?

Well, you didn't.

But I wondered why you would make the claim (that you snipped)
when I knew you had been exposed to the mother of all help systems.

--
Dan Espen

[Dave Garland]

On 7/5/2013 3:40 PM, hanc...@bbs.cpcn.com wrote:
> On Monday, July 1, 2013 1:48:40 AM UTC-4, Dave Garland wrote:
>
>> And especially with stuff developed in the "aulden days" when
>> Barb was at DEC. Back then, the excuse was usually "the
>> computer needs it that way".
>
> Well, going back far enough computers had very little memory, so
> the kind of verbage we accept today wasn't possible. Name and
> address fields were quite short and pretty much everything else
> was coded numerically. There wasn't much that was intuitive.
>
> Indeed, one common frustration with computerized systems of those
> years was a "none of the above" answer for which there was no
> entry. There was no space to spare for comment fields. And of
> course, the infamous "invalid entry" response message--with no
> further information.

Of those years? I occasionally complete web-based market research
surveys. I assure you, the missing "none of the above" is alive and
well today. And you have to make a choice to advance to the next
screen. Now, I'll grant that the people who design web survey forms
are not exactly at the top of the programmer pecking order. But not
all software is created by the top 1%.

> A lot of the pioneer programmers of those early days were
> engineers and mathemeticians. They were great with bits and
> bytes and packing a lot of functionality into 16k, but not so
> good at the human element. Plus, time was a factor and
> developers were under pressure to get a [usually unexpectedly
> late] system out the door.

All of which is sometimes still true today. Well, aside from them
being engineers or mathematicians, or packing functionality into a
small space. I guess the generation who learned programming from
schools that advertised on the back of matchbook covers has moved
on, at least.

[Walter Bushell]

In article <b3oigq...@mid.individual.net>,

"jklam" <j...@nlgrf.com> wrote:

> Quite a bit is, most obviously with phones, cellphones and cars
> for the most basic operations like making a call or driving the car.

But not for things like dimming and brighting the headlights.
Designers spend much though in hiding that function.

--
Gambling with Other People's Money is the meth of the fiscal industry.
me -- in the spirit of Karl and Groucho Marx

[jklam]

"Walter Bushell" <pr...@panix.com> wrote in message
news:proto-025D22....@70-1-84-166.pools.spcsdns.net...

> In article <b3oigq...@mid.individual.net>,
> "jklam" <j...@nlgrf.com> wrote:
>
>> Quite a bit is, most obviously with phones, cellphones and cars
>> for the most basic operations like making a call or driving the car.
>
> But not for things like dimming and brighting the headlights.
> Designers spend much though in hiding that function.

No, it's just another of those functions that has not been
standardised across much of the industry, so isn't as obvious.

We have seen the same thing with things as basic as mains
power on off switches where the world ended up with two
different approaches and then ended up adding another
where you push it to turn it on and push it again to turn
it off again for various reasons. That last does cause real
problems with those with the worst mental deficiencies
apparently.

[Charlie Gibbs]

In article <proto-025D22....@70-1-84-166.pools.spcsdns.net>,

pr...@panix.com (Walter Bushell) writes:

> In article <b3oigq...@mid.individual.net>,
> "jklam" <j...@nlgrf.com> wrote:
>
>> Quite a bit is, most obviously with phones, cellphones and cars
>> for the most basic operations like making a call or driving the car.
>
> But not for things like dimming and brighting the headlights.
> Designers spend much though in hiding that function.

Maybe it's one of these things that few people bother to do
anymore. Here in Canada daytime running lights are often
implemented through the high beams. I leave my rearview
mirror in the night setting all the time now.

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

[Charles Richmond]

"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote in message
news:928.969T11...@kltpzyxm.invalid...

> In article <proto-025D22....@70-1-84-166.pools.spcsdns.net>,
> pr...@panix.com (Walter Bushell) writes:
>
>> In article <b3oigq...@mid.individual.net>,
>> "jklam" <j...@nlgrf.com> wrote:
>>
>>> Quite a bit is, most obviously with phones, cellphones and cars
>>> for the most basic operations like making a call or driving the car.
>>
>> But not for things like dimming and brighting the headlights.
>> Designers spend much though in hiding that function.
>
> Maybe it's one of these things that few people bother to do
> anymore. Here in Canada daytime running lights are often
> implemented through the high beams. I leave my rearview
> mirror in the night setting all the time now.
>

Long ago, when my dad was a young man... he had his own solution. Back when
it was legal, he had a forward-pointing spotlight on his car. When an
approaching car did *not* dim their headlights at night, he would hit them
with the spotlight. That got an almost instant response.

--

numerist at aquaporin4 dot com

[Walter Banks]

hanc...@bbs.cpcn.com wrote:

> On Monday, July 1, 2013 8:22:21 AM UTC-4, Dan Espen wrote:
>
> > I started in the field in 1964. I remember lots of articles

> > about well designed data entry and lots of review of input

> .> forms with users. From my small porthole into the process,

> > it seemed like we were aware of the issues and addressed them.

>

> At college, in a computer design class, our first assignment

> was to bring in an example of a poor computer system.

Unfortunately they are still around. I was trying to
pay a bill on line to my home ISP provider a few
days ago and the online payment system had no
way of backing out of a menu item that had been
selected through an ambiguous prompt (prompt
for credit card to pay bill which actually meant
pay bill automatically forever not pay this months
bill, I had just displayed current balance). It also
wasn't clear that it wasn't a deliberate *mistake*
no confirmation and no back out or no change.

w..

[greymausg]

On 2013-07-06, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> In article <proto-025D22....@70-1-84-166.pools.spcsdns.net>,
> pr...@panix.com (Walter Bushell) writes:
>
>> In article <b3oigq...@mid.individual.net>,
>> "jklam" <j...@nlgrf.com> wrote:
>>
>>> Quite a bit is, most obviously with phones, cellphones and cars
>>> for the most basic operations like making a call or driving the car.
>>
>> But not for things like dimming and brighting the headlights.
>> Designers spend much though in hiding that function.
>
> Maybe it's one of these things that few people bother to do
> anymore. Here in Canada daytime running lights are often
> implemented through the high beams. I leave my rearview
> mirror in the night setting all the time now.
>

I find that (lights in daylight) irritating, coming to a
junction, all you can see is the first car coming from that
direction...


--
maus

Will rant for food. (Sugar free, of course)

[jmfbahciv]

Shmuel (Seymour J.) Metz wrote:

> In <PM0004E0C...@ac8109c6.ipt.aol.com>, on 07/05/2013
> at 01:05 PM, jmfbahciv <See....@aol.com> said:
>
>>I sure wish the TOPS-20 command interface would be "reinvented".
>
> And patented by m$?
>

They couldn't do that. If MS did use a decent user command system,
a lot more work would get done.

/BAH

[jmfbahciv]

Just look at the web pages. One should never, ever have to move the
page down just to hit the "next" key.

/BAH

>

[jmfbahciv]

Charlie Gibbs wrote:
> In article <proto-025D22....@70-1-84-166.pools.spcsdns.net>,
> pr...@panix.com (Walter Bushell) writes:
>
>> In article <b3oigq...@mid.individual.net>,
>> "jklam" <j...@nlgrf.com> wrote:
>>
>>> Quite a bit is, most obviously with phones, cellphones and cars
>>> for the most basic operations like making a call or driving the car.
>>
>> But not for things like dimming and brighting the headlights.
>> Designers spend much though in hiding that function.
>
> Maybe it's one of these things that few people bother to do
> anymore. Here in Canada daytime running lights are often
> implemented through the high beams. I leave my rearview
> mirror in the night setting all the time now.
>

But isn't it Canada who has the law they have to be on? My
car has them and I can't turn them off. It's dangerous
because the few times I've driven at night, I thought my headlights
were on but they weren't.

/BAH

[Dan Espen]

Right, but a web page should not be used as a data entry system.
Sure you enter data, but you wouldn't want to do it all day.

over here:

http://www.investorvillage.com

the discussion forums allow you to type "n" and "p" for "next" and
"previous". It's done with Java Script. One of the few web sites
I've seen with hot keys.

--
Dan Espen

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E0D...@aca22c6a.ipt.aol.com...

Trouble is that when so many have such variable depth pages due to
the wide variety of toolbars that are possible and the variation in how
deep each of those is, it just isnt viable to assume some minimum page
depth and ensure that the next button is never below that because that
means there is fuck all of a page to have the fields on, or you end up
with a form which has very little on each page, and so lots of pages.

Now that scroll wheels are available for all but the worst dinosaurs,
it can make sense to have everything on a single page and just have
a next button on the bottom of that page.

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004E0D...@aca22c6a.ipt.aol.com...

> Shmuel (Seymour J.) Metz wrote:
>> In <PM0004E0C...@ac8109c6.ipt.aol.com>, on 07/05/2013
>> at 01:05 PM, jmfbahciv <See....@aol.com> said:
>>
>>>I sure wish the TOPS-20 command interface would be "reinvented".
>>
>> And patented by m$?
>>
> They couldn't do that. If MS did use a decent user command system,

They have done for a long time now. Hardly anyone uses it.

> a lot more work would get done.

No, because there just aren't enough dinosaurs still around.

[Shmuel Metz]

In <icobagw...@home.home>, on 07/05/2013

at 05:34 PM, Dan Espen <des...@verizon.net> said:

>> 2. IBM publishes thousands of pages in ISPF manuals;
>> they don't claim that the help panels are self contained.

>Yes they do.

Where does IBM make such a claim?

>I don't remember finding anything in those manuals that I couldn't
>find in the help system.

I don't recall writing an ISPF application where I never had recourse
to the manuals.

>But I wondered why you would make the claim (that you snipped) when
>I knew you had been exposed to the mother of all help systems.

Because the claims were true. ISPF does not "pretty much explain
itself". "It would be nice if the context sensitive help actually
answered the user's question; it often doesn't." does not refer to
ISPF and while I am comfortable with IBM install processes, they are
not "able to guide the installer thru the rest of the process."

If you're going to tell me that a z/OS install is less frustrating
than, e.g., a windoze 8 install, that's damning with faint praise.

[Dan Espen]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:

> In <icobagw...@home.home>, on 07/05/2013
> at 05:34 PM, Dan Espen <des...@verizon.net> said:
>
>>> 2. IBM publishes thousands of pages in ISPF manuals;
>>> they don't claim that the help panels are self contained.
>
>>Yes they do.

I'm confused, I don't remember writing that and I don't think
the help panels are advertised as complete, I just found ISPF
help more than adequate for writing a lot of ISPF dialogs.
When I went to the manuals, I didn't find anything new.

> Where does IBM make such a claim?
>
>>I don't remember finding anything in those manuals that I couldn't
>>find in the help system.
>
> I don't recall writing an ISPF application where I never had recourse
> to the manuals.

If you go into the ISPF model system, the help for models
is by far the largest part of the ISPF help system.

I can't remember any ISPF service that wasn't completely explained
by the model system. Bringing in the model gives you a snippet with
some notes, but the trick is to navigate to the panel that allows
you to select the model, and then press help.

>>But I wondered why you would make the claim (that you snipped) when
>>I knew you had been exposed to the mother of all help systems.
>
> Because the claims were true. ISPF does not "pretty much explain
> itself". "It would be nice if the context sensitive help actually
> answered the user's question; it often doesn't." does not refer to
> ISPF and while I am comfortable with IBM install processes, they are
> not "able to guide the installer thru the rest of the process."
>
> If you're going to tell me that a z/OS install is less frustrating
> than, e.g., a windoze 8 install, that's damning with faint praise.

Since I'm not a z/OS sysprog, I have no first hand experience.
Installing z/OS is a completely different subject.


--
Dan Espen

[jmfbahciv]

<grin> But some hotshot will make a form which doesn just that.
the few web pages which I tried to fill out had similar problems.

>
> over here:
>
> http://www.investorvillage.com
>
> the discussion forums allow you to type "n" and "p" for "next" and
> "previous". It's done with Java Script. One of the few web sites
> I've seen with hot keys.
>

That would be a very useful standard. I wonder if web page designs
will get a standard template.

Which prompts another question...do templates exist in the computer
biz these days?


/BAH

[Shmuel Metz]

In <ictxk6v...@home.home>, on 07/07/2013

at 09:29 AM, Dan Espen <des...@verizon.net> said:

>If you go into the ISPF model system, the help for models is by far
>the largest part of the ISPF help system.

I use models, but I also use the manuals.

>Since I'm not a z/OS sysprog, I have no first hand experience.

Then why did you defend LON's claim "able to guide the installer thru
the rest of the process."?

[Rod Speed]

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004E0E...@aca2297c.ipt.aol.com...

I use Roboform which fills out forms auto.

>> over here:

>> http://www.investorvillage.com

>> the discussion forums allow you to type "n" and "p" for "next" and
>> "previous". It's done with Java Script. One of the few web sites
>> I've seen with hot keys.

> That would be a very useful standard. I wonder if web page designs
> will get a standard template.

Not even possible.

> Which prompts another question...do templates exist in the computer
> biz these days?

With some stuff, of course.

[Charlie Gibbs]

In article <PM0004E0D...@aca22c6a.ipt.aol.com>, See....@aol.com

I've noticed a significant increase in the number of cars driving
without tail lights at dusk or in heavy rain. I suspect many people
are fooled into thinking that their headlights are "on" when the
switch - and their tail lights - are off.

When these things first appeared (around 1989 IIRC), the first
thing I noticed was the number of cars that appeared cross-eyed
during the day, i.e. the inner lamps were lit rather than the
outer ones on a 4-lamp system. Also, the standard practice of
blinking one's lights to signal other people seemed to be replaced
by flicking high beams at them. At the time, I thought this was
just a combination of the spreading more-is-better philosophy
and the decline in manners - but I realize now that it wasn't
the drivers that were becoming rude, just the design of the
headlights.

Ironically, on a car with high-beam running lights, turning
the headlight switch to "on" actually reduces the amount of
light reaching the eyes of oncoming motorists.

As for not being able to turn them off, somehow something worked
loose in my car's fuse panel (ahem) and I now have full control
over whether my lights are on or not.