Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 16 user support. Today’s Outline Users have different requirements for support at different times. User support should be:  available but unobtrusive.

Similar presentations


Presentation on theme: "Lecture 16 user support. Today’s Outline Users have different requirements for support at different times. User support should be:  available but unobtrusive."— Presentation transcript:

1 Lecture 16 user support

2 Today’s Outline Users have different requirements for support at different times. User support should be:  available but unobtrusive  accurate and robust  consistent and flexible.

3 Today’s Outline User support comes in a number of styles:  command-based methods  context-sensitive help  tutorial help  online documentation  wizards and assistants  adaptive help.

4 Today’s Outline Design of user support must take account of:  presentation issues  implementation issues.

5 Overview Users require different types of support at different times. There are four main types of assistance that users require:  Quick reference  Task-specific help  Full explanation  Tutorial.

6 Quick Reference Quick reference is used primarily as a reminder to the user of the details of tools he is basically familiar with and has used before. It may, for example, be used to find a particular command option, or to remind the user of the syntax of the command.

7 Quick Reference -- Telnet

8 Quick Reference –Word 2007 Screen

9 Task Specific Help Task-specific help is required when the user has encountered a problem in performing a particular task or when he is uncertain how to apply the tool to his particular problem. The help that is offered is directly related to what is being done.

10 Task Specific Help Example

11 Task Specific Help --PowerP

12 Full Explanation The more experienced or inquisitive user may require a full explanation of a tool or command to enable him to understand it more fully. This explanation will almost certainly include information that the user does not need at that time.

13 Full Explanation – Example In Unix, most programs, and many protocols, functions, and file formats, have accompanying manuals. With the man command, you can retrieve the information in the manual and display it as text output on your screen.

14 man --unix

15 Tutorial This is particularly aimed at new users of a tool and provides step-by-step instruction (perhaps by working through examples) of how to use the tool.

16 Tutorial –Mail Merge

17 Types of support Four types are complementary Together they support range of points in user’s experience with system Each type may be on-line and off-line (documentation)  should be consistent in content  presentation medium may have impact on design  general principles for both

18 Requirements of User Support Designing a good help system needs to understand some features that help system should have. Using all of these help features is not compulsory for a system.

19 Requirements Features 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

20 Availability The user needs to be able to access help at any time during his interaction with the system.  He should not have to quit the application he is working on in order to open the help application.

21 Availability This is a problem for non-windowed systems if the help system is independent of the application that is running. However, in windowed systems there is no reason why a help facility should not be available constantly, at the press of a button.

22 Accuracy and completeness It may seem obvious to state that the assistance provided should be accurate and complete.  if the assistance provided proves not to match the actual behavior of the system the user will, at best, become disillusioned with the help facilities, and, at worst, get into difficulties. The completeness also is very important.

23 Consistency Users require different types of help for different purposes.  This implies that a help system may incorporate a number of parts.  The help provided by each of these must be consistent with all the others and within itself Online help should also be consistent with paper documentation.  It should be consistent in terms of content, terminology and style of presentation.

24 Robustness Help systems are often used by people who are in difficulty, perhaps because the system is behaving unexpectedly or has failed altogether. It is important then that the help system itself should be robust, both by correct error handling and predictable behavior.

25 Flexibility Many help systems are rigid in that they will produce the same help message regardless of the expertise of the person seeking help or the context in which they are working. A flexible help system will allow each user to interact with it in a way appropriate to his needs.

26 Unobtrusiveness The help system should not prevent the user from continuing with normal work, nor should it interfere with the user’s application.

27 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 This type of help is simple and efficient if the user knows what he wants to know about and is seeking either a reminder or more detailed information. However, it assumes that the user does know what he is looking for, which is often not the case.

28 Approaches to user support.. Command prompts  Provide information about correct usage when an error occurs  Good for simple syntactic errors  Also assumes knowledge of the command Another form of command prompting, which is not specifically intended to provide help but which supports the user to a limited degree, is the use of menus and selectable icons.

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

30 Approaches to user support On-line tutorials  user works through basics of application in a test environment.  can be useful but are often inflexible. 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.

31 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

32 Approaches to User Support Assistants  monitor user behavior and offer suggestions  unobtrusive and under user control  ‘Clippy’ not unobtrusive, suggestions inappropriate  MS Office smart tags appear near object of interest

33

34 Adaptive Help In any large or complex computer system, users will be familiar with a subset of the available functionality, demonstrating expertise in some applications and having no experience with others, even to the point of being unaware of their existence.

35 Adaptive Help In addition, different users will have different needs and levels of understanding. Adaptive help systems attempt to address these problems.  Adapting the help that they provide to the individual user who is making the request and by actively suggesting alternative courses of action of which the user may not be aware.

36 Intelligent Help: Adaptive Help Systems Use knowledge of the context, individual user, task, domain and instruction to provide help adapted to user's needs. Problems  knowledge requirements considerable  who has control of the interaction?  what should be adapted?  what is the scope of the adaptation?

37 Knowledge representation: User modeling User modeling  single, generic user (non-intelligent)  user-configured model (adaptable)  system-configured model (adaptive) Static help systems can’t address all user differences. Adaptive help systems model users, refining the model by monitoring a user’s activities, and present help tailored to the particular user.

38 Approaches to User modeling Quantification  user moves between levels of expertise based on quantitative measure of what he knows Move from level 1 to level 2 if system has been used more than twice commands x and y used effectively help has not been accessed in this session system has been used in last 5 days

39 Approaches to User modeling Stereotypes  user is classified into a particular category Overlay  an idealized model of expert use is constructed  actual use compared to it  can determine how far user is from optimal use  can suggest optimal use strategies

40 Knowledge representation: Domain and Task Modeling Usually involves analysis of command sequences  Assistants and agents Covers  common errors and tasks  command sequences for current task Problems  interleaved tasks  user intention

41 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.

42 Techniques for Knowledge representation Rule-based Frame-based Network-based Example-based

43 Techniques for Knowledge Representation Rule-based  knowledge represented as rules  facts interpreted using inference (logic)  used in large domains IF command is EDIT file 1 AND last command is COMPILE file 1 THEN task is DEBUG action is describe automatic debugger

44 Techniques for Knowledge Representation Frame-based  knowledge stored in structure that contains labeled slots  slot has default value  useful in small domains User Expertise level: novice Command: EDIT file 1 Last command: COMPILE file 1 Errors this session: 6 Action: describe automatic debugger

45 Techniques for Knowledge Representation Network-based  knowledge represented as relationships between facts  can link frame-based representations CC is and instance of COMPILE COMPILE is a command COMPILE is related to DEBUG COMPILE is related to EDIT Automatic debugger facilitates DEBUG

46 Techniques for Knowledge Representation Example-based  knowledge represented within decision structure of classification system  trained to classify rather than programmed with rules (AI techniques)  detects recurrent features EDIT file 1 COMPILE file 1  trains for task debug

47 Problems with knowledge representation and modeling Knowledge difficult to elicit  especially if domain expert not available  variability of users  difficult to ensure completeness and correctness Interpretation of information  during interaction all we have are logs  do not have user’s intent or goal

48 Designing User Support User support is not an ‘add on’ - it should be designed integrally with system. Should concentrate on content and context of help rather than technological issues There are presentation issues and implementation issues

49 Designing User Support : Presentation issues How is help requested?  Command  button  function (on/off)  separate application How is help displayed?  New window  whole screen or split screen  pop-up box  hint icons

50 Designing User Support : Presentation issues Effective presentation requires  clear, familiar, consistent language  instructional rather than descriptive language  avoid of blocks of text  summary and example

51 Designing User Support Systems : Implementation Issues Is help  OS command  meta command  application What resources are available  screen space  memory capacity  speed

52 Designing User Support Systems: Implementation Issues Structure of help data  single file  file hierarchy  database Consider  flexibility and extensibility  hard copy  browsing

53 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.

54 Summary Users require different support at different times User support should be:  available but unobtrusive  accurate and robust  consistent and flexible User support comes in a number of styles:  command-based, context sensitive help  tutorial, online doc, wizards and assistants  adaptive help

55 Summary Design of user support must take account of:  presentation and implementation issues


Download ppt "Lecture 16 user support. Today’s Outline Users have different requirements for support at different times. User support should be:  available but unobtrusive."

Similar presentations


Ads by Google