Never mind the obscure programming style or the total lack of helpful comments left by the programmer. The biggest disgrace was the experience of the poor users.
Failing to cope
In some circumstances, the computer system failed to cope. This, of course, is a common occurrence with computer systems. Users type in stuff the system can't handle, data gets corrupted, bugs in the code lead to situations that make no logical sense - there are many reasons why a system will end up unable to finish what it started.
A decent programmer (even a half-decent programmer) will expect that this could happen and will try their utmost to ensure the system handles it gracefully.
This computer system didn't. It put a very techie-style error message on the screen and did nothing else. The poor user was stuck with a screen that made no sense and no obvious way to get out of it. (This was mainframe-based - so no mouse, no windows - just a box where you could type stuff, which was ignored.)
(For those who care, the way out for the user was to press the 'clear-screen' button and type 'CESF' and press enter. Not many users were going to guess that.)
Yes, but why?
I contacted the original programmers to ask what they were thinking.
Ah, they explained slightly patronisingly, if it's got to that state then we have to 'abnormally terminate' the program in order to force a 'rollback'.
(Rolling back is when the system puts all its data back to the way it was before the whole sorry business started. In theory, that should be consistent and stable. Oh, the user's work is lost but that's better than the whole thing going up the Swanee.)
Sadly, an 'abnormal termination' leaves the mess on the screen (as described above) but, hey, that's part of ensuring the data stays safe.
Except there's a command called... wait for it... ROLLBACK. It does the thing I just described. It allows the program to stay in control, put a helpful message on the screen and return the user to a menu they can actually use.
This team of crack programmers apparently hadn't heard of this.
Yes, but why the history lesson?
Bear with me.
That story is about sixteen years old. But looking after the user experience is one of the big keystones of computer system design. Leaving the user out in the cold, twisting in the wind is one of the worst things you can do.
You get the system to handle the error and do something useful. It's really not hard. No, really, it's not hard.
Yes, Apple, it's really not hard.
Don't tell me you're having a go at the most profitable private company in history?
Yes I am.
We have an iPad, from back in the days when it was just 'the iPad'. The first one. There's absolutely nothing wrong with it except the problems caused by Apple's software decisions.
The Safari web browser has a lovely quirk. Give it a website that has an element that it can't handle and it simply crashes. Straight back to the home screen.
For example, http://theguardian.com - try loading it on your original iPad. It won't take long. The webpage appears, the text appears, the pictures load, then it freezes for a second and then you're crashed back to the iPad home screen.
It's probably a fault on The Guardian's side. Some dodgy Javascript or newfangled dynamic whatsit is asking Safari for the impossible.
It's asking Safari to do the equivalent of running headfirst into a wall. Certainly, the website shouldn't be asking. But, equally worthy of blame and derision is the fact that Safari dutifully obeys.
Here's what I'd do
If I were designing a browser, I would arrange it to ignore impossible instructions and carry on with the next thing.
Funnily enough, that's precisely how browsers used to work. You could write all manner of garbage in the webpage and the browser would just display what made sense and bypass the rest.
Instead, we have a computer system that is being instructed to run headfirst into a wall. So it does. Boom bang crash and down it goes.
It's all Apple's fault
I neither know nor care what the underlying fault actually is.
But I know that it's Apple's fault that it's not being handled gracefully. I just wanted to read an article. But they decided that if I couldn't have every last pixel precisely as intended - then I was to get none of them at all.
Any fool knows that's the wrong approach. Wrong, wrong, very very wrong.
Unless, of course, you'd rather encourage someone to buy a new shiney machine. Then knobbling your own hardware begins to sound very sensible indeed.
Surely this can't be the case
If you wanted to encourage people to upgrade their expensive hardware then you could follow this roadmap to becoming the most profitable private company ever in the history of private companies that are profitable:
- Make expensive stuff
- Write the software so it handles new developments in data (or webpages) badly.
- Wait a year or two for those new developments to start to become common.
- Fix the software so it can handle these new developments.
- Only make the fixes available to people who have the latest version of your expensive stuff
- Go back to step 1
And, of course, in the event of an error in that six-point system, run headfirst into a wall. But make sure the wall is made of paper and you've already got your bonus for the year.
No comments:
Post a Comment