|
|
| (11 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| tictric AT jabber.ccc.de if you really need to contact me directly :) | | tictric AT jabber.ccc.de if you really need to contact me directly :) |
|
| |
|
| | | http://techbase.kde.org/Projects/Documentation/KDE4/kdepim |
| == A "Nanny" for our time problems ==
| |
| | |
| Having two kids, I discovered that they tend to spend more then sufficient time in front of our computer. Not that I don't appreciate their efforts to learn to use this complex worktool, but I think there's other important things to learn too.
| |
| | |
| In short, I want to give them sufficient time per week or month to make themselves even more familiar with our workstation but I don't want to stay guard all the time that they don't sit in front of it longer than allowed (and good for them). Unfortunately there's no tool with GUI so far, that I could get hold of that would assist me managing the time my kids may spend with processing data.
| |
| | |
| Therefore I propose (or rather put up to discussion) the development of '''Nanny'''.
| |
| | |
| = Project User Research Profile =
| |
| | |
| Kim and Joe've got two children. Jil and Moe. Jil goes to primary, Moe to secondary school. They, like their parents, love to work (play) with the computer in their home office. They show a tendency to sit rather longer than shorter in front of the screen and this causes trouble because Kim and Joe think their minds are too immature for a constant exposition to this technique. And also there's more important skills for children to master and be it only to jump and run and cycle and what not.
| |
| | |
| So Kim fires up the workstation and logs into her account on a KDE-Desktop. In system-settings, on the ''advanced'' tab she finds a button for ''Nanny''. She opens the settings dialog, activates administrator mode and selects Jils user account.
| |
| | |
| Now she can set a time limit for Jil in hours and a time period the time credit is valid for in days, weeks or months. Since Jil almost only uses the computer only for playing rather silly games, like Kim thinks, Kim decides that Jil shouldn't spend more than 2 hours a week in front of the computer and restricts the time per session to 30 minutes.
| |
| | |
| Moe, being older, not only plays games but also uses the computer for his homework and emails with his friends. So Kim and Joe think that he should have more time, like 1 hour a day maximum on the average. Now that Moe is already a ''big kid'', he should also learn to household with his time credit as he sees fit and so he gets 30 hours per month which he has to
| |
| | |
| == Who is the application for? ==
| |
| | |
| * List of types (groups) of users
| |
| * User groups can be organized based on any type of dimension
| |
| * Some groups may be broken down in to sub groups
| |
| | |
| === (Who is the application ''not'' for) ===
| |
| | |
| * Sometimes it is easy to identify who the application is '''not''' for
| |
| * This can help keep the scope of the project under control
| |
| | |
| === Sample User Profiles ===
| |
| | |
| User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know.
| |
| | |
| == What kinds of tasks will they complete ==
| |
| | |
| * Set a time credit for each targeted ''human'' user account with a valid shell per day/week/month.
| |
| * Optionally set during which hours of the day (maybe restricted to certain days of the week) using the computer will be possible.
| |
| * Easy setting of exeptions when necessary (like: Okay, today you may finish your task without further debit to your time credit).
| |
| *
| |
| <br />
| |
| ----
| |
| | |
| * List of common tasks users will complete
| |
| * This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed
| |
| * Include functionality that is planned but not yet implemented to help keep the future in focus
| |
| | |
| === (What kinds of functionality will the application ''not'' support) ===
| |
| | |
| * List tasks or functionality the application will not address
| |
| * Sometimes it is useful to list this unintended functionality to help keep the scope of the application
| |
| * For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary
| |
| | |
| === Sample Use Scenarios and Cases ===
| |
| | |
| Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task ''independent'' of how they would complete it within the application.
| |
| | |
| Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it.
| |
| | |
| == Environment Conditions & Requirements ==
| |
| | |
| * List of environmental conditions for the user or the application to consider
| |
| * For example, an Internet-capable application would require an Internet connection
| |
| | |
| == More Information ==
| |
| | |
| [http://www.usability.gov/analyze/personas.html Short introduction to user personas on Usability.gov]
| |
| | |
| [http://www.boxesandarrows.com/view/making_personas_more_powerful_details_to_drive_strategic_and_tactical_design In-depth discussion about creating personas on Boxes and Arrows]
| |
