Part 5: Beta Release
Design Revisions
- We ended up having to make changes to the Achievement concept to have progressive levels rather than each achievement being capped and independent (e.g. Tasks II being the next step after Tasks I, instead of making progress towards Tasks I and Tasks II simultaneously with Tasks II merely having a higher value to achieve it)
- There was too much going on in the generatePlan route, so we divided up a lot of the functionality into the various concepts.
- For many of our concepts, we initially had actions that are called multiple times in syncs to find information for MongoDB documents with specific fields or ids. However, once we started programming the routes and coding our syncs, we realized that this process was inefficient and created the need for loops and multiple await calls. Therefore, we simplified and made some routes more efficient by writing function calls in our concepts that return bulk data for a list of ids, fields, etc (as seen in route getPlan).
- We also decided not to implement surveys in our app. The surveys were initially intended to allow the user to gain more insight into their items. However, with regards to time, we decided to scrap the idea since the Plan and tasks also provide this insight.
Plan for User Tests
Diverse Data (Login)
Username: 61040TAs
Password: 123
Tasks
| Title | Instruction | Rationale |
|---|---|---|
| Create an Account | Create an account with an username and password. | Our app limits all functionalities to registered and logged-in users exclusively. The first thing any user must do is to create or log into an account. This task allows us to gain insight into whether it is easy for a new user to locate and execute this fundamental feature easily. |
| Logout and Sign In | Log out of your current account and Log in to an account with username, user1, and password, 123. | In the context of apps, seamless log-out and account switching is fundamental to user experiences. This task serves to evaluate the ease of accomplishing these actions within our app. Additionally it prepares the user for the subsequent tasks which requires a larger number of items logged. |
| Add an Item | Add an item you own to the app. | The tags might be a little bit confusing for the user, and taking a photo might be difficult from a laptop. We just want to look for any potential annoyances in this process. |
| Delete an Item | Delete any item from your catalog. | Deleting an item should be easy for the user. It is a common action a user will face in our app. This task tests whether the design of our app makes it easy to do so. |
| Search and Edit | Find [an item at the bottom of the list] and edit it | f the user chooses to use the search feature, it will be important for its usage to be intuitive and for it to return helpful results. If the user chooses to not use the search feature, that is also useful information. The edit part is there to both (a) make the task feel more purposeful to the tester and (b) check that it works as intended. |
| Week's Plans | Find and view the tasks you have to complete for this week. | A key feature of our app is the generation of a plan that provides users with a set of tasks to complete each day. This feature makes it easier for users to discard items. Therefore, it should also be intuitive and simple to find the plan. |
| Complete Tasks | Complete the tasks for today (no need to actually discard items, just say you did in the app) | We’re unsure if the user will think to delete items or check the checkbox. Also, are the checkboxes too small? |