Page History

Launch App
(Home Screen)

a

This is the entry point of the application, and is the first screen that the user faces when it is first launched. This is termed the Home Screen.

At the top of the screen is an Action Bar, and this is persistent across all views in the application. It provides navigational access to other views and application functions via the icons which are present. Beginning from the left, we have the Friends icon, the Events icon and the Notifications icon. We will outline each of their usage in the following task and sketches. The Home Screen comprises of 2 main portions: the search bar at the top and the map view below.

Map View: By having this screen as a default screen, the user (Alice) is able to view a map view of the location, in this case it is the layout of MIT. Her position on the screen is indicated by a Pink dot, whilst those representing her friends' locations are Blue dots. Tapping on a friend's dot will reveal the friend's name.
Search Bar: The search bar allows for Alice to easily find a user's location on the map by entering his or her name. The view camera will pan over and center about the specified friend. Alice may easily pan the view camera back to her location by tapping the Locate button location on the right of the search box.

By using icons in the Action Bar as opposed to menu buttons with text, it encourages learning by exploring.

We mitigate the confusion by using familiar icons which are used by several other apps, such as the Friends Icon being a silhouette of a male and a female character (Facebook), the Events Icon being a calendar (iOS Calendar) and the tray with an arrow for the Notifications (Apple's Find My Friends. Also, we use the magnifying glass to indicate search. This helps to maintain external consistency with other apps in the same mobile apps ecosystem.

We encourage the user to interact with the map view via direct manipulation. The user is able to pan, perform pinch-to-zoom and tap to select. Upon tapping on a dot on the map, the bubble with the person's name helps to bring the metaphor of the user speaking out his name. There is continuous visual feedback in this interface due to these elements.

The Action Bar's location at the top of every window makes it quick for a user to access any of the 3 key menus without having to cycle back and forth in order to reach any of them.

The map view shows all the users within a nearby location of Alice, the current user. This is an intrinsically efficient way of knowing who is around the user. 

The search bar allows the user to quickly search for a person should he/she not be present in the viewport.

The locate button next to the search bar allows a quick way for Alice to return to where she is located should she have strayed far away whilst looking at someone else's position. This saves user time in trying to pan back to his/her original location.

Listing Friends.

b

Alice wants to view the list of friends that she has using this app, and also approved her. She taps on the Friends Icon on the Action Bar, and it pops and overlaying dialogue. It currently shows two of her friends, Boris and Christine which are sorted alphabetically. Alice wants to search for for Bob to add to this list, and taps the icon with the `+'-plus sign on the top right of the dialog.

The overlaying dialog box is used for all three icons on the action bar and we maintain internal consistency by using the same speech bubble dialog whenever each menu is accessed.

The names are listed in alphabetical order, and the list is scrollable by flick gestures. The arrows on each cell indicate the affordance of tapping to reveal a sub-menu (we will see this in action later). The "+"-icon used for adding a friend maintains external consistency as it is widely used across all mobile apps in the ecosystem.

By using a overlaying dialog instead of switching to a separate view, a user can quickly dismiss the dialog and return to the map view (lying behind it) with just a single tap.

Using flick gestures allows quick scrolling through the list too.

The overlay dialog box can only be dismissed by tapping on the Friends Icon. Because it is relatively small compared to the dialog, and located away from the tapping zones covering the list view and the add button, it becomes a *pointing task. *There is little chance of dismissing the dialog without intending to. 

Even if a user unintentionally taps on a user's name and moves into the Profile View, the back button will allow him/her to return  back easily.

Searching for Bob.

c, d

The app dismisses the dialog box, and presents the user with the Add Friend screen. An icon with a left-arrow is the Back Button, which dismisses the page and brings the user back to the previous page (the Home Screen in this case.) should she change her mind.

The soft-keyboard automatically pops up and the prompt gives focus to the Search Bar upon loading this view. As Alice begins typing the letters 'B' and 'o', the application fill the spaces in between the search bar and the soft keyboard with suggested people she might be looking for based on the directory listing database. 

For each person listed within the list that is already an approved friend in Alice's list, a small icon with the word "friend" is present in the cell. Each cell can be tapped to reveal a user's profile, as indicated by the '>'-arrows located at the right edge. 

Alice sees `Bob' in the list, and wants to find out if he is the person she wants to add. She taps on the cell in order to view his profile.

As Alice types in Bob's name, suggestions guide the user into finding the person he/she is looking for. The list is automatically refreshed and populated with user's names from the directory, 

By placing an icon to indicate an existing friend, the system helps to reduce the task of remembering whether a friend had already been added into a recognition task, as opposed to a recall task.

There exists a clear text button indicated by a circle with an 'x' within it. This allows the user to efficiently clear the search text box as opposed to have to press backspace/delete multiple times in order to clear a name with a long sequence of characters.

The soft-keyboard pops up automatically, and focus is also automatically given to the search bar.This prevents any mode errors, (for instance if the user had to first tap on the search bar manually before the keyboard came up, the user might have just been staring at the empty list assuming something was supposed to happen).

Viewing Bob's profile and sending an "Add Request" to Bob.

e, f

The app brings up the Information View. It lists Bob's name, email-address, office and any other profile information as already available on his public MIT directory listing. Alice knows that this is the Bob she is looking for, and taps on the Send Friend Request button to confirm her intent to send a request to this particular Bob to add as a friend in Discover.Me.

The app brings Alice back to the Home Screen. Alice taps on the Friends Icon on the Action Bar to bring up the dialog, and now sees that Bob has been tentatively added to the list of friends. An icon with the graphic and text stating "pending" indicates that Bob has not yet accepted the request. As such, Alice is unable to view Bob on Map View.

By keeping the information screen simple and uncluttered, and using terminology externally consistent with that used in the MIT directory, Alice will be able to identify if the current "Bob" is the one she is looking for.

By having the pending icon located next to the person's name, Alice will not be forced to recall whether a request had been sent to Bob previously.

If for any reason Alice wants to email Bob, she can simply tap on the email entry which should natively bring up the Mail application of the device she is working on. This saves her from having to first close the app and force her to have to recall the email address before sending an email.

She can also immediately view the location on Map View by tapping on the office section on the user profile.

In order to prevent an accidental request being sent by a mis-tap, a confirmation dialog should ask Alice whether she wants to proceed with sending the friend request after she has tapped on it.

Receiving confirmation from Bob through a Notification.

g

After Bob's approval of Alice's request, Alice is notified by a counter on the Notifications icon in the Action Bar. Alice taps on the icon to bring up the Notifications dialog, and there she sees that Bob had accepted her request. She dismisses the dialog.

Because the counter on the notifications icon appears in real-time, it provides a call for attention. It also provides an affordance that the icon has to be tapped in order to attend to the call.

Alice can easily view the number of requests without having to manually refresh or enter the Notifications page because of the live counter.

One safety issue here would be if Alice taps on the Notifications Icon, and accidentally dismisses it, the counter would have reset and the items in the list which were initially marked as unread would no longer be in that state.

Viewing location of all approved friends.

h

This reveals the Home Screen once again. The Map View shows an additional _Blue-_dot, which corresponds to the newly-added Bob's location (Building 19). Alice notices that both Christine (Building 20) and Bob(Building 19) are located relatively close to her (Building 20). She decides that it could possibly be a good time to arrange a meeting for all three of them for a cup of coffee. She taps on the Events Icon in the Action Bar.

This is the same as the Home View from earlier, except that it should be immediately visible that the number of friends has increased because of the addition of the new dot on the map screen.

Efficiency issues covered earlier in similar screen.

Safety issues covered earlier.

Viewing listed events.

i

The app launches the Events List dialog. Alice notices that she has no scheduled events from the dialog that pops up. She taps on the "+"-plus icon to create a new event.

Using the ""-plus graphic+ maintains external consistency as it is a widely adopted icon to indicate the affordance of being able to add something.

When the list is populated, the user can easily flick-to-scroll across the list at high speeds.

No specific safety issue here.

Creating an event for friends - Bob, Christine and Alice herself.

j

The Create New Event view is brought up. It provides text boxes for Alice to fill up, corresponding to the details of the event she wants to organize right now. The Title is a self-defined title which best describes the event. The Location text box is used to define the location of the event. The Time section indicates the Start Time, End Time and Time-Zone of the event. The Participants text box lists the participants of the event and the Comments text box is a free-entry text for an additional information the organizer might want to add.

Alice types in "Coffee" as the title of the event. The timing automatically defaults to the nearest half-hour based on the current time and time-zone which Alice, the user, is at. Alice is also automatically added as the first participant of the event. 

Alice decides to pick a location for the event, and taps on the Compass Icon located on the right edge of the Location text box.

Each of the text boxes used are widgets which provide the* affordance* that they can be tapped to have their contents change. 

Both the Location and Participant fields have buttons (Compass Icon and +-plus Icon) which provides the affordance that they can be used to assist in filing in their respective fields.

The ">"-arrow located at the Time section indicates that editing the timing is possible (because it indicates a sub-menu is present)

The page provides all the information about the event, and sub-menus are only required to be accessed if edits are required.

Because the timing automatically defaults to the nearest-hour based on Alice's current time, it saves Alice the trouble of needing to specify the time of an event when she wants to quickly and spontaneously create one.

As further illustrated later, by allowing the user to use context specific sub menus to adjust the location, timing and participants, it allows the user to be less likely to make a mistake (picking building 41 instead of 14 for instance).

Selecting a location for the event.

k

This brings Alice to the Map View, but it is in the mode which allows her to tap on a location to select a location for the event she is creating. A small semi-transparent note instructs her on how to select a location. Alice decides that Building 24 is a good location that is close to all three of them. She also really likes the coffee there. She taps on Building 24 on the screen to indicate her choice.

The semi-transparent notice indicates to the user that the mode has changed, and clearly instructs Alice, the user, on how to achieve her goal of picking a location.

By being able to simply tap a location and having the system populate the text representation of the location, it saves time.

Mode error is reduced because of the persistent text that is on-screen, even though the view is similar to the Map View on the Home Screen.

Confirming the location for the event.

l

A Pin Icon animates and drops on the point Alice tapped. White Lines are drawn to between a participant and the pin location to indicate that he/she is invited. It thus shows that Alice, Bob and Christine are all invited to participate in the event. 

At the bottom of the screen, a confirmation menu pops up. It states in text: Location: Building 24, MIT which corresponds to the location of the pin and where Alice tapped. Alice knows that this is correct and thus taps the Confirm button to accept the location.

Because the Pin Icon animates onto the location, the user's attention is brought to focus on the location. The confirmation menu only pops up after the pin drops, and it also states in text what the location Alice

The user can view immediately the number of participants, their proximity to the event location and their responses because of the lines connecting the dots to the event pin.

The confirm and cancel options will allow a user to make a change in location in the event a wrong place was tapped, making the action reversible.

Selecting participants for the event.

m

The Select Participants view is brought up. It presents the list of friends that Alice has (corresponding the to Friend's List). Check-boxes are located on the left of each cell containing the friend's name. There is a search bar located at the top to enable Alice to search for people by typing, or she can make use of the fast-alphabetical scroll-bar located on the right of the screen.

Alice doesn't have many friends, and she can see both Bob and Christine in the list. She checks the boxes corresponding to the both of them. Hovering Text located at the bottom of the screen reflect the number of people chosen. Alice is happy with her selection and taps the Done button.

The use of menus, checkboxes and search bars allow internal and external consistency, so a user like Alice would already be familiar with how to interact with them and their uses.

The quick-alphabetical-scroll allows Alice to scroll through her contact list quickly, even in the event she has many friends listed.

The indicator at the bottom showing the number of people selected adds as a sanity check for the user to ensure he/she has invited the corrected number of participants.

Reviewing and sending the event to friends - Bob and Christine.

n

Alice is returned back to the Create New Event screen. The information which she has provided is now reflected in the screen. She is happy with her selection and taps the Done button to confirm that she wants to create the event and invite the selected participants to it.

The changes that Alice has made is immediately reflected in the user interface.

Efficiency issues covered previously.

Alice may continue to make changes at this point. Other safety issues regarding this UI was covered earlier.

Viewing the created event

o

The screen is dismissed and Alice is returned to the Home Screen. A non-blocking semi-transparent overlay notifies Alice that the invite has been successfully sent out to the users. Alice taps on the Events Icon to bring up the Events List again. It is now populated with her recently created event, giving a summary of the title, date, time and location of the event. Alice may tap on the event to make changes to it, but she does not have any reason to do so right now. She awaits the acceptance of the invite from both Bob and Christine.

The semi transparent overlay acts as visual feedback that the action of sending the invite has completed successfully.

The list compactly represents the event that Alice created.

Alice can simply make modifications to the event by tapping on it and reaching the Modify Event Screen (covered later). This will allow her to make changes and resend the invitations out.

Receiving notification of an event.

p

On Bob and Christine's side, they receive a Notification in their app, which once against is indicated on the counter above the Notifications Icon. Tapping on the icon brings up the Notifications dialog once again. 

On Bob's screen, he can see two notifications on the dialog. The new, one is highlighted with a slight shade and has a dot, which indicates that the notification is unread. Unread in this definition corresponds to notifications which were only not present since the last time Alice was in the Notifications Dialog and corresponds with the counter above the icon.

The notification acts similar to the one covered earlier when talking about an incoming friend's request. The issues with learnability would be similar in this case.

The reciepients Bob and Christine, can easily access details fo the event by tapping on the entry in the notification view.

Safety issues similar to the ones covered earlier.

Viewing the event details and accepting the invitation.

q

On their respective phones and apps, Bob and Alice tap on the cell in the Notifications dialog. This brings up the View Event screen, which is similar to the Map View. At the top, the title of the event "Coffee" is listed, as well as the participants invited as indicated by dots on the screen. The pin corresponds to the location.

Bob thinks it's a great idea to meet up, and he is happy with the location and time, and he taps on the Accept button at the bottom of the screen.
Christine, however, would like to meet up for the event too, but has something on at 2:00PM. She decides to respond to the invitation by Proposing a Change and tapping on the Propose Change button.

The map view provides information regarding the event title and time, and the visual representation clearly indicates the location of the event.

The recipients can easily see the number of people invited to the event, as well as where the event is going to be held without further navigation.

The Accept & Reject buttons have no confirmation dialog. The confirmation dialog is unnecessary because all responses to events can be modified in the Events Menu.

Proposing a change to the event.

r

The Propose Change view pops up for Christine, which is similar to what Alice saw in her Create Event screen. It is populated with the details of the event. Since Christine only wants to change the time of the event, she taps on the Time section.

Because certain options are greyed out, it marks that the affordance for Christine to modify them is not available.

Christine can easily make modifications to the Location, Time or Participants by making use of the Compass and "+"-plus icon.

The greyed out options make it impossible for Christine to make alterations to parts of the event which shouldn't be modified.

Proposing a change of time for the event.

s, t

This brings up_ the Start & End Time view. Christine may alter the Start Time, End Time, Time Zone or Date of the event. She wants to suggest shifting the event _back by one hour, so that the event now starts at 3:00 PM instead of 2:00 PM. She taps on the Start, and uses the Date & Time ticker at the bottom to modify the start time to 3:00PM. As she changes the time, it gets reflected in the corresponding sections in the top half of the screen. The End Time automatically shifts back by one hour to 4:00PM, so as to maintain the duration of the meeting. She is done, so she taps on the Done button.

She returns back to the Propose Change view. At the bottom, a summary of changes made by Christine is shown. She is happy with the changes and taps on Done to send the proposed changes back to Alice.

The ticker is used across standard mobile devices when it comes to selecting date and time, so it helps with external consistency. The use of* Today as opposed  to just the present date helps to reduce the need to *recall what the day is.

By highlighting Today, it allows the user to quickly be oriented as to what the present day is, and allow them to quickly select the next day or previous day because of this frame of reference.

The use of the ticker automatically ensures that times that are chosen are valid (i.e. selecting a time and data in the past is not possible).

Receiving a notification for a proposed change to the event.

u

Alice receives a notification, and taps on the Notification Icon to view the list of notifications received. She sees Christine's proposed change as the latest, unread notification. She taps on it to view the details of the changes.

Learnability issues similar to those covered previously.

The user can easily reach the Modify Event menu by tapping on the entry in the list.

Safety issues similar to those covered previously in the Notifications Menu.

Reviewing proposed changes to event

v

This brings up the Modify Event view. Alice can see that the Time of the event has been modified, because there is an *-asterisk next to that section. The modified time as proposed by Christine is now reflected in that section, and at the bottom, a summary of proposed changes by Christine is shown. Alice is happy to shift the event to 3:00PM and clicks on Done to resend the new invitation out back to Bob and Christine.

The *-asterisk and the message at the bottom is externally consistent with its usage as a indicator for change.

The event Start Time and End Time was changed and reflected automatically.

Safety issues similar to those covered previously in the Create Event Menu.

Confirming the event

w

Bob sees the updated invitation and accepts it. 

Christine is delighted that her proposed changes didn't cause any problem at the event is still going ahead as planned.

Alice is able to view the confirmed event in the Events Listing menu. A Tick graphic is located next to it to indicate that all members of the events have responded to it and are attending it.

The Tick graphic helps to indicate that responses have been added.

The user can easily access the Modify Menu by tapping on the entry.

The use of the Tick also saves the trouble of having the user view the event through the Event Menu in order to see who has responded.

Changes can be proposed by tapping the entry, which will bring the user back to the Modify Event menu.