Skip to content

Commit

Permalink
Update BP#3 based on course feedback
Browse files Browse the repository at this point in the history
  • Loading branch information
cynber committed Feb 28, 2024
1 parent 5f7f55c commit 5257191
Show file tree
Hide file tree
Showing 2 changed files with 70 additions and 18 deletions.
87 changes: 69 additions & 18 deletions docs/blog/posts/project-update-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ This blog post will include a revision to the task examples, information about o

## 3a. Further Updated Task Examples

!!! quote "Task Examples from Project Update 2"
!!! quote "Original Task Examples (from blog update #2)"

Task Example 1: Jeffrey

Expand Down Expand Up @@ -55,7 +55,13 @@ Two of our task examples remain unchanged, but the second task example called "K

Karen is a parent taking photos of her son at the UBC fountain prior to his wedding ceremony. This is her first time on campus, so she is unfamiliar with the facilities. As this is a private event, there are no UBC staff members that can assist. The ceremony is starting soon, so she wants to find a washroom nearby that she can access quickly without much walking since she is wearing uncomfortable shoes. Since it is a later in the day, she is not sure which buildings are open to the public and which ones need keycard access, such as those that are locked after a certain time. It would take some time to check each building for access and facilities, and she is not sure which one will be easiest to access for her. She can ask her son for directions, and he is able to direct her towards a building, but she does not know where to go after entering the building.

We changed the context of the task example to be a wedding ceremony instead of a graduation ceremony. As graduation ceremonies typically have lots of staff and volunteers to help guide guests, we wanted to make the task example more challenging and generalized by removing this support. Also, we removed the specific details on how she completed the task to make the task example more open-ended and allow participants to come up with their own solutions.
#### **Explanation of Changes**

We changed the context of the task example to be a wedding ceremony instead of a graduation ceremony. As graduation ceremonies typically have staff and volunteers to help guide guests, we wanted to make the task example more generalized by removing this support. Private weddings events and festivities are not likely to have UBC staff members to assist. This change should make the task example more representative of users that are unfamiliar with the campus and need to find a washroom quickly. We also removed the specific steps Karen took to complete the task, so that the task example would remain open to different solutions.

<br>

#### **Other Thoughts**

Other than this change, the task examples remain the same. Our task examples went through a significant update in blog update #2, and they continue to be applicable and relevant to the current direction of our designs. We currently do not have any significant updates to our requirements or methodology to justify changing the other task examples.

Expand All @@ -69,53 +75,98 @@ PLACEHOLDER TODO: Add low-fidelity prototype demonstration

## 3c. Additional Information about Prototype

The chosen design of a mobile app should support all our task examples. An app provides the flexibility for it to be used on the go, making it suitable for those who have limited time to find a washroom (e.g. Marie and Karen) as well as those who have time to explore. Further, with the knowledge that UBC Vancouver provides Wi-Fi access to both guests and members of the community, a mobile app can be easily downloaded by anyone on campus. This design also accounts for different preferences for washroom features and amenities and takes measures into categorizing them for ease of use. Additionally, since a mobile application has a built-in update mechanism, the faster release cycles should enable us to quickly update any features or preferences that have not already been accounted for. This would be much more difficult and expensive with a stationary board or a custom device.
### **Prototype Justification**

The chosen design of a mobile app should support all of our task examples. An app provides more flexibility and it can be used on the go, making it suitable for those who have limited time to find a washroom (e.g. Marie and Karen) as well as those who have time to explore. Since UBC Vancouver provides both private and public Wi-Fi access, a mobile app can be easily downloaded by anyone on campus. For example, signs could be placed around campus with a QR code to direct the user to the app.

This design also accounts for individual user preferences for washroom features and amenities and, it takes measures to categorize them for ease of use. Additionally, since a mobile apps have a built-in update mechanism through the app stores, the app can be updated more quickly and easily to include new features or preferences that aren't currently accounted for. This would be more difficult and expensive with a stationary board or custom devices.

<br>

### **Focus of Prototype**

For this stage, while we considered exploring both breadth and depth of the design, we focused more on the depth of key features.

**Design Breadth:**

- Wireframes for all key features have been designed.
- However, some less crucial pages such as the profile page were omitted.


**Design Depth:**

- We paid special attention to key aspects such as searching and viewing washroom details. Interactions on these pages are more complete and flow seamlessly between one another.

At this stage, this prototype has both breadth and depth, but focuses more on the depth of key features. With regard to breadth of the design, wireframes for all key features have been designed. However, some less crucial pages such as the profile page were omitted. With regards to depth, we paid special attention to key aspects such as searching and viewing washroom details. Interactions on these pages are more complete and flow seamlessly between one another.
One key design decision we made was to add a toggle on the interface for looking at washroom features. This toggle allows users to switch between a more visual interface with icons and images representing the information, and a denser text-based interface. This was done to accommodate different user preferences and to make the app more accessible to a wider range of users.

One key design decision we made was to give users the option of a more visual or text-based interface – specifically for washroom features. This will be implemented via a toggle that allows for users to switch between an icon view of information and a text-based view of information. Another choice made was to leverage positive transfer effect and utilize industry standard interactions such as screens sliding into frame from the right after a button is clicked and swiping from left to right to return to the previous page.
Another design decision made was to leverage positive transfer effect and utilize industry standard interactions such as screens sliding into frame from the right after a button is clicked and swiping from left to right to return to the previous page.

---

## 3d. Cognitive Walkthrough Report

### **Cognitive Walkthrough Goals**

During the cognitive walkthrough, we asked participants to complete the following tasks:

- Assuming you are somewhere on campus, find a nearby washroom as quickly as possible
- Assuming you are at the washroom, try to add or update information about the washroom

<br>

While the user completed the task, we were looking for the following:

- How long it took for the user to complete the task
- Whether the user's conceptual model matched the system's conceptual model, which is to say if the effect of the user's actions matched their expectations
- Whether the information or button is visible and easy to find, once the user knows what they are looking for
- Once an action is completed, can the user recognize that the action was successful and would they have benefited from any additional feedback
- Whether the information and buttons were visible and easy to find, once the user knew what they were looking for
- Once an action was completed, could the user recognize that the action was successful and would they have benefited from any additional feedback

<br>

### **Cognitive Walkthrough Results**

**Task 1: Find a nearby washroom as quickly as possible**

We found that the user was able to quickly find the washroom using the quick search button, but they had difficulty getting back to the home screen afterwards as they did not expect to have to swipe from left to right. Once the user got to the directions screen, they understood that they had completed the task.

<br>

The cognitive walkthrough identified several usability issues with our prototype. We found that the user was able to quickly find the washroom using the quick search button, but they had difficulty getting back to the home screen afterwards. Additionally, the user could add information to the washroom, but they said they may not have done so unless specifically asked to do so. This suggests that we may need to make the process of adding information more intuitive.
**Task 2: Add or update information about the washroom**

One suggestion from the participant was to connect the process of adding information to the process of finding a washroom. Once the user has arrived at the washroom, which would either be detected automatically or selected by the user, the app could prompt the user to add information about the washroom. This would make the process of adding information more intuitive and would also help to ensure that the information in the app is up to date.
For the second task, the user was able to quickly find the button to add information to the washroom. Their conceptual model matched the system's conceptual model, and they were able to recognize that the action was successful. However, they recommended that the confirmation screen should be more distinct, such as by including a large checkmark.

<br>

**Overall Feedback**

The user noted that while they could add washroom information easily, they may not have done so unless specifically asked to do so as a task. This suggests that we may need to make the process of adding information more streamlined and intuitive.

One suggestion from the participant was to connect the process of finding a washroom to the process of adding information. The app could either detect when the user has arrived at the washroom, or include a button on the navigation screen to confirm that they had arrived at the washroom. When the arrival was confirmed, the app could automatically open up the add/update information screen. This would make the process of adding information more streamlined, and better address our goal of keeping the information in the app up to date.

---

## 3e. Proposed Goals of Experiment

For our experiment, there are a few goals that we would like to focus on. We have ranked these goals by importance and our ability to test them within the scope of CPSC 444. Our two most important goals are:
For our experiment, there are a few goals that we would like to focus on. We have ranked these goals by importance and our ability to test them within the scope of CPSC 444. Our two most important goals are as follows.

1. **Do users feel motivated to add/update washroom data?**
- This is the most important goal for our experiment. We want to ensure that the app is sustainable and that the information in the app is up to date. As such, we want to investigate whether users feel motivated to add or update washroom data.
- While this currently exists in a limited form in our low-fidelity prototype, we will need to expand on this for our evaluation. In particular, we want to explore different ways to motivate users to add or update washroom data. For example, we could explore the use of gamification or social incentives.
- This is the most important goal for our experiment. We want to ensure that the app is sustainable and that the information in the app is up to date. As such, we want to investigate whether or not users feel motivated to add and update washroom data.
- While this currently exists in a limited form in our low-fidelity prototype, we will need to expand on this for our evaluation. In particular, we want to explore different ways of motivating users to add and update washroom data.
- In particular, we are exploring the use of gamification and social incentives, such as a points system, a leaderboard, and achievements.

2. **Do users prefer a visual or text-based interface?**
- This is the second most important goal for our experiment. We want to ensure that the app is accessible and usable by a diverse set of people. As such, we want to investigate the best way to convey information, so it is easy to use.
- This is easy to test since it is already partially implemented in our low-fidelity prototype. For our evaluation, we will ask participants to complete tasks using both the visual and text-based interfaces and then ask them which one they preferred.
- This is the second most important goal for our experiment. We want to ensure that the app is accessible and useful for a diverse set of users. As such, we want to investigate the best way to convey the information.
- This is easy to test since it is already partially implemented in our low-fidelity prototype. For our evaluation, we will ask participants to complete tasks using both the visual and text-based interfaces, and then ask them which one they preferred.

<br>

We also considered a few other goals, but we are unlikely to pursue them in our experiment. These goals are:
We also considered a few other goals, but we are unlikely to pursue them in our experiment. Those goals are as follows.

3. **Do users value the option to switch between text-based and visual-based GUIs?**
- This may be helpful if we find that there are groups of users that prefer one interface over the other. While this is partially implemented in our low-fidelity prototype, it is partially encompassed by the goals above.
- This may be helpful if we find that there are groups of users that prefer one interface over the other. While this is partially implemented in our low-fidelity prototype, it can be covered by the goals above.

4. **Do users see themselves continuing to use this app over time/once the novelty wears off?**
- This is important for the long-term sustainability of the app. However, within the scope of CPSC 444, we may not be able to test this goal effectively. This is something that would need to be tested over a longer period of time, especially because individual users may only use the app every so often.
- This is important for the long-term sustainability of the app. However, within the scope of CPSC 444, we may not be able to test this goal effectively. This is something that would need to be tested over a long period of time, especially because individual users may only use the app every so often.

5. **Do users prefer a more playful/juvenile or serious design?**
5. **Do users prefer a more playful and juvenile design, or a more serious design?**
- This is a low priority goal to explore different design and theme options. In particular, we want to see if users will enjoy a funny and playful design, or if they might find it inappropriate for the context.
1 change: 1 addition & 0 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,7 @@ markdown_extensions:
- pymdownx.superfences
- attr_list
- md_in_html
- sane_lists

theme:
name: material
Expand Down

0 comments on commit 5257191

Please sign in to comment.