Final Design
The primary focus of our design was to create an application that allows parents and close friends to experience distant locations where there loved ones live or travel. Prioritising simplicity and intuitive understanding of the system's use, we designed layout that consists of one main active window and a side bar. This layout is externally consistent with Skype but differs in its priority to create an interface that allows to easily share and explore spatial locations using Google Earth.
|
|
|---|---|
|
To start the system the user is asked to log in. We tried to keep the page as simple s possible. For returning users there is an autocomplete. |
|
The new users are required to create a new Teleport account. |
|
The implemented layout consists of a panel on the right that contains mode controls, main window and a heading bar. The light background is intended to be unobtrusive but communicative of the main purpose of the application. Through our prototype testing we observed that the users were mostly drawn to the main window and found it difficult to access controls from the top bar. We, therefore, located all the necessary function buttons within the main window and mode controls on the right. It is only utilities that are located in the top bar. |
|
Feeds panel stores all the posts made. Feeds are sorted by date and time. When clicking on the feed the user is taken to the Google Earth navigation window. To improve efficiency we provided a search bar. |
|
The Teleport mode is activated by either clicking on a feed or by clicking Teleport on the right hand side panel. To transfer to a location the user can either type in a location, or, alternatively, speak. Throughout prototyping stages we found it is important to provide the possibility of speech input because elderly are part of our targeted user group and for them it might be easier to use speak a location. |
|
Showing a specific location. When the user navigates in the shared location, the view is updated for both participants in the chat allowing users to explain, point and make comments interactively, while also seeing another person in a video chart. |
|
When clicking a share button a window that allows to tweet and post appears. During paper prototyping one of the users raised concern that there should be a save button because otherwise it is hard to be sure that the tweet has been saved therefore we added the save option. |
|
Live vide chat mode opens two vide: the person contacted appears in the main window, while the person calling can see himself/herself appearing on the side bar. When changing to the Teleport mode the video the person one is talking to is relocated to the side bar, underneath the personal video. This gives a feedback for the user that when taken to a different mode, another person is still on call. Seeing another person while navigating a map also provides additional visual clues and creates a more intimate conversation. |
|
|
|
|
|
|
Implementation
Map + Google Earth (Teleport)
Profile + Account Managenent
Location Based Sharing (Tweet/Post) + Feed
Backend Database + Webserver
Chat Server (Video, and Text both).
Backend for managing multiple sessions and connections
Infrastructure for Notifications.
Evaluation
Tasks
Set 1 (from perspective of a person making the call and sharing a location)
1. Accept an invitation to join Teleport and start the chat.
2. While chatting accept an invite to view a location.
3. Explore the location using provided controls and add a tweet.
Set 2 (from perspective of a person receiving a call and viewing a location)
1. Add a contact and on confirmation make a video call.
2. Share a location.
User summaries
User1
Course 4 Graduate
Age 26
Female
- Commented that having personal live video chart on the side bar and another person's video in the middle is very convenient.
- Said her Mom would really enjoyed Teleport.
- Overal found the system is intuitive to use.
User2
Course 2 Graduate
Age 23
Female
User3
User4
Discovered usability issues
Issues |
Users |
Possible improvement |
|---|---|---|
Could not post a tweet because |
User 1 |
Create independent data base for tweets. |
When navigating Google Earth, tried to use mouse |
User 1 |
Support mouse navigation alongside keyboard controls. |
Was confused when taken to teleport's navigation |
User 1 |
Make it more obvious that person's live chat window moves |
When tried to speak a location, there were multiple errors. |
User 1 |
Better speech parsing and understanding capabilities. |
Keyboard does not have Page Up / Page Down. |
User 2 |
|
The tweet option appears only when the user clicks the |
User 2 |
Include a separate button for the tweet option. |
|
|
|
|
|
|
Reflection
- Brainstorming and sketching ideas separately and then discussing them together as a group really expanded the amount of options and possible solutions we considered.
- Early paper prototyping is a good way to figure usability, efficiency and learnability issues.
- Because paper prototyping is quick and easy, it allows to iterate through many different design options. Paper prototyping particularly helped us to find the most intuitive location for buttons and navigation controls; find out safety issues (e.g. confirming that tweets are being saved); because the paper prototype was to scale we got a good indication if the layout works well.
- The drawback of a paper prototype was that it did not allow us to foresee many implementation challenges, accurately test typography, colour schemes.