WAITLESS

Stage 1

Stage 1 involved brainstorming proposed ideas for our project. We agreed to expand upon three ideas for this deliverable.

U of C room Finder

A mobile application that by way of visual cues, voice directions, and camera/AR implementation shows the user the route to take toget to the room they were looking for. We planned for this app to be accessed anywhere around campus. However, for our timeline, a small scale part of campus would've be achievable, such as a handful of rooms. The idea is to get the initial position of the user’s mobile device. The main methods we have considered are Wifi Access Points and BLE Beacons. Once we have received the location of the user, the user will then choose the room that they are looking for through a searchbar in the app. Once the room is selected, the app will pick one of the pre-defined routes that is in the system that gets the user from their starting location to their final one. Alternatively, we can implement a shortest path algorithm that determines the the fastest path from one room to another. This method will need to have a map of the building/campus area implemented in software as well as the following considerations:

• If location finding was implemented with WAPs, we will have to calculate room positions relative to the WAPs before hand
• If BLEs are used, beacons can be placed in the rooms so that we know where the rooms are located

Finally, through the use of on screen visual commands, voice directions, or AR implementations the app will direct the user through the chosen route to the destination that the user picked.

WaitLess

A mobile application that improves on the existing line up app, "QLess". Students can join a ”virtual line” to make the process of meeting with an advisor much easier. When registering for the first time, students can set their post-secondary institution in order to only show lines that would apply to them. Additionally students can search for specific queues, or organize them by preset options such as distance and line-size. These queues would have info pages and FAQs that users can easily view and have the option to contact these advisors. When queued, the user's position and estimated wait time are displayed along with directions to the advising location.

D2L Mobile Application

With a D2L mobile application, notifications will be visible on a users phone as if it was a notification from any other app. This will help students keep track of courses and their updates/information. Important deadlines such as tests and assignments would be priority notifications and updated course info/material and discussion posts could be tagged as important by course instructors and TA's if they desire. Students would also have the ability to mute specific notifications, or add more for themselves if they require them. Class schedules could also be linked to user's D2L accounts to remind them of upcoming classes and tutorials or if they've been cancelled by instructors. These all would improve the student experience and assist them in course and time management.

Continue to Stage 2

Stage 2

In Stage 2 our group chose an idea from the previous stage to further develop as our main project. We agreed upon the WaitLess queue app and provide the basis for this idea in the following.

Project Description

The WaitLess project idea revolves around improving the virtual academic advising experience for students by refining a virtual line up system. The current solution, QLess, has problems that will be addressed with our idea while also adding improvements to make lining up virtually easy and convenient. We expect our system to be used as a mobile application where students can virtually line up for drop-in advising at their university/school. This system will be used by students and academic advisors that will be conducting these line ups. The context at which we expect this system will be used under is in an academic environment between student and advisor. We don't expect the student to use this system daily as advising meetings are infrequent, but we expect the advisors to use this system daily to provide guidance to students.

Stakeholders

• University students are the ones who will use this system to line up to get counseling on their degree. Students can be split into two categories:
  • Students familiar with the existing solution QLess have sufficient experience and background using a virtual advising system. Hence, would be more understanding when using our idea.
  • Students NOT familiar with QLess do not have much experience or background with virtual advising and would need special attention to make our WaitLess solution more welcoming.
• Academic advisors are individuals who will be using this system to advise students and set up lines. Advisors are assumed to already have the requirements and experience of conducting virtual advising as well as background knowledge in QLess.
• The University Administration are stakeholders that will want to oversee the our system but will not directly use it.

User Research

With the pre-existing QLess app, we were able to make comparisons and evaluate this product to create initial requirements for our app and make changes we deemed necessary. We were able to sit down with University of Calgary students to get their feedback on the QLess app, recieve a better idea of the actual application functionality and evaluate their overall user-experience. We also talked to the parents of one of our teammates to get an idea of solely the design of the app.

The following issues came to light from these discussions:

• An "About" label at the top left that provides no valuable information, except a way to get to settings.
• Can't access settings unless you are on the home page.
• Constant "refresh" animation covering the first place.
• Need a more tailored location selector. Being offered places that are nowhere near the user.
• Difficult to locate academic advisors as a line. Need a student specific menu.
• Multiple UI menus needed for joining a line. Could be simplified to 1.
• Information is not retained from joining lines in the past.
• Setting up appointments for a second time asks for the same data to be input which users find extremely time-consuming.
• The app doesn’t allow re-using previous inquiry messages from the user. Users feel this would help them organize their thoughts and questions for the next meeting.

Flow Analysis

We also drew out the process flow that listed out the steps of putting yourself in an drop-in advising line.

From this diagram we learned the following:

• Stripped down the process of getting into a virtual line for academic advising. Identified important tasks, decisions that a student should do in order to get into a line.
• Determined alternative endpoints/end-goals for the lining up process. These alternative end goals keep students needing short answers out of the line.
• Introduced possible improvements in the lining up process by having the student submit their question before they get in the line, so the student and advisor can reduce session time and shorten the line.

User Tasks

Lastly, we listed user tasks to include in our project.

Must Be Included

• The user must be able to log in once and join a queue without going through any additional steps. The process of joining a queue is the main task that the app performs, and going through unimportant steps before joining a queue can cause frustration for the user.
• The user must be able to search and browse for different queues to join. This task involves the user having an option to freely browse queues and also search for specific queues. This task must be included in our application because it allows for users to find their desired queue quickly.
• The user must be able to access a FAQ page for queues and/or be able to access a chat system to be able to get information about the queue before joining it. This task is essential because it will allow for a better user experience and also reduce excessive joining and leaving of queues.

Important

• The user should be able to sort the current lists on the screen in a variety of different ways. For example, from our research, we discovered that it is important for the user to sort information how they wish in order to quickly find what they need.
• The user should be notified by the app on their position in the queue. As they get closer to the front, notifications would become more frequent, however they may could change this setting to meet their need.

Could be Included

• The user could access a general "about" page that contains more information about the app. This task could provide a good baseline of information for the user.
• The user could access a history of queues they've joined in the past. This allows for better communication between the user, application provider, and the queue provider if support is ever needed for the user.

Continue to Stage 3

Stage 3

For Stage 3, we further developed our user tasks, created an affinity diagram, completed a cognitive walkthrough and created sample sketches and visuals for our app. A Low-Fidelity prototype was also created and used in a demo.

User Tasks

We further develop user tasks through horizontal and vertical prototyping.
Horizontal prototypes are most often used during the early stages of analysis. They give a broad view of the application including sample screens, menus, buttons, pop-ups and sample reports that reflect the current requirements.
Vertical prototypes are used in the later stages of analysis and design to drill down and elaborate on specific features or functions.

Prototyped Vertically

• The user will be able to search and browse for different queues to join. This task involves the user having an option to freely browse queues and also search for specific queues.
• The user will be able to access a FAQ page for queues and/or be able to access a chat system to be able to get information about the queue before joining it.
• The user will be notified by the app on their position in the queue. As they get closer to the front, notifications would become more frequent, however they may change this setting to meet their need.

Prototyped Horizontally

• The user will be able to search and browse for different queues to join. This task involves the user having an option to freely browse queues and also search for specific queues.
• The user will be able to log in once and join a queue without going through any additional steps. The process of joining a queue is the main task that the app performs, and going through unimportant steps before joining a queue can cause frustration for the user.
• The user will access a general "about" page that contains more information about the app. This task will provide users with a good baseline of information about the functions and purpose of the app.
• The user will access a history of queues they've joined in the past. This allows for better communication between the user, application provider, and the queue provider if support is ever needed for the user.

Affinity Diagram

Cognitive Walkthrough

Low-Fidelity Demo

Continue to Stage 4

Stage 4

In Stage 4, we began creating a high-fidelity prototype for our app and conducted a heuristic evaluation on it.

High-Fidelity Demo

Heuristic Evaluation

Our evaluation was conducted using Nielsen and Molich’s UIDesign Guidelines. We split our team into 3 evaluators and 2 reviewers. Each evaluator independently viewed the application and reported their findings using the guidelines provided. Each report was then shared with the reviewers and were analyzed to determine problems and their severity.

• Initially, the high priority issues we encountered all related to traversal of the app. When evaluating early versions of the prototype, many of the buttons in the app did not take users to the correct screen or no screen at all.
• In regards to problems with a low severity of 1 and 2. They are mostly related to quality of life enhancements. There is a need to recolour different sections and buttons to be less eye straining. This mostly pertains to the faculty logos in the queue search and the help buttons.
• Moving on to the overall design of the app, when transitioning from the lo-fi prototype to the hi-fi prototype, overall aesthetic and design was vastly improved.

Overall, the heuristic evaluation and review process found initial versions of the prototype to have a few areas with high severity issues to address. After these were dealt with, evaluations of the prototype mainly resulted in the identification of issues with none to low severity mainly relating to quality of life and non-critical usability of the app. Throughout the entire process, the app required the most attention in the area of error prevention, mainly relating to navigation and accessibility, and required the least attention in the area of matching the system to the real world, which was integrated well in previous stages.

Continue to Stage 5

Stage5

In this final stage, we refined our high-fidelity prototype, conducted a professional demo and wrote a final project report.

Final Demo Video

Team

Robert MCCURDY
Karan PANESAR
Evan LOSIER
Edmund SAYSON
Amman YUSUF

A Project for CPSC 481

Elements

i = 0;

while (!deck.isInOrder()) {
    print 'Iteration ' + i;
    deck.shuffle();
    i++;
}

print 'It took ' + i + ' iterations to sort the deck.';