1. Help and Documentation

2. Overview zUsers require different types of support at different times but all user support should fulfil some basic requirements. zImplementation and presentation both need to be considered in designing user support. zTypes of user support yquick reference ytask specific help yfull explanation ytutorial

3. Overview zThese may be provided by help and/or documentation yhelp xproblem-oriented and specific ydocumentation xsystem-oriented and general xThe same design principles apply to both

4. Requirements zAvailability ycontinuous access concurrent to main application. zAccuracy and completeness yhelp matches actual system behaviour and covers all aspects of system behaviour. zConsistency ydifferent parts of the help system and any paper documentation are consistent in content, terminology and presentation.

5. Requirements zRobustness ycorrect error handling and predictable behaviour. zFlexibility yallows user to interact in a way appropriate to experience and task. zUnobtrusiveness ydoes not prevent the user continuing with work nor interfere with application

6. Approaches to user support zCommand assistance yUser requests help on particular command. ye.g., UNIX man, DOS help. yGood for quick reference. yAssumes user know what to look for. zCommand prompts yProvide information about correct usage when an error occurs. yGood for simple syntactic errors. yAlso assumes knowledge of the command.

7. Approaches to user support zContext sensitive help yHelp request interpreted according to context in which it occurs. ye.g., Spy, Balloons Help. zOn-line tutorials yUser works through basics of application in a test environment. yCan be useful but are often inflexible. zOn-line documentation yPaper documentation is made available on computer. yContinually available in common medium but can be difficult to browse. yHypertext used to support browsing

8. Intelligent Help zUse knowledge of the individual user, task, domain and instruction to provide help adapted to user's needs. zProblems yknowledge requirements considerable ywho has control of the interaction? ywhat should be adapted? ywhat is the scope of the adaptation?

9. Knowledge representation zUser modelling yAll help systems have a model of the user xsingle, generic user (non-intelligent) xuser- configured model (adaptable) xsystem-configure model (adaptive) yApproaches xquantification user moves between levels of expertise based on quantitative measure of what he knows. xstereotypes user is classified into a particular category. xoverlay an idealised model of expert use is constructed and actual use compared to it. Model may contain the commonality between these two or the difference. Special case: user behaviour compared to known error catalogue

10. Knowledge representation zDomain and task modelling yCovers xcommon errors and tasks xcurrent task yUsually involves analysis of command sequences. yProblems xrepresenting tasks xinterleaved tasks xuser intention zAdvisory strategy yInvolves choosing the correct style of advice for a given situation. E.g. reminder, tutorial, etc. yFew intelligent help systems model advisory strategy but choice of strategy is still important

11. Knowledge representation zTechniques for knowledge representation yrule based xknowledge presented as rules and facts interpreted using inference mechanism. E.g. logic, production rules. Can be used in relatively large domains. yframe based xknowledge stored in structures, each having slots which can be filled. Useful for a small domain. ynetwork based xknowledge represented as relationships between facts. E.g. semantic network. Can be used to link frames. yexample based xknowledge represented implicitly within decision structure. Trained to classify rather than programmed with rules. Requires little knowledge acquisition

12. Knowledge representation zProblems with intelligent help systems yknowledge acquisition yresources yinterpretation of user behaviour

13. Issues in intelligent help systems zinitiative ydoes the user retain control or can the system direct the interaction? Can the system interrupt the user to offer help? zeffect ywhat is going to be adapted and what information is needed to do this? Only model what is needed. zscope yis modelling at application or system level? Latter more complex. E.g. expertise varies between applications

14. Designing user support zUser support is not an `add on' yit should be designed integrally with the system. zShould concentrate on content and context of help rather than technological issues. zPresentation issues yHow is help requested? xcommand xbutton xfunction (on/off) xseparate application

15. Designing user support zHow is help displayed? ynew window ywhole screen ysplit screen ypop-up boxes yhint icons zEffective presentation requires yclear, familiar, consistent language yinstructional rather than descriptive ylanguage yavoidance of blocks of text yclear indication of summary and example information

16. Designing user support zImplementation issues yIs help xoperating system command xmeta command xapplication yWhat resources are available? xscreen space xmemory capacity xspeed

17. Designing user support zImplementation issues yStructure of help data xsingle file xfile hierarchy xdatabase yConsiderations xflexibility and extensibility xhard copy xbrowsing