1 / 38

user support

user support. user support. Issues di ff erent types of support at different times implementation and presentation both important all need careful design Types of user support quick r eference, task speci fi c help, full e x planation, tutorial Provided by help and documentation

reed-lyons
Télécharger la présentation

user support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. user support

  2. 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 andgeneral • same design principles apply toboth

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

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

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

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

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

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

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

  10. 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 email 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.

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

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

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

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

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

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

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

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

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

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

  21. Knowledge representationAdvisory 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.

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

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

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

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

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

  27. Writing User Guide

  28. 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?

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

  30. Components of a UG

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

  32. 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!

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

  34. References • User Guide Tutorial • http://www.klariti.com/technical-writing/User-Guides-Tutorial.shtml • •User Guide – Wikipedia • http://en.wikipedia.org/wiki/User_guide • •Tips for Writing User Manuals (very slow if there) • http://www.userfocus.co.uk/articles/usermanuals.html • •How to Publish a Great User Manual • http://www.asktog.com/columns/017ManualWriting.html

  35. Thank You

More Related