Blog Update #3

Blog Update #3a — Further Updated Task Examples:

Our original task examples can be found at https://medium.com/cpsc-444-lost-and-found/milestone-2-project-introduction-ba7cee038138.

Neither the first or second task examples have changed but we have rewritten the third task example and the summary of the revisions can be found below.

Task Example 3

Donald just finished class in Hugh Dempster Pavilion and as he’s walking to his next class, he realizes his reading glasses are missing. Upon realizing this, he immediately tries to Google the UBC lost and found. He waits a day to check the database again, in hopes that a new listing that matched his glasses would be appear, but it didn’t. He ends up going to the UBC Bookstore and they don’t see his item there either.

Donald then decides to scroll through his Facebook timeline. A few posts down, he sees Patricia has posted a picture of his reading glasses in the “UBC Class of 2021” Facebook page. Donald sends her a direct message with a brief description of where and when he lost the glasses.

A day later Patricia notices a direct message request and trusts that Donald was indeed the true owner as the location and time matched. She also sees the exact glasses in his Facebook profile picture. She lets him know that she still has the glasses on her and that they can meet any time that week on campus. They coordinate a mutually desirable time and location and exchange the items.

Summary of Revision:

We had originally wanted to add an extra task example that reflected how the Computer Science department currently handles lost and found items, the way that our previous Bookstore task example did. However, upon deciding that the department should not have an active role in handling the lost and found process, but rather, just act as a drop-off point for items, we have decided to instead focus on the interaction between item losers and founders. The new task example reflects a combination of our previous task examples, and how this interaction currently exists.

Blog Update #3b — Low-Fidelity Prototype(s) Demonstration

Blog Update #3c — Additional Information about prototype

We ended up creating 1 low fidelity paper prototype to support the first two task examples and the requirements we had outlined. We chose to support the task examples about trying to retrieve a lost item, and posting a found item. We focused on these task examples as supporting these allowed us to prototype the most feature heavy aspect of our final application — as specified in our requirements. We also took a more vertical approach in order to cover more features, as opposed to spending too much time working out all the permutations of search and filters we could have at this stage. Although we did not make every search and filter option we would like to include, the features were present, so we could better understand what users are expecting to see in the future. Another thing we wanted to ensure was because security is a huge concern of this application, we wanted the CWL login to be the first thing users saw. This is intentional to help ensure users that everything done on the app will be directly tied to their UBC credentials. Overall, the design is meant to be simplistic and streamlined, and aims to leverage positive transfer from our users regarding similar catalogue browsing applications (library, online shopping etc.). We tried to keep in mind what we, as students, would expect and hope to see with an on-campus lost and found app when prototyping.

Blog Update #3d — Walkthrough Report

The lack of feedback made it challenging for the user to understand how the search and filter functionality worked. Since we were unable to actually reorder the results in the appropriate manner after the user entered search criteria, they were unable to understand whether their search worked. Further, the filter button was hard to locate. The naming of the “save” button inside the filter model was confusing. The user had a hard time locating the “submit” button for their filter search, not realizing that the already existing “save” button would have the same functionality as a “submit” button. The user then didn’t fully understand from the feedback if their actions were correct.

Task example 1 was supported by the cognitive walkthrough by searching for a lost item using the interface. Our cognitive walkthrough showed that users can properly search for lost items, identify their item and contact the person that has possession of the given item. However, the walkthrough also showed that the user has difficulty locating the filter options, which substantially increased the search time, which is something that would want to be minimized by the task example.

Task example 2 of adding a lost item to the interface was also supported by the cognitive walkthrough. The user was able to add descriptions of the item, the location, and date that the item was found and how and where to attach a file. However, the type of file to attach was unclear. It would be better to take a picture of the lost item and upload it directly to the interface rather than taking it with the camera and uploading the file separately. Further, the walkthrough showed that adding contact details was unclear, as they were not sure whether to add their email, phone number, facebook, etc.

Blog Update #3e — Proposed goal(s) of experiment

Proposed Goals:

1. Would users be able to find a lost item in Y time?
2. Would users be able to complete posting about a lost item in X time?
3. What are the most representative icons and wording to use?
4. What is the minimal amount of information needed to identify an item?
5. What fields should be required and which are optional? Are there any fields we should omit all together?
6. What is the best way to display lost items for users?
7. Does the level of security meet users’ requirements/ expectations?

We will address the first two goals. Since the main finding from our field study was that the current process was inefficient, the primary focus of our research is efficiency. Testing efficiency using time thresholds would be the most straightforward approach to evaluate it.

We had additional questions regarding usability of the application that we would be curious to find out. But we ultimately would not be able to address them, based on the fact that we won’t have enough prototypes to iterate upon- A/B testing these fine-tuned details would not be a priority for us.