You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Scenario

Rachel is the new housing manager of the dorm Dartmoor.  She is taking over from Greg, who is moving on to better and brighter things, but unfortunately was not very organized, and did have a system of organization.  Instead, he kept his data scattered among Excel spreadsheets and pieces of paper.  Rachel prefers to keep things organized, so she decided to use HManager.

The first thing Rachel does is start collecting all the data left over from Michael, which includes all the past and current projects, as well as how much money that took, how much money she has for the next year.  She already has the residents' information (name, age, email) in a spreadsheet and a email list that contains all the students.

She receives requests from the students, and decides if the requests need to be worked on.  When she does so, she can (optionally) email everyone in the building that she is going to take on the project.  Once she has an estimate on when the projects can be done, and how much money each project will take, she updates the projects with that data, and wants to be able to keep track of dates and the project to "current" status.  At this point, she thinks about sending an emails to broadcast out to the residents to update them on what she is doing.  She wants to be able to keep track of projects that are completed, and be able to view past projects, and another email broadcast can be made.

Designs

Design 1

Rachel starts off with creating a new account on HManager, as Greg did not have an account.  She clicks start.  Clicking start brings her to the startup page, which includes a place to input a house name, as well as a choice to input old data (from Greg) or simply starting anew.  Since she wishes to keep track of everything that has happened, she clicks Input old info.

The startup page already includes the name of the house, and Rachel starts off with inputting old tasks that Greg has left.  The tasks require a task name and a description, and if the task has been completed (or is in the process of completion), she also writes in a date of completion and an amount of money spent.  When she is finished with the tasks, she clicks submit, which saves the data, and the next section, the budget / year, is revealed.  This section is optional.  Rachel does not know the old budget, so only puts down her current budget, and presses submit.  At that point, she realizes that she forgot a task, and mis-typed the budget.  She goes back and corrects the details, then presses either submit button.  She then adds a few of the requested tasks that she will be looking into, and presses submit.  A popup button comes up, and she clicks no to check her work.  Finding no problems, she presses submit again, then yes on the popup button.

She then comes to a page to input the residents, which she does, then presses done.  

This concludes the start up, and she is brought to the startup page.  She sees the tasks that are up already, and notices that there is a task that was moved up by the contracted company, and she clicks the task, which brings up the details in a popup that blocks the screen.  She then clicks edit, which changes the popup to another screen that allows her to edit the details.  She changes the date, and then clicks save.  (On the bottom, accidentally forgot to draw it).  This brings her back to the main page.  She then schedules a previously unscheduled (or future) task in the same way, and decides to email the house to let them know that the task has been scheduled by checking the box that says email.

At a later date, she logs in again, and this time types in the house name.  That brings her directly to the front page.  She needs to delete a resident, and add a new one, and therefore clicks edit residents.  She checks the delete button on that resident, and clicks add resident, and types in the information.  Once that is completed, she clicks submit.  

She is brought back to the main page, and decides to add a new task, based on the emails she gets from the residents.  She creates a new task, and leaves the date and amount of money spent blank, as it is a future task.  

Analysis

  • Learnability
    • Good: The buttons are labeled, and self explanatory.  For the mass input stage, because the next sections are present but grayed out, it should be obvious that the user is meant to press submit to continue.  Every other section either allows people to return without changing anything, or to change something and submit, with clear buttons to do so.
    • Bad: If someone mistypes the name of the house on the account login, they will not receive any feedback.  
  • Efficiency
    • Good: Most of the web site is rather efficient and streamlined, allowing for quick input of tasks, and quick editing of tasks.  
    • Bad: You cannot mass-delete tasks.  The initial start-up is time consuming, as is adding multiple new tasks at once.  The web site is designed for a streamlined house manager, who updates the web site as new problems arise.
  • Safety
    • Good: This system is relatively safe, as most of the aspects can be edited, including the budget, residents, and all tasks, scheduled and not.  Most actions are reversible, and you can check your work on the mass-input stage before continuing.
    • Bad: The only problems that may occur are in misspelling the name of the house, which, in login, simply does not log you in, or in creating a new account for the house, in which case, you can simply discard that web site and try again, as the account is not actually created until you first press the submit button.  The other area which may cause concern is the editing of residents.  The only way to change a resident's information is by deleting the resident, and adding the resident again.  

Design 2

text/images

Analysis

Text

Design 3

text/images

Analysis

Text

  • No labels