| | 1 | = !BluePrint: Inline Help = |
| | 2 | [[TOC]] |
| | 3 | |
| | 4 | == Introduction == |
| | 5 | This will use a variety of formats to provide help to the user of the system. This includes tooltips that are linked with the fields in a form and guided tours which can be used to step a user through a particular process. |
| | 6 | |
| | 7 | Documentation using a variety of published media such as video, screenshots and text are difficult to maintain and with a system such as Sahana Eden which rapidly evolves these artifacts are soon out of date. Additionally, much of this material is tied to a template and as the different templates expand to meet user needs capturing the same screenshot for a new template become a chore. |
| | 8 | |
| | 9 | Inline help is independent of templates and will continue to work as the system evolves. Tours can be used to highlighted new material and help new users understand existing processes. |
| | 10 | |
| | 11 | The system currently has tooltips which are tied to the form, but these can't be used to describe how the fields come together to manage a particular workflow. |
| | 12 | |
| | 13 | == Stakeholders == |
| | 14 | This will be used by new users and made available to seasoned users who are trying a new workflow or have forgotten how to perform particular workflow. |
| | 15 | This will create more text to be managed by the system and so it will add an extra burden on the translators. |
| | 16 | This can be used to support remote training sessions. |
| | 17 | Developers can use this system to showcase a new feature. |
| | 18 | System documentors will have another system to maintain (although the maintenance cost of this will be lower than published material) |
| | 19 | |
| | 20 | == User Stories == |
| | 21 | A new user wants to know what they can use Sahana Eden for. |
| | 22 | A new user wants to know how to access and use a particular workflow. |
| | 23 | A seasoned user doesn't want to be hindered by paper clips attached to the system. |
| | 24 | A manager doesn't want to have to train every volunteer on how to use the system. |
| | 25 | A user want the inline help to be available in their mother tongue. |
| | 26 | |
| | 27 | == Requirements == |
| | 28 | Requirements for a guided tour |
| | 29 | === Functional === |
| | 30 | 1. Template functionality |
| | 31 | 1. When templates share the same functional interface then they should be able to share the same tour |
| | 32 | 1. When templates differ in functionality they should be able to modify an existing tour to reflect the different functionality |
| | 33 | 1. The template design |
| | 34 | 1. Tours should reflect the look and feel of the template |
| | 35 | 1. The text displayed in the tour |
| | 36 | 1. Should be integrated with the translation system |
| | 37 | 1. Should be decoupled from the code |
| | 38 | 1. A user who is not logged in |
| | 39 | 1. Should be able to start a tour to get some basic information about the instance |
| | 40 | 1. Should not be distracted by a tour if they are trying to log in |
| | 41 | 1. A user who is logged in |
| | 42 | 1. Should be able to start a tour where they left off |
| | 43 | 1. Should be able to see what tours are available |
| | 44 | 1. Should be able to see what tours they have completed |
| | 45 | 1. Should control the speed of the tour (active participation rather than passive observer) |
| | 46 | 1. An administrator of the system |
| | 47 | 1. Should be able to collect anonymized usage data of the tours. |
| | 48 | 1. Should be able to make a tour available |
| | 49 | 1. Should be able to block access to a tour |
| | 50 | === Non-functional === |
| | 51 | 1. When not running |
| | 52 | 1. they should not have any noticeable impact on the performance of the system. |
| | 53 | 1. When running |
| | 54 | 1. They should never expose information that the user would not normally have the permissions to see. |
| | 55 | 1. They should not prevent a user from aborting the tour and any point to perform their expected duties. |
| | 56 | === Interoperability === |
| | 57 | === Standards === |
| | 58 | === System Constraints === |
| | 59 | |
| | 60 | == Design == |
| | 61 | <Where relevant include alternative design options> |
| | 62 | === Data Model === |
| | 63 | (e.g. EER or class diagrams) |
| | 64 | === Workflows === |
| | 65 | <Diagrams or Pseudocode> |
| | 66 | === Site Map === |
| | 67 | <for User Interface solutions> |
| | 68 | === Wireframes === |
| | 69 | <for User Interface solutions> |
| | 70 | === Technologies === |
| | 71 | |
| | 72 | == Current Implementation == |
| | 73 | <Leave open for a list of existing implementation of this solution in Sahana Eden:> |
| | 74 | <*a brief description of the implementation (date/time, name, design options chosen)> |
| | 75 | <*a link to the code> |
| | 76 | <*list of deployments of the implementation> |
| | 77 | <*links to case studies> |
| | 78 | <*short analysis of achievements/problems> |
| | 79 | |
| | 80 | == Planned Implementation == |
| | 81 | <List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on> |
| | 82 | |
| | 83 | == Future Extensions == |
| | 84 | <List of features which could be included, but are outside of the scope of this extension> |
| | 85 | |
| | 86 | == Outstanding Questions == |
| | 87 | <Questions about the features or design that haven't been (and need to be) answered> |
| | 88 | |
| | 89 | == References == |
| | 90 | <Links to external resources> |
| | 91 | |
| | 92 | ---- |
| | 93 | BluePrint |
