user support

Issues –different types of support at different times –implementation and presentation both important –all need careful design Types of user support –quick reference, task specific help, full explanation, tutorial Provided by help and documentation –help - problem-oriented and specific –documentation - system-oriented and general –same design principles apply to both

Requirements Availability –continuous access concurrent to main application Accuracy and completeness –help matches and covers actual system behaviour Consistency –between different parts of the help system and paper documentation Robustness –correct error handling and predictable behaviour Flexibility –allows user to interact in a way appropriate to experience and task Unobtrusiveness –does not prevent the user continuing with work

Approaches to user support Command assistance –User requests help on particular command e.g., UNIX man, DOS help –Good for quick reference –Assumes user know what to look for Command prompts –Provide information about correct usage when an error occurs –Good for simple syntactic errors –Also assumes knowledge of the command

Approaches to user support (ctd) Context sensitive help –help request interpreted according to context in which it occurs. e.g. tooltips

On-line tutorials –user works through basics of application in a test environment. –can be useful but are often in flexible. On-line documentation –paper documentation is made available on computer. –continually available in common medium –can be difficult to browse –hypertext used to support browsing.

wizards and assistants wizards –task specific tool leads the user through task, step by step, using user’s answers to specific questions –example: resumé –useful for safe completion of complex or infrequent tasks –constrained task execution so limited flexibility –must allow user to go back

assistants –monitor user behaviour and offer contextual advice –can be irritating e.g. MS paperclip –must be under user control e.g. XP smart tags

Adaptive Help Systems Use knowledge of the context, individual user, task, domain and instruction to provide help adapted to user's needs. Unlike traditional "static" help systems that serve by request the same information to different users, AHS attempt to adapt to knowledge and goals of individual users offering information about most relevant aspects in a most relevant way.

user modeling typical : The designer has in mind a ‘typical’ user, and builds the interface accordingly Adaptable: the user is able to adapt his own environment to suit his preferences –browser or preferences that can adjust certain parameters of the system to the requirements of the user Adaptive –is to have the system construct and maintain a model of the user based on data gleaned from monitoring the user’s interaction.

Approaches to user modelling Quantification –The system recognizes a number of levels of expertise, which it will respond to in different ways. –The useris placed on one of these levels, and moves between them, based on a quantitative measure of his expertise at that time –Different activities are given weightings, andthe user is scored according to the weightings of the activities he takes part in. –If the score exceeds a certain threshold, the user is moved to a different expertise level

Stereotypes –the system classifies the user as a member of a known category of users or stereotype. –Not a real world true model –Stereotypes are based on user characteristics and may be simple, such as making a distinction between novice and expert users, –One is to use information such as command use and errors to categorize different types of user and then to use rules to identify the stereotype to which the user belongs.

Overlay –expert user, is constructed and the individual user’s behaviorcompared with it –The resulting user profile may represent either the commonality between the two models or the differences –Not only is the system aware of what the user is doing, but it also has a representation of optimal behavior.

There are four main groups of techniques used in knowledge representation for adaptive help systems: –rule based – frame based –network based – example based

Rule-based techniques Knowledge is represented as a set of rules and facts, which are interpreted using some inference mechanism Rule-based techniques can be used in relatively large domains and can represent actions to perform as well as knowledge for inference.

IF command is EDIT file1 AND last command is COMPILE file1 THEN task is DEBUG action is describe automatic debugger

Frame-based techniques Frame-based systems are used to represent commonly occurring situations and default knowledge. A frame is a structure that contains labeled slots, representing related features. Each slot can be assigned a value or alternatively be given a default value. User input is matched against the frame values and a successful match may cause some action to be taken.

Network-based techniques Networks represent knowledge about the user and system in terms of relationships between facts One of the most common examples is the semantic network This makes it a relatively efficient representation scheme and is useful for linking information clearly

Example-based techniques Example-based techniques represent knowledge implicitly within a decision structure of a classification system. This may be a decision tree The decision structure is constructed automatically based on examples presented to the classifier. The classifiers effectively detect recurrent features within the examples and are able to use these to classify other input

Problems with knowledge representation and modelling knowledge acquisition resources interpretation of user behaviour

Knowledge representation Advisory strategy involves choosing the correct style of advice for a given situation. e.g. reminder, tutorial, etc. few intelligent help systems model advisory strategy, but choice of strategy is still important.

Issues in adaptive help Initiative –does the user retain control or can the system direct the interaction? –can the system interrupt the user to offer help? Effect –what is going to be adapted and what information is needed to do this? –only model what is needed. Scope –is modelling at application or system level? –latter more complex e.g. expertise varies between applications.

Designing user support User support is not an `add on’ –should be designed integrally with the system. Concentrate on content and context of help rather than technological issues.

Effective presentation of help Help screens and documentation should be designed in much the same way as an interface should be designed, taking into account the capabilities and task requirements of the user Help and tutorial material should be written in clear, familiar language, avoiding jargon as much as possible. paper manuals and tutorials exist, the terminology should be consistent between these and the online support material

help system should tell the user how to use the system rather than simply describing the system To close the window, click on the box in the top right-hand corner of the window. rather than Windows can be closed by clicking on the box in the top right-hand corner of the window

Presentation issues How is help requested? –command, button, function (on/off), separate application How is help displayed? –new window, whole screen, split screen, –pop-up boxes, hint icons Effective presentation requires –clear, familiar, consistent language –instructional rather than descriptive language –avoidance of blocks of text –clear indication of summary and example information

Writing User Guide

User Guides Purpose is to allow a user to install, use and troubleshoot a piece of software Some questions to think of when writing a user guide: –Who is your audience, who are your users? Are there different groups of users? What level of technical expertise do they have? How much time will they invest in reading the UG? Where/how will they read the UG? Is this product an upgrade to an existing product? –What tasks are the users typically going to perform with the software? Will different groups of users perform different tasks?

User Guides There are many online resources to help –See reference list Generally, UGs employ the following style elements: –Headings and Lists: help user find information quickly –Special Notices: warnings, cautions or alerts, to alert readers to important points –Instructional Design: task-oriented headings, tasks in numbered lists, “chunking” together related tasks –Graphics: screenshots and pictures, before and after views –Tables: present data in an easy-to-access form, good for look-up information like OS types or minimum system requirements –Highlighting: can be useful if used consistently and sparingly

Components of a UG

Tips on Content Use direct commands to the user: –“Click this”; and “you”, not “the user” Explain the problem being solved: don’t just include a detailed description of features, explain why a user might want them Present the concepts, not just the features: if users understand the underlying concept of the software, they will more easily understand the features Give them more: manuals cover the task domain, not just the software

Tips on the Writing Process Ensure the writers are part of the software design team Write the user manual while you are developing the software –Don’t try and write it quickly before a release deadline Make sure the writers have access to the software, have used the software, and are using the software while they write Consider the needs of disabled users –Low vision, colour blindness, loss of acuity Your boss can’t see as well as you can!

Designing a Readable User Manual Choose a few readable fonts. – Choosing only a small number of fonts that look good together is the best way to achieve this goal Give some thought to the layout. –you need to decide where everything goes on the pages –Allow reasonably margins on all sides, with extra space on the edges that will be bound together.

References User Guide Tutorial – User Guide – Wikipedia – – Tips for Writing User Manuals (very slow if there) – – How to Publish a Great User Manual – –

Thank You