You often learn the golden rule or some variation of it as early as kindergarten. There are several ways to phrase it, but you most often hear: “Do unto others as you would have them do unto you.” While that’s catchy, it is really an aphorism that encourages us to consider the viewpoints of others. As people who design things, this can be tricky. Sometimes, what you want isn’t necessarily what most people want, and — conversely — you might not appreciate what most people want or need.
EDIT/1000
For example, printing a few lines around the current line requires the command: “/-2,L,5” which isn’t that hard, I suppose. To delete all lines that contain a percent sign, “1$ D/%/A/” assuming you don’t want to be asked about each deletion.
Sure, sure. As a Hackaday reader, you don’t find this hard to puzzle out or remember. But back in the 1980s, a bunch of physicists and chemical engineers had little patience for stuff like that. However, the editor had a trick up its sleeve.
Old Terminal Basics
Old HP terminals didn’t work like you think of a terminal today. The computer would send a whole screen to the terminal along with some instructions. This was common on several brands of computers, even though it is rare today. For example, the computer might send a form with some data. The user can then use the terminal to modify the data or add new data. Then, with a single keystroke, the entire screen goes back to the computer for processing.
In the case of EDIT/1000, you could invoke screen mode, which would load a page of text into your terminal. Then you could use the arrow keys, insert, delete and the experience wasn’t too far from using a text editor today. Until you wanted to change pages, that is.
You’d use /S to start the screen mode from the current location in a file. But to move forward you needed to use Control+F. Well, that’s if you wanted to send your changes to the computer. You could also move forward and discard your changes by pressing Control+F twice. There were a handful of other commands you could use in screen mode. To do things like search and replace, you still needed the oddball commands along with the Control+X incantation to execute a command while in screen mode.
Complaint Department
We heard no end of complaints about EDIT/1000 and spent a lot of time helping people fix their mistakes made while editing. Training didn’t really seem to help. There didn’t seem to be any other reasonable options as far as buying a different editor.
The problem is, we were split into two camps. People who knew how to use EDIT/1000 well and people who needed to use it, but didn’t really know anything about it.
One More Puzzle Piece
HP terminals of the day all had an interesting feature. The keyboards had nine keys along the top row — what you’d think of as function keys today. The monitors always had eight little spots at the bottom that had labels for what the keys did. The ninth key let you page through a couple of sets of function keys. You can see that in the HP terminal teardown video below.
So F1 might have “Help” on the screen above it, unless you set the next page where it might say “Clear” or something. The effect was best on the terminals where the keyboard and screen were one piece so the labels lined up.
Then One Day…
I was thinking, probably uncharitably, about how stupid people were that couldn’t learn how to use the editor. I happened to be setting up custom function keys at the time. I wrote a quick program to put a few editor-specific keys on the terminal like “next page” and “previous page” and mapped them to the correct commands.
That worked fine, and then I wrote a short program to launch the editor on a file and put it into screen mode. I grabbed someone passing by and had them try it. By the end of the day, everyone was using “my” editor.
No Genius
I can’t overstate how simple this was. I later reduced it to just a batch file that copied a text file to the terminal to set the function keys, and then launched the editor. And everyone loved it. The people who knew how to use the editor didn’t need all this, of course. And they knew how easy it was. But they loved that it saved people asking dumb questions or messing up their files. The other users just loved it because it made the editor easy.
This predates easy access to the Internet, and a common thing in those days was to trade tapes with other sites. You’d get a magnetic tape in the mail, mount it, look at what was on it, copying anything you found interesting. Then you’d add anything you had to the end, and send it to the next place. In a year or so, the tape would make its way back around to you and the process would repeat. I put my editor on the outbound tape.
Within a year or so, people were literally finding me — hard to do in those days — and sending me real letters thanking me for my editor solution.
The Moral
The script to do this was extremely trivial. It probably took 10 minutes to write and once you knew how to do it, maybe less. But the point was, the people who knew how to write the script didn’t need it. The people who needed it were those who had no more idea how to program function keys than I know how to perform open heart surgery.
It doesn’t matter if it is hardware or software. Getting into the heads of users can really pay off.
I thought it was “program knowing that the next person to maintain it is a violent psychopath who knows where you live.”
It seems computers and software to it’s very bone are made to follow outdated standards.
It’s not just computers
It’s not the computers. It’s the humans that like to use outdated standards.
Like most things, standards have inertial properties. It should be expected and priced in
I love these kinds of stories. It’s basically how the whole field of User Experience started. :)
Stil some hiccups on the way. For instance CD-i, where CD-i developers thought that people would find it fun to scan the whole screen with the mouse pointer to find out where all the buttons were, and then clicking every button to find out what they would do.
Classic wrong thinking by engineers: thinking that users enjoy manipulating the machines as much as they do. But most users don’t, they don’t see the machine as a goal in itself, but as a tool to reach other goals. And they don’t enjoy manipulating the tool, they only enjoy reaching their goal.
Well, they’re simply NOT engineers. But it’s very hard for engineers, to put themselves in the shoes of non-engineers. Simply because engineers are born the way they are, or so I suspect.
Ah, the Linux experience. :-)
…The Arch Linux experience
It’s not necessarily that they’re not engineers – it’s that they’re not in an engineering mindset at that point.
They may not be engineers at all
They may be a different type of engineer
They may be a software engineer with a different specialty
They may just be in “entertainment” mode rather than “engineer” mode.
My brother is an Excel guru. He learned VBA and macros, he worked for small State budget office. He made many macros for his cow-orkers and bosses so they could print out Budget Reports. But often they came to him with a “one off” request. He’d tell them “I can teach you how to do this yourself in 15 minutes.”
But, most of them would refuse for various reasons (i.e. excuses).
He retired a couple of years ago. Then they contracted him to make videos explaining all things he was willing to show in the previous 20 years or so.
Can’t argue with job security.
For one-off tasks, teaching the person is ineffective because without the need to repeat performance soon, they will forget the lesson in three days and come back to you asking for the same advice. If it’s a task that repeats once a month, it can take up to a year before people start picking it up on their own, so you’re better off just writing the instructions down or better yet, just give them the macro.
If the task is repeating often enough that spaced learning can take place and the user can retain the knowledge, you should automate it or provide some kind of simplified interface because it’s a waste of time doing it “manually” every time. There is only a small overlap in the Venn-diagram for tasks that occur often, but not often enough to provide a canned solution. That’s the “power user” region, for people who know some tricks by memory, but don’t know the entire system in and out.
That’s the paradox with systems where the user interfaces are based on “programming” or other complex interaction that requires learning some open-ended procedure or syntax. They’re not exactly efficient for the basic users – only for the programmers who build or maintain them, who learn the required skills automatically through the job. You’re either in or you’re out.
Thanks, this was well phrased.
My sister had a friend who was very proficient with Excell – at least for her he seemed to be. One day she asked him how he became so good since he was not part of any IT related position. He said that whenever he wants to do something in Excell and it takes him more than few minutes most probably there is a function that does that since for sure he is not the first to run on this problem. So he calls IT and ask them which is the function?
On more than one occasion, my brother was contacted by IT, asking for assistance.
Did he?
When I started undergrad, our school was using video terminals at 2400 baud attached to a VAX, and we were instructed how to use the line editor to enter programs. I saw someone using a screen editor, and immediately asked him what that was and how I could use it. That’s when I became an Emacs user.
Luxury!
We used to dream of edline.
We entered programs by using copy con: myprogram.exe
Then used Alt-keypad to enter the headers, opcodes and data.
Code like a Klingon (from Yorkshire)!
That was the improved version.
Before, we wrote basic programs to poke the real program into memory.
And we liked it.
At least we didn’t have to learn an OS (emacs), just to edit a file.
‘Do onto others as they are planning to do to you, but do it first.’ is a grownup golden rule
Beware edge cases around oral. Not an obligation.
Ah, the fun of not having an assembler with DOS. I remember hand-compiling x86 and poking it with basic. Was very excited the first time it worked. Got boring REALLY fast!
“It doesn’t matter if it is hardware or software. Getting into the heads of users can really pay off.”
This is pretty much a universal truth for any human endeavor. Think about how what you make or do can make another person’s life better, and everyone will be happier, more productive, and better off.
Pay it forward.
Or for the more cynical: “It’s always good business to know your customers.” (Ferengi RoA#194)
There’s some dispute about the text and the actual number of that Ferengi Rule of Acquisition. But your overall point is well made.
“It doesn’t matter if it is hardware or software. Getting into the heads of users can really pay off.”
Just be sure it pays off to YOU, in the long or short term, not to a middle man, and be sure your customers,employers or friends knows that they are happier, more productive, and better off, thanks to YOU. Yeah I know, I know, but I didn’t invent the game, the rules were here already when I came in :)
Don’t just be a cog.
Especially don’t be the ass.
Don’t play that game.
Do better.
Yes, you can.
As I said… Yeah I know, I know, but I didn’t invent the game, the rules were here already when I came in :)… so I guess is all about find some equilibrium, both sides of the game are bad places.
If your user interface is not intuitive enough that someone can easily figure out what they need to do on their own you need to work on it to make it better, create better documentation or both. You also shouldn’t release a new interface that is missing functionality that the previous interface had (I’m looking at YOU Microsoft). It’s also a good idea to think through your interface fully BEFORE you start coding as going back and retrofitting functionality in might be a lot more work if you didn’t plan for the functionality in the first place.
ah, yes. memories of using cande on a burroughs b800 with td830 terminals. the editor would load a page into the terminal, you’d edit it locally, then transmit it back.
the td830 could also do forms. the computer could send a form containing text and a bunch of left-justified or right-justified fields. the user filled in the fields and sent the form back.
I babysat an HP1000 as well. Silicon on sapphire. Ours had the cool disk with the one button backup, that was kind of cool. We had a disk fail and HP was on site the next day. A van and 4 tech. The new “mech” came in a giant anvil case and they had a crane like thing they used to pull the old one out of the rack enclosure with and lower the new one into it with. And the 2628 terminals. Man that was a long time ago. HP kept up the weird crap even after the mini’s though. Their flavor of UNIX was meant to be used with one of their terminals. It was enough to make people not want to touch them. We had Sun’s that were a fraction of the speed but at least you could type on them. I spent some time collecting gripes and came out with and rc file that addressed most of the issues. Sun also got a lot of users mad with the move to Solaris. I recall they did a lot of the same. Just typing and using VI became a pain until you figured out what needed to be tamed.
I fondly remember the HP 1000-E, F, and M series (RTX-IVB). Fortran days. The big improvement in subsequent years was VAX-11/780s and PDP 11s, yet still assembly language, Fortran and C (but in those days also got to play with Snobol, lisp, Pascal, Modula-2 and Ada).
Oops RTE-11B
You don’t realise how bad a papercut can sting when you never encounter them yourself. This is why it’s useful to occasionally spend a few minutes to file off a rough edge, even if it’s “obviously” not going to make a difference to yourself – you can make someone else’s day.
Another thing is that learning takes effort and time, so people avoid learning. Any task you don’t already know is going to feel awkward and difficult for the first 5-10 times, which is forgotten by people who have already done it a hundred times.
If you have to skip to the documentation while trying to accomplish some other, more important task, it’s cutting off your flow and annoying. If that happens all the time, no matter how powerful the system actually is, it’s going in the dump in favor of some less powerful but more intuitive system.
MacOS says hi.
There is a corollary to the the golden rule of tech. Namely, users often know what they want but not what they need. Often, what they want won’t solve their problem. I don’t say this to denigrate users. Rather, I’ve realized it takes maturity and relationship building to really understand what the users are trying to accomplish and shaping the outcome to achieve that.
Nicely said.
In the mid 90’s I worked for an aerospace company where we’d use an HP/1000/RTE system with EDIT/1000 to develop the engine control software. My memory is a bit fuzzy, but I think we may have telnet-ed in via a VAX. I distinctly remember multiple occasions where just as I was pressing Ctr-F to save the screen buffer, A “broadcast all” message would be sent by an admin that would overwrite some of the screen just as the screen contents were being saved…
My first job out of college was managing a brand new IBM mainframe (mid-80s) for a team doing computer modelling projects. I spent most of my time writing macros that turned plain VM/CMS into something more intuitive for my users to run their jobs. I didn’t have to get into their heads much either; I just recreated what someone else had done on the system I used in college. I figured, what made life easier for me would probably work for them too.