User Control

User can cancel any operation, clear exit points, browser compatibility, Languages, Online help/user guides, user feedback etc


1) Users often choose application functions by mistake and need a clearly marked “emergency exit” to leave the unwanted state without having to go though an extended process. The application should support “undo” and “redo” functions.

· Allow the user to control where to start and when to finish
· Allow the user to control the interaction
· Support multiple paths
· Support “Undo” and “Redo”
· Provide clearly marked exits.

2) The application should always keep users informed about what is going on by providing appropriate feedback within reasonable time.

· Keep users informed about what’s happening
· Provide appropriate feedback within a reasonable time
· Keep users oriented and clear about where they are in the system or where they are up to in a process.

3) 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.

· Provide on-line help and guidance
· Make it easy to search
· Keep it relatively short
· Make it available in context
· List concrete steps to be carried out.
· Mandatory fields are not indicated on the order form.

4) Make the user smart
Users want to feel that they are in control of the computer’s activities. Good interface design features and embedded performance support tools will provide users with the information they need to make decisions regarding navigational and ‘next step’ issues.

· Build a consistent model in user’s mind
· Provide good mapping between the task and the system
· Provide clear navigation clues.
· Reduce the user’s cognitive load (memory, calculating, understanding relationships)
· Create a feeling of progress and achievement.

5) Match between the system and the real world
The system should speak the users’ language, using words, phrases and concepts familiar to the user, rather than systems-oriented terms. The conventions of the real world should be followed, making information appear in a natural and logical order.

· Provide an intuitive visual layout
· Information should appear in a natural and logical order
· Use words, phrases and concepts familiar to the user
· Concepts and processes mirror what the user is familiar with.

6) Consistency and standards
Users should not have to wonder whether different words, objects, operations or behaviors mean the same thing in different parts of the application.
· Follow platform conventions
· Conform to any existing processes or procedures
· Be consistent across the system (words, objects, operations, behaviours).

7) Visibility of system status
The application should always keep users informed about what is going on by providing appropriate feedback within reasonable time.

· Keep users informed about what’s happening
· Provide appropriate feedback within a reasonable time
· Keep users oriented and clear about where they are in the system or where they are up to in a process.

8) Error prevention
Does the system allow the user to make unnecessary errors easily? Has it been optimized to reduce casual errors? Although good error messages are important, even better is a careful design, which prevents a problem occurring in the first place.

· Avoid situations where errors are likely to occur. Errors should be predicted
· Provide only appropriate choices
· Warn users of potential problems before they take action
· Ask for confirmation of potential destructive actions. Use a message that clearly warns the user of the consequences of the requested action
· Provide a way to cancel the command.

9) Error recovery
Error messages should be expressed in plain language rather than codes, precisely indicating the nature of the problem (what and where) and constructively suggesting a solution (how to fix).

· Make actions reversible
· Allow users to backtrack by providing ‘undo’ and ‘backup’ functions
· Allow users to return to the same place in the same state.
· Express error messages in plain language, precisely indicating the nature of the problem and constructively suggesting a solution.

Many unnecessary errors occur.
For example:
· If customers order ‘out-of-stock’ items, an error occurs when they attempt to conclude the payment.
· If a search returns zero hits, an error message is returned.
· The credit card number field does not allow spaces.

Examine all error messages with a view to reducing the possibility of their occurring. Resolving this issue may require Further design effort.

No help is available for error messages.

If an error cannot be resolved during the interaction, at least provide contact details so the customer can report the Issue for resolution.

Error messages do not describe what action is necessary.
For example:
‘Search returned zero items’
Examine all error messages with a view to improving the wording and advice given

Error messages do not always provide a clear exit point
For example, the ‘Search returned zero items’ has no exit—the Customer must use ‘Back’ on the browser to back out.
Provide clear exit points (at least to the Home and Feedback pages) on all error messages.

Browser Compatibility

My opinion is that the best way to create and test your pages is to create them in the most current, standards-compliant browser you can (this would be Firefox) and then tweak your pages for Internet.

HTML Features that may fail to work if your visitors are using a different browser:

There are many interesting features which you can find for your website. They will produce effects which are exciting, colorful, amusing, and grab the surfer to look further at your website. But unless the surfer is using exactly:

· The same browser,
· The same set-up for the same fonts and colors,
· With the same Plug-In options,
· Using the same display size and resolution

Your beautiful gimmicks may not be seen. Or may even destroy the presentation of the rest of the material. Therefore the rule should be:

Only use features that add to the presentation, and which leave the basic material on the page still working, however it is viewed.

And to be specific

· No cookies
· No sound
· No animation
· No Java
· No JavaScript
· No DHTML
· No background images
· No Plugins
· No downloadable fonts

Sound and Movies
(Many users will not have implemented the plug-ins for these.)
· If you are using multi-media you should warn the user, and also ensure that the electronically deprived have something to look at instead.
· Shockwave in tables can cause problems in NS2.

Images

(It is said that 60% of your visitors surf with the graphics turned off.)
· Each image should have an ALT= clause to mark its place.
· Users of Lynx browsers cannot handle graphics and if there is no ALT="" clause are presented with an ONLINE message.
· Images should always have WIDTH= and HEIGHT= clauses to allow the space to be assigned while loading the remainder of the text to be displayed.
· Mosaic and OS/2-Warp will not scale images.
produces inconsistent results.


JAVA and JavaScript
· Some browsers may not have either of these languages. Do not rely on them working.
· Internet Explorer 2 does not handle Javascript, and IE3 handles Javascript in slightly different ways
· Javascript 1.1 works only with NS3.
· JAVA will not work if any of the images on that page do not have WIDTH= and HEIGHT=

Forms Submit using mailto:
· The mailto: statement requires that the browser is properly set up to handle mail
· Early versions of Internet Explorer do not have its own mailer and relies on invoking the surfers own mail package, which is on his own server. It follows that the forms - mailto feature does not work on Explorer, and merely displays a blank mail form.
· You can use CGI scripts on your own server to handle this consistently if you must have it.
· The results transmitted from a form can be in a different order depending on the browser, so each item should have its own identification.

Frames
· Several browsers will not handle frames. The heading frame has provision for a message or material to be displayed when accessed by browsers which cannot handle them.
· Visitors who are using 640x480 displays may find the frames window rather small. Or even very small...

Tables
· It is probably now safe to assume that all browsers will handle tables.
· Empty table cells will probably be ignored; you can put in a space character to avoid this.
· Border colors and table colors and backgrounds may not work in early versions of Netscape.
may not work.


Lists

usually does not work

Blinking and Marquee
· Netscape is alone in implementing BLINK, which was originally included for internal error messages.
· Explorer is alone in handling Marquee moving text; other browsers will display an un-moving image.


pairs

· There is growing concern that the most recent browsers will not be as tolerant of commands which are not closed with We shall have to watch this one.

Please see the Following Link to check which all Technologies, Javascript, Protocol, Image formats etc are supported by different browsers:


http://en.wikipedia.org/wiki/Comparison_of_web_browsers