Project 5: Beta Release
Table of Contents:
Design revisions
During implementation, we realized that the inventory class was effectively a state on each expiring item. Instead, we decided to give each expiring item an administrator, and an additional state of status which is Unreleased, Claimable, Ordered, Used, and Expired, which were previously managed by the inventory concept. This also meant that we discarded the pantry statistics dashboard feature.
We also realized that the map feature made more sense as a sync than a concept, since we want the maps for users to dynamically update based on changes to eligibility information, meaning that the locations should be refreshed each time and eliminating the need to save locations across sessions. Thus, the map is now a sync that the frontend can call each time the corresponding Vue component is accessed.
While implementing the frontend for ordering, we realized that while our original route to get orderable quantities and barcodes requested the pantry account’s username, this data wasn’t already exposed on the frontend to the user, and would require an additional request. To fix this, and make the backend functionality accessible to users more cohesive, we changed the route to take the pantry administrator ID instead of pantry administrator username.
For the time being, we struggled with implementing the map, and fell back to the list of food pantries by city, as we said we might in assignment 3. Since users can still view pantries by location, this does not significantly impact usability. We also postponed implementation of request until the next assignment to focus on core functionality, as we said we might in assignment 3.
User testing task list
Task list for administrators
| Task | Instructions | Rationale |
|---|---|---|
| Log in | Log in as a pantry administrator using the example username and password provided. | The user needs to be logged in to execute any further actions. |
| Update opening hours | Find the pantry settings and update the pantry’s hours. | The user has to update opening hours using a text input, instead of a calendar or drop down, which they may be more used to. This task tests whether users find this input method intuitive. |
| Update eligibility requirements | Find the pantry settings and update the pantry’s eligibility information. | The eligibility requirements are in a slightly unconventional format, where a user has to select a requirement using a checkbox, and then fill in a boundary value using an input box associated with that value. |
| Add, update, and delete an item in the inventory | Add an item with barcode 5900259094704, and set the day for release to tomorrow and the day the food expires to two days from now. Then update the item to change the expiration date to a week from now, and then delete the item. | We worry there may be some confusion regarding what the “drop date” means in our app, specifically as it relates to when food is released. By giving a release task accompanied by expiration, we will be able to deduce if a user differentiates the two and also understand that drop date relates to the release time. With updating and deleting, we can then see how quickly a user grapples with a typical administrator flow regarding an item. |
| Check pending orders and fulfill an order | Find an order that is placed for pickup in the future, find the items that should be in the order, and change the order status to packed. | A central admin flow is identifying orders and their necessary items, since one needs to pack them. We want this to be as efficient and easy as possible, so testing this will let us see if administrators can efficiently and easily engage in that flow. |
| Update out of stock request | Find requests that clients have made for out of stock items, and notify one client that their request has been satisfied. | This is another major administrator flow, and we are specifically uncertain if administrators will assume once they add an item, they do not need to notify the clients. We want adding the request item and notifying clients to feel seamlessly connected, so ideally this will test that. |
Task list for clients
| Task | Instructions | Rationale |
|---|---|---|
| Log in | Log in as a pantry client using the example username and password provided. | The user needs to be logged in to execute any further actions. |
| Update eligibility information | Update your settings to indicate that your annual income is $25000. | Updating user information is necessary for eligibility, but the user flow of identifying what to update may be too vague. Ideally, we can verify that this necessary feature is coherent and efficient for users. |
| Find a pantry | Use the map to find a pantry that is located in your area. | We want to verify users understand the use of the map concept and in particular understand that the food pantries are one’s that they are specifically eligible for. |
| Make an order | Go to the given pantry, and begin an order. Add items to the order that you would need to make a balanced meal. | We want to make sure users can easily identify a pantry and then add items to it efficiently, and specifically be able to find the items they are intending to. |
| Request an out of stock item | If there is an item you would like that is out of stock, request the pantry to restock that item. | We want to make sure users don’t simply ignore items that are out of stock (as they may at other online markets). Instead, they see they are out of stock and consider requesting a restock. Hopefully, they quickly think that an out of stock is connected with a request option in the UI itself. |
| Submit an order | Place the order you’ve created. Then, check the order that you created to confirm the time you’ll pick it up. | We want to verify that users have clarity in how to place an order, and how to then find where their orders are. Since this is core to the user flow, we want the operation to be as efficient as possible, so any hiccups for the user will be helpful in optimizing the UI. |