GR1 - Task analysis
User analysis
We are targeting MIT undergraduate students, all of whom eat. A major division exists in our user population between students who are on a meal plan and those who are not. Each of these two groups have their own subgroups. For those on a meal plan, there are students who are on the MIT House Dining plan (where a certain number of meals are provided every day in certain dorms), and there are those who are on the meal plan of some living group (like a fraternity, sorority, or independent living group). Among the students who are not on a meal plan, there are those students who cook regularly and those who eat out regularly.
Task analysis
I. Manage presence on website
Subtasks: (see below)* Create an account
- Delete an account
--> Create an account
Goal: Allow users to use the site and have data privately associated with them
Frequency: one time only
Precondition: be MIT student, have email address
Subtasks: * Decide to use this meal-planning service - Enter required information
- Submit information
Possible errors: * User incorrectly enters some information
--> Delete an account
Goal: Delete all personal information from the site
Frequency: zero to one time
Precondition: have an account
Subtasks:* Identify self
- Verify desire to delete account
Possible errors: * Accidentally delete account
II. Identify self
Goal: Be able to gain access to features of the site and own personal information
Frequency: daily
Precondition: have an account
Subtasks: * Enter information to prove identity
- Submit information
Possible errors: * User submits incorrect identification
- User forgets own identification
Other possible problems: * Someone gains improper access to an account (hacking), and user has to recover account
III. Manage personal nutrition
Global precondition: user has an account, and has identified self
Subtasks: (see below)* Record food in possession (optional)
- Record consumed food
- View food history
- View food statistics
--> Record food in possession (optional)
Goal: Keep track of food items in user’s possession. Users can pick items from this list to speed up updating daily food records. (see “Record consumed food” below)
Frequency: weekly or twice a week
Precondition: physically have food in possession
Subtasks:* Add food items to a list
- Delete food from list
- View list
Possible errors:* User enters incorrect food, or misspells
- User forgets to add a food item in possession
- User forgets to remove food items no longer in possession
- Food item remains in user’s possession too long, and expires/rots
--> Record consumed food
Goal: create a record of what food a user consumed
Frequency: daily
Precondition: have consumed food
Subtasks:* Specify a new food log entry
- Enter information pertaining to the food eaten, such as:** Type of meal (breakfast, lunch, dinner, snack, other)** Date
- What food items were eaten*** User can optionally choose this from the list of food in possession
- Optionally for each food item:** Amount of item eaten** Food group that item belongs to
- Calories
- Cost
- Submit information
- As an alternative to the above, if a user is a member of a Group (see section IV below), user can simply import a Group food entry to own food log** User can further edit this entry once it is imported (e.g. to delete items he or she did not actually eat, or to add items)
Possible errors: * User enters a wrong food item
- User incorrectly specifies a detail about a food item
- User enters a list of correct food items, but all on the wrong day
--> View food history
Goal: View what the user has eaten in the past
Frequency: weekly to monthly
Precondition: have made at least one meal entry
Subtasks:* Specify which entries to show** Specify a date range
-
- Optional: categories of meals (breakfast, lunch, dinner, etc.) to display
- Specify level of detail to show** Choose between a summary or full details
Possible errors:* User specifies an impossible date range (going backwards in time)
- User has no food history to display
--> View food statistics
Goal: See trends in a user’s food data
Frequency: several times a week to monthly
Precondition: have made at least one meal entry
Subtasks:* Specify data range for statistics
- Specify the type of analytics desired. Can sort by trends in:** Proportions of different food groups** Food costs
- Calorie consumption
Possible errors:* User specified impossible date range (going backwards in time)
- User has no food history, and thus no statistics to display
IV. Manage groups of people who eat together
Global precondition: user has an account, and has identified self
Subtasks: (see below)* Create a Group
- Join a Group
- Invite users to join a Group
- Delete a Group
- Change Group Administrator
- Record food consumed by Group
- Communicate to all group members
--> Create a Group
Goal: Allow users to identify with other users who have an overlapping meal plan. This allows them to share information about the food they all eat. The user who creates the Group becomes the default Administrator.
Frequency: one time only, per group
Precondition: the user who creates the group has an account
Subtasks: * Enter Group name
- Invite other members to join Group (see “Invite user to join a Group” below)
Possible errors:* Misspell Group name
- Mistakenly invite some users who shouldn’t be in the Group
--> Join a Group
Goal: Associate users with others who share a meal with them
Frequency: zero to a few times, total
Precondition: users have an invitation to the Group
Subtasks: * Choice 1:** Receive invitation
-
- Accept invitation
- Choice 2:** Locate Group** Request permission to join Group
Possible errors:* Users can’t locate a desired Group
- Users may want to leave Groups they’ve joined
--> Invite users to join a Group
Goal: Let users know that a Group exists, encourages users to join a Group, and allow users to gain access to the Group.
Frequency: several times
Precondition: invited users have an account
Subtasks: * Locate users
- Send invitations
Possible errors:* Can’t locate desired users
- Accidentally invite an undesired user
Other problems:* Desired users don’t have account
--> Delete a Group
Goal: remove a Group from the site
Frequency: zero to one time only, per group
Precondition: the user doing the deletion is the administrator of a Group
Subtasks: * Specify Group to delete
- Verify desire to delete
Possible errors:* Administrator mistakenly deletes Group
--> Change Group Administrator
Goal: Change a Group’s Administrator to someone else, or add an Administrator
Frequency: monthly to yearly
Precondition: the user making the change must be an Administrator of the Group; new Administrators must be members of the Group
Subtasks: * Optional: look to see who is in Group
- Specify new Administrator(s)
Possible errors:* Specify someone to be an Administrator who shouldn’t be
- Attempt to specify someone outside the Group to be an Administrator
--> Record food consumed by Group
Goal: Make a meal entry for a Group, specifying what was on this Groups’ menu.
Frequency: possibly daily
Precondition: user who makes the entry must be an Administrator of the Group
Subtasks: (this is the same as for a personal food entry)* Specify a new food log entry
- Enter information pertaining to the food eaten, such as:** Type of meal (breakfast, lunch, dinner, snack, other)** Date
- What food items were eaten*** User can optionally choose this from the list of food in possession
- Optionally for each food item:** Amount of item eaten** Food group that item belongs to
- Calories
- Cost
- Submit information
Possible errors:* Admin enters a wrong food item
- Admin incorrectly specifies a detail about a food item
- Admin enters a list of correct food items, but all on the wrong day
Other problems:* The menu entered does not apply to every member in the Group ** The solution to this is explained in “Record consumed food” of section III above.
--> Communicate to all group members
Goal: Communicate a message to all members in a Group.
Frequency: possibly daily
Precondition: sender must be member of Group
Subtasks: * Create new message
- Write message
- Send message
Possible errors:* Sending a message prematurely
- Losing a message that is half-written because of an external failure
Further Notes:* All tasks are performed by an individual user.
- Tasks are probably learnt individually by experimentation on the site or by reading an instruction page.
- All tasks are performed at a computer. Users may be distracted or multitasking.
- Users may be constrained on time, or will easily see the service as a hassle if it takes more than a few minutes per day to use. The tasks, especially daily ones, should take as little time as possible.
Meta Note:* The Groups aspect of the site may be dropped if time gets too tight.
Justifications
This Task Analysis reflects our interviews and observations of people in different dining situations at MIT. We interviewed a student who lived in Burton-Conner (BC), a dorm with no dining plan; a student who lived at pika, an MIT independent living group with a house-run, required meal plan; several students at the MIT Alpha Delta Phi fraternity (ADP), ranging from those who cooked very little to the most active cook in the fraternity; and two students who lived in Ashdown House, a dorm with both a required dining plan (dinner only) and plenty of individual kitchens.
Originally, our plan was to create a site that helped students eat healthier by creating a site where students could find other students with similar tastes in food and organize cooking teams. However, the student at BC expressed discomfort with cooking with strangers and possibly even acquaintances, and said that scheduling would be a big problem for MIT students. The most active cook at ADP expressed similar concerns, saying that the people he might potentially cook with would be people he sees day-to-day anyway, and he doesn’t need a website to connect with them. Furthermore, as the student at pika showed, some students are already on mandatory dining plans that can cover all three meals of the day, and thus have pre-determined cooking groups. Many students also buy lunch on campus (e.g. from the Stata Center, Cafe Four, or food trucks) and live in dorms that require a dinner meal plan, meaning they have less of a need to cook. In fact, with the proposed changes to MIT dining, starting next year, some students may be eating all their meals at a dining hall. In addition, the students at Ashdown (one cooks dinner a few times per week and eats at the dining hall the other nights, while the other cooks dinner on most nights) pointed out that they wouldn’t use the site very much (on the order of twice a month) since cooking in groups usually takes more time than cooking by themselves.
Though our potential users would not use our intended service, they told us problems that were relevant to them. The student at BC wanted to be able to track her food intake, nutrition, and food costs easily. She said she used to keep track of these details on a spreadsheet, but it was too clunky to use. Thus, we came up with the idea of the food log. The student at pika told us about problems with planning food for a large group of people, and requested the ability to list menus for the house, arranging for late dinners (when people can’t make it to dinner, they request food to be set aside for them), and for signing up to do kitchen duties. To serve this population, we added the ability to create “Groups,” which allow people to share food logs (since they eat some similar meals) and aggregate their communications about food. This functionality could be useful to all FSILG’s that have a house meal plan.