Re: Why a "retired farmer"?
Yup. He'd have run faster at the very suggestion.
33005 publicly visible posts • joined 16 Jun 2014
Context is everything: in this case, an old mainframe system, the wording might well have been specified by an analyst or designer and not left to a junior programmer. It would have been specified that way because it wasn't customer facing, it was staff facing.
In general we need to realise that there's a hierarchy of ways to convey information. The UI is, whatever the era and technology, limited in bandwidth.
Long labels mean either crowded or oversized screens.
Long prompts aren't always going to be read or will sometimes be misread.
"Discoverable" functionality isn't going to be. Have you ever been shown, read or seen in a video some function of an application you thought you knew and thought "I forgot/never knew it could do that?".
Adding tool tips, extra documentation and training all have their places over and above the first line UI.
If you find something that old it's very likely driving some extremely expensive diagnostic machine which isn't going to be replaced any time soon and whose manufacturer has disappeared or never got the system re-qualified on a later version. Possibly it relies on an ISA interface card with not more recent alternative available. It's not organisation that matters, it's money.
The difference between Shift and Ctrl is that with Shift the action, or the result of it, is visible. This is especially true when using a typewriter so Shoft and Lock will require no thought whatsoever to someone who started out on typewriters. Ctrl characters are not necessarily so and operate on a different level in the user's perception. Ctrl-V, Ctrl-Z etc. might result is a visible change, Ctrl-C has no immediately obvious result (assuming the context means copy).
“Are you sure” questions are daft.
Not if it saves you from the "Oh shit!" moment when you realise you've clicked the wrong button and what you've done is irreversible. They should, of course, be saved for such situations and accompanied by a clear statement of what it is you're about to confirm.
So if it's in use what do you tell them? That it isn't?
The system provided information. Using that information requires knowledge. Ensuring that the users have the appropriate knowledge needs wisdom. Until Eric appeared on the scene the last two were absent.
The correct response to the information might depend on circumstances. In some the sessions in use might all be required by staff not immediately present and logging one out strictly against the rules. In this case the correct response was to log one out. It should be the management's role to ensure the user knew what to do and what not to do. It would certainly not be the developer's to either second guess the situation nor to go over their core budget writing an effusive essay.
Let me give you the fuller quottion: "The past is another country. They do things differently there."
It's worth remembering that this story involves systems going back to the late '50s. At that time memory was hideously expensive and mainframes had very little of it. The programmer (or analyst - the programmer might not have had to provide the text) would have had an overall budget for memory and none of it to spare to substitute for user training. Wasting 8 bytes to say "Session A in use" might have resulted in a bawling out.
The past is another country.
"Could this be mis-interpreted?"
Of course it can be misinterpreted. There's always somebody to misinterpret anything.
I think there's a difference between some software being released to the public and something provided by a company for its employees to use as part of their job. One hopes the user had been trained in other aspects of booking a flight. She should have been trained to understand any routine aspect of it and this appears to have been routine.
Training- exactly. This wasn't a lay person. This was an employee who had been provided with a tool to use for her work. This was the tool behaving exacrtly as its user should have expected. She should have been trained to use it. Maybe a test after a week or so to see if the training had stuck.
We had a guest speaker the other week coming to give a presentation. He'd alarmed us by saying he had two videos to show which were currently on his phone. Eventually he got them into his .ppt which he sent in advance. Our Mac colleague couldn't get them to play. He sent me a copy. It turned out they were some Microsoft format.
LO on my main laptop (Linux of course) would play them but they both insisted on playing twice. Fortunately VCL transcoded them to mp4 (at a fraction of the former file size) which played OK, including playing sound to external speakers, so I swapped them for the original versions and saved as an Impress file. I took my laptop along to the talk just in case.
As it turned out the speaker brought his own laptop - I didn't look too closely but I think it may also have been a Mac - so they decided to use that. His laptop couldn't get sound out to a set of external speakers. These decisions were made while I was busy sorting out the presenter's mic. The situation was salvaged by borrowing a very tinny and not very powerful Bluetooth speaker.
"the kids who graduated Uni/College and got into the corporate computer and networking world back when computers started becoming ubiquitous on desktops all over the corporate world are now roughly in their mid 50s. ... In their minds (and the generations following) it's supposed to be shoddy code,"
True in a general way but there were still some big systems around and no doubt some of the new graduates became familiar with them. And as you and I both know there was Unix continuing through all that.
It wasn't all flawless in the past. I had one card compilation run that didn't - a new version of the system library had gone in that morning and it wouldn't link. It was reverted the same day, of course.
"Day to day commutes are compensated...If these rights are embedded in legislation, there is no can of worms to open."
In what legislation? This would certainly not be the case in the UK (if commuting costs to a regular place of work were covered it would be taxable*) and as far as I know not in the US. If this were to lead to WFH to be withdrawn by employers there might be people looking out for this guy and wielding attitude adjustment tools.
* Another can of worms for freelancers.
Considering my extremely low opinion of the technical depth behind this bullshit, I fail to see how the above is a problem. I've already said that CERT is effectively saying "come, DDOS me", and who are we to say "no sir!"?
I've always believed that IT's ultimate sanction is to give users exactly what they asked for. This seems to be an appropriate occasion for applying it.
"a thermostat on each radiator, end off. I first time encountered a central thermostat in the UK and wondered how that would play with the radiator mounted ones"
We have radiator thermostats but also a central programmable thermostat/timer. It allows the heating to be cut back at certain times of day to override the radiator stats. As it's not networked it cuts out the IoT crap.