Embed Size (px)
Citation preview
Assignment 3a: Low Fidelity Prototype Group Name: KRABS
Group Member Photo
Name: Randy Jama Student Number: 34487694 Email: [email protected]
Name: Andrew Bui Student Number: 15991152 Email: [email protected]
Name: Saif Sajid Student Number: 25125148 Email: [email protected]
Name: Kenton Ma Student Number: 32689151 Email: [email protected]
Name: Benny Lo Student Number: 32677130 Email: [email protected]
Precursor Information
What type of users are expected? ● A wide age range and technical skill level for the user base is expected to use
the interface. ● The audience encompasses anyone who may need to set up a recurring
commute path or a one-time use to optimize a trip when using multiple transport methods. Thus, the audience can range from a technically savvy teenager to a technically inexperienced middle aged individual
What they are trying to do with it? ● A given user may have multiple reasons for using the application, but all the
reasons stem from wanting to create a route using multiple transportation methods.
● The interface could also be used to save routes for specific times. Such features may prove useful to those who wish to set up recurring trips such as commutes to and from work.
What are the tasks and how the user is expected to accomplish them? ● Search route scenario
○ User types the destination address in the search bar ○ User sets the departure and/or arrival time ○ User adds intermediate stops (optional) ○ User specifies transport type preferences (optional) ○ User picks one of the recommended routes
● Save trip route scenario ○ User specifies destination address, intermediate stops, departure/arrival
timing, transport type preferences ○ User clicks on the star to save the trip route ○ User chooses a name for the trip route (optional)
● Set alarm scenario ○ User clicks on the alarm icon ○ User inputs the time for the alarm to go off before reaching the next stop ○ This scenario encompasses users who want to nap during their commute -
the alarm will wake up a sleeping user so they do not miss a transfer
1
Heuristics being used in the screens: ● Nielsen Heuristic 1: Simple & Natural Dialog
○ The purpose of the application is to be mostly visual driven through a touch based interface. Therefore, it is critical to reduce the amount of text on screen for the user to read by replacing it with helpful, yet simple, visual layouts and icons to guide the user’s eyes around the screen.
● Nielsen Heuristic 2: Speak the users’ language ○ The language displayed in the application is all simple, basic English.
There are no technical terms. The words used are terms such as “destination”, “method”, “go”, and “save” - all are easy to understand by anyone.
● Nielsen Heuristic 3: Minimize user’s memory load ○ A key feature of the application is to store routes, such that previously
taken routes can be easily selected by the user. The user simply selects a saved route, instead of having to reenter it.
○ As the user enters an address, the application will automatically suggest locations. This means a user who is unsure about a location name can enter the parts of the location they do know, and receive a helpful recommendation. For example, if I entered “Simon University”, the application would suggest “Simon Fraser University”.
● Nielsen Heuristic 4: Consistency ○ The GUI must maintain a similar visual language and field layouts across
the screens. All buttons or symbols on a screen should serve a purpose that is universal no matter where it is viewed in the app. For example, a “plus” button in the app should always mean adding a new entry in a list.
○ The application never uses the same word to mean different things. ● Nielsen Heuristic 7: Shortcuts
○ A user can skip the relatively time consuming process of entering a travel route (beginning, destination) if they have already saved the route. Instead, the user simply selects the route from the Saved Routes menu and the application will begin executing the route.
● Nielsen Heuristic 9: Prevent errors ○ As the user types in a location/address, the application will auto suggest
possible locations or addresses. If no locations/addresses are suggested, the user knows that their entry does not exist, preventing the user from searching for a non-existent place.
2
Early Prototyping Notes & General Flow
3
Low Fidelity Prototype Flowchart & Screens
4
Figure 1: Home Screen
Figure 1a: Saved Routes Screen
5
Figure 1b: Settings Screen
Figure 2a: Search Screen (Blank)
6
Figure 2b: Search Screen (Typing)
Figure 3a: Routes Screen
7
Figure 3b: Trip Timing Screen
Figure 3c: Breakdown Mode Screen
8
Figure 4a: Set Alarm Screen
Figure 4b: Alarm Confirmation Screen
9
Figure 5: Navigation Screen
10
