Two More Examples

Two friends have sent examples of the sort of thing that this blog is all about: websites that difficult operations that should be simple. The experiences of my friends are recounted below, with some comments added by me.

Example 6: Nikon

Friend No 1 had bought some eye-glasses with lenses made by Nikon and was trying to register her purchase on their website. Most manufacturers of small equipment and accessories encourage purchasers to register their purchases. Frankly I don't think it does a lot for the purchasers in most cases but is obviously of advantage to the supplier: the supplier gains the contact details of the client. So you'd expect the registration process to be made as simple as possible; but you could be wrong. This friend couldn't at first find how to register her glasses on the Nikon website and so resorted to the telephone number given on the site. She ended up writing the following letter to Nikon.

“I think your whole system needs to be looked at. I had enormous difficulty when trying to register my Presio Balance Transitions Signature with SeeCoat Plus UV  spectacle lenses. The telephone number for assistance on your website was answered by someone who was unable to help me, but told me to telephone 00442082471717. At the commencement of this call I clearly stated that I had bought lenses for my spectacles, but the lady who answered the phone obviously didn't pick this up and it took about 15 minutes before she realised I hadn't  bought camera lenses and so she couldn't help me.”

“She then told me to phone 01908214100, where I was told after some discussion that they couldn't help me either because I wasn't an optician. I then phoned my optician who helped me fill in the registration form which I eventually located on the website and which I couldn't have done on my own as it required information which was not on the card I was given with the lenses. I had missed out certain sections when initially trying to fill in the form and when, as instructed by the optician, I went back to fill them in the result was to clear the whole form! This happened several times.
The process of registering my lenses took over an hour.”

“Your website is the worst I Have ever used and your telephone operators are not very helpful.
I will be reporting you as a company with a very bad website and will not be buying your products in future.”

What stands out for me here is the obvious inadequacies of user testing of the website, with the result that would should be an opportunity for CRM becomes a disaster.

Example 7: Online Train Ticket Booking

Friend No 2 wanted to book a train ticket. It can reasonably be assumed that train companies very much want people to do this so you would think they would make the process as simple and convenient as possible. Once again, think again. He has added his own comments to his experience, below. So I won't elaborate further.

“Booking a train ticket in the UK online includes a step that not only turns out to be unnecessary but in my case has also led to a time-wasting extra 4 mile journey to collect the ticket!”

“Train ticket booking websites include a mandatory phase in which you must specify the station at whose machine you will collect the paper ticket, and only then does it give you a voucher with a code number to input at the machine. The problem is that my local station (Winnersh), which is only 300 yards from where I live, and from where I will be travelling, and where I therefore wish to collect the ticket, does not appear in the list of available stations - even though it has a machine. I am therefore forced to specify a different station, in my case 3 miles away, and assume I must travel there just to collect my ticket.”

“I have complained about this to my local train operating company (TOC) only to be told that in reality no matter which station I have specified I can collect my ticket from my local station, or indeed from any other station. Mandating that a station be specified from an approved list is therefore not only an unnecessary and meaningless step in the process, but misleading. A representative from the TOC has said that the issue about my station being missing from the list would be passed to their website administrator; but that was more than 6 months ago and nothing has happened yet. But in any case why not eliminate this step from the process altogether and simplify the booking process?”

“From memory this applies to ‘South West Trains’ and ‘First’ booking sites – the train operators who run on my local line, but since they all take their data from a common underlying database it probably also applies to other operators”.

“There is of course a much wider usability issue for train ticket booking websites. Why can’t we print the actual ticket at home in much the same we do for plane journeys, and other countries do for trains? That would abolish the other annoying part of the current process, namely, having booked the ticket, possibly having to join a queue for the machine at the station to print it out.”

The ELSE Clause Explained

It has occurred to me that since this blog is aimed at, mostly, simple folk trying to do simply things the significance of the ELSE clause may need explaining; so here goes. Back in 1965 a couple of guys called Bohm and Jacopini demonstrated in a paper published then that only two control constructs were needed to control the sequence of instructions that were executed in a computer program. The first construct was in itself called SEQUENCE, which simply meant one instruction was executed after another in the sequence in which they appeared in the program. The second was called DO WHILE, which catered for conditional statements. It presupposed two or more conditions (true-false, black-white or whatever) and meant that if one of these conditions was true then an associated set of instructions should be executed and if the other condition(s) was/were true then another set of instructions should be executed. DO WHILE is not a very obvious concept to get your head round and so a more or less equivalent construct, IF THEN ELSE, was often used instead. This indicated that IF (e.g. true, black) applied a given set of instructions was to be executed and IF (e.g. false, white) applied then another set of instructions should be followed. ELSE at the end was a kind of “get out of jail” clause; it catered for anything that might have been overlooked in the conditions listed in the program. It is for most practical purposes equivalent to the “Other” box if one appears at the bottom of a list of tick boxes on a form.

ELSE allows for any conditions which the programmer may have overlooked or not considered relevant when writing the code. IT THEN ELSE is effectively the construct that applies when you are asked to make choices or have to fill in a form that contains alternatives. The alternatives and choices offered are those that the programmer has considered and written code for. But programmers (and I'm sure you will believe this) can make mistakes. They may think they have written code for all the conditions (choices, possibilities) that can occur but may, in fact, have overlooked some. In that case the ELSE clause, if they think to add it, gets them out of jail.

There is a slight problem in what code to write if the ELSE clause is activated, since it relates to a condition that hasn't been considered. In some situations it can safely be ignored as irrelevant. In others it may properly result in the display of an error message. However, it can also be relevant and not an error. I don't know of any standard method of dealing with this situation but would suggest that it should result in an automatic email to the site owner, showing the condition that has been neglected. That, of course, assumes that the site owner will accept emails from outside on situations that have been overlooked. I think it's called CRM (customer relationship management).