Archive for the ‘Metalink’ tag
Meaningless Support
Grrrrgh. I can sort of cope with the oracle.com technet homepage randomly appearing in Chinese. That’s just annoying. On the other hand I really do want http://support.oracle.com to actually work reliably and sensibly. Once again it didn’t for me today. Specifically I was trying to update an SR – I entered the SR update text, pressed ” Send” (why not Update?) and was greeted with a non-modal and yet non ignorable error dialog
Unable to perform “Update SR” operation because of the following error: “BusinessException thrown from Update Step : updateSR() at 2010-12-13 07:34:21.719 CST”.
I of course can do nothing about this. Which in turn means there is no point showing me the message in this form. I did retry the submit and got the same result. At this point I logged into http://supporthtml.oracle.com (yes I needed another round through the Single Sign-ON loop – Oracle seem to think SSO means Same Sign On) pasted the update text into my SR and got the SR updated.
All of this got me thinking about Jakob Nielson’s rules of thumb for user interfaces . I’m afraid it appears the designers at Oracle Support haven’t read them, or else don’t consider them useful. Let’s run through them.
- Visibility of system status
- The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Well here I suppose you could argue that Oracle is at least giving me feedback – although it isn’t actually telling me what is going on – I can at least conclude that my SR never got updated.
- Match between system and the real world
- The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
This is just a straight fail. The language is meaningless and certainly doesn’t match users usage: In addition when this occurs the error message appears in a non-intuitive place out of context of the user action.
- User control and freedom
- Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Another fail. In general MOS neither supports undo/redo nor even normal navigation keys – eg backspace. .
- Consistency and standards
- Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Note that I said “in general above” Sometimes MOS supports the browser standard navigation keys. Sometimes it doesn’t.
- Error prevention
- Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
I think this one is actually somewhat unrealistic – I don’t like the error message, but I do recognize that unexpected errors occur.
- Recognition rather than recall
- Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Hmmm. Another fail. When logging an SR without a configuration (as many of our clients require) then the same information is often asked for repeatedly – sometimes more than once (eg version of software, version of database, version of product) on the same page.
- Flexibility and efficiency of use
- Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Non-existent here.
- Aesthetic and minimalist design
- Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Well it’s certainly true that my dialogue was minimalist…
- Help users recognize, diagnose, and recover from errors
- Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Not even a “please retry the update” and an error message full of codes. Another Fail.
- Help and documentation
- Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
I’ll pass on this one since it’s been a while since I investigated the flash MOS help.
Overall no better than 50% Oracle. Not good enough. Not by a long way. Worth noting as well that the http://supporthtml.oracle.com interface to the same application would probably score at least 75%.