Friday, April 3, 2009

What can go wrong when using a web page for a service?

More and more transactions are moved from personal phone contacts or paper forms to web pages. Making me use a web page is clearly an advantage for the provider of the service, because data need not be entered manually in their system by his personnel and checks on consistency of my entry are forced on me when I enter the data.
The disadvantage is on my side: the services are not easy to use and hoist the providers view of he world on me. Here a reasoned list of issues:

Finding the web page
To remember the name of a web page is only feasible for the few services I use very often, for the other I have either a bookmark in my browser or use Google search. Relying on the browser bookmarks does not work when I am not on the computer I have produced the bookmark with.
Requirement: every web service must be easily found using Google search. Links to the service should be place on the appropriate home pages.

User name and password
Every service provider sends me happily a new user name and password, which I am supposed to learn by heart and not write on a post-it note pasted to the screen. I admit that more than knowing my name and perhaps 2 to 3 passwords and codes is difficult for me! I rely on my browser to remember user name and password – which does not work reliably if one uses more than one computer.
Requirement: I can select the same user name everywhere and set the password to the one I remember; I am willing to select one with 6 letter and non-letters – but no other requirements, please! The various requirements for length, to include numbers or other signs are forcing new passwords on me that I promptly forget.

We work in teams. Not everything a web services expect me to do I do myself, but often I can delegate some of the tasks to others. It must be possible for others to work on my behalf without me giving them my password. At least a full delegation to another user with another password to work on my behalf is necessary, for web pages which contain many actions, a divided delegation would be nice; for example, allowing others to enter data but not commit them.
Requirement: delegation to another user/password must be possible.
Screen size and browser type
I have computers with a browser – any request from a web service to change my computer or browser is inappropriate. It is the service's responsibility to adapt to my screen size. It is the most common size, sometimes a netbook, sometimes a portrait screen. I am not willing to install a new browser just to book an airline seat!
Requirement: construct web service to work on different screen sizes and with all regular browsers that support www standards.

Every web page communicates in its own terminology and often this is a quite strange jargon unintelligible or even misleading. Organizations and parts of organizations create quickly their own languages, completely obscure to outsiders. In a human communication the speaker and the listener can adapt and correct misunderstandings – on a web page, this is not possible.
Recommendation: check the clarity of the language with several outsiders; they must understand it without any help! Add help texts to every page where the same words are used in a context.

Web pages differ in how they expect inputs; problems are caused by numbers (decimal point or comma?), times and dates, but phone numbers can also cause trouble: are blanks allowed to group digits?
Requirement: Any input a human can interpret should be acceptable by the web page. If a specific format is expected, then the web page must show an example and not let the user guess, repeatedly, with increasing frustration.

Error tolerance
Errare humanum est – people make errors. A web application which assumes perfect inputs is not usable.
Requirement: The application must be tolerant for errors and give multiple ways for correcting them. It is required to be able to go back and change only one thing without entering everything again.

It is rare the moment I can work for a few minutes without interruption: the phone rings... Some web applications are set up to terminate a transaction if it is not completed quickly and after the interruption one has to start from scratch. If I come back after an interruption, or because I had to search for some detail to enter, it should be clear what is done and what needs to be done to progress.
Requirement: Save current state and allow interruptions.

Adherence to web interaction standards
Over the past years a set of rules has been established which are followed by nearly all applications: I can go back one page, pages open in a new browser window or in a tab, depending on my preferences. Requests for name, email etc. are marked such that the browser can fill them, etc. Many web services I have to use do not follow these standard ways of working and expect me to learn new tricks.
Requirement: adhere to the standards!

Post scriptum
I understand that programming a web page to follow these requirements may be more difficult; but why should (small) savings on the provider side justify large losses of time on my side?

No comments:

Post a Comment