View Source

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.


	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. Contacts panel: this panel allows one to make video calls, send e-mails, add contacts, see if contact request was accepted. To maximise efficiency we provided an option of searching contacts by name. To improve learnability we used real-world metaphors for icons. The icons are also externally consistent.
	Live vide chat mode opens two videos: the person contacted appears in the main window, while the person calling can see himself/herself appearing on the side bar.
	We also support an option for text messages, giving users the flexibility to choose depending on context and personal preference. During the user testing we found out that some users like typing things in along with speaking. Messaging is also useful when speaking is disruptive to other people around or internet connection is not good enough.
	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.
	Clicking the share button brings up a dialogue box. Sharing text messages is implemented through twitter, therefore, the user has to have a twitter account to be able to post messages.
	The interface also allows to post and share YouTube videos related to a location.
	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. Sharing spatial location through a post allows for both, reviewing a location while talking in a video chart and visiting a location anytime after the post has been added.
	The offline 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. Navigation controls are differentiated by colour. Navigation is only possible through keyboard controls. Through paper prototyping we determined that the best location of the legend explaining the mapping of actions to keys is bottom of the window. We tried to make it as clear as possible for the new users while at the same time unobtrusive for regular users.
	Showing a specific location offline. 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.
	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.

Implementation

Technology:

1. Django (backend server)

2. Postgres (backend database)

3. Node.js (realtime connection backend)

4. Socket.io (chatserver, realtime notification)

5. openTalk and webRTC (video streaming)

6. Google earth APIs (teleport backend)

Primary Modules:

1. Request Handler (handles all HTTP queries and delegates the work to the appropriate modules)

2. BookKeeping Module (Account Management, Feeds) -- takes care of user registration, login, feeds etc..

3. Teleport Module (Google Earth + Camera) -- takes care of all the navigation control and the google earth view

4. Teletalk Module (chat server) -- takes care of all chat sessions

5. Notification Module (for realtime notifications and relaying) -- an abstract layer to allow notifications passing and relaying in realtime

Source Code: https://github.com/abhardwaj/teleport 

Limitations that affect usability:

The webRTC doesn't remember user preferences over non-SSL transport. We couldn't get a SSL cert and thus it has an usability implication -- user needs to authorize Teleport to access camera and audio on every page. We will fix this soon.

Evaluation

We did our user testing in live environment. We invited our users to join Teleport (email invitation) and waited for them to join and start the video chat. We counterbalanced the scenario in such a way that some users got to initiate the video-chat first while some just accepted our video-chat invite. We ensured same counter-blanching for teleport, in some cases users followed our navigation and in some cases users took the lead in teleporting. We asked some subjective questions in the end and most users looked *very* happy with the system. We tested with six users locally so that we can observe their actions in person and we tested the interface with 4 users in remote locations. For simplicity, we will present only four users (two local -- two remote).

Tasks

Set 1A (Accept Teleport register invitation and initiate a new video-chat)

1. Accept an invitation to join Teleport

2. Send a teletalk invite to us

Set 1B (Register to Teletalk and join a video-chat)

1. Register to Teleport

2. We sent a video-chat invite and asked them to join the chat

start the chat.

1. While chatting accept an invite to view a location.
2. Explore the location using provided controls and add a tweet.

Set 2A (Teleport to a location - active)

1. While chatting send an invite to teleport the other person
2. Navigate the other person -- show him the places around and then transfer the control to the other person.

Set 2B (Get teleported to a location )

1. While chatting accept an invite to view a location.
2. Explore the location using provided controls and add a tweet.

Set 3 (Tweet/Share/Video/Image)

1. Tweet a location
2. Share a location

3. Add video/image on a location

Set 4 (Offline Exploration)

1. Explore the location from the notifications in the Feed

User summaries

User1 (local)

Course 4 Graduate
Age 26
Female

Was able to use the intrface effectively
Commented that having personal live video chart on the side bar and another person's video in the middle is very convenient.
Said her Mum would really enjoyed Teleport.
Overal found the system is intuitive to use.

User2 (local)

Course 6 Graduate
Age 24
Male

"I love it -- it's very interesting app"
"I will use it for my vegas trip planning next week (this realtime google earth sharing feature is so amazing)"
"You should release it as a product -- it's a very useful app"
He was able to use it without any instructions.

User3 (remote)

Location: Pune, India

Age, 45

Male

Was able to use the interface effectively
"I like it better than Skype. I will use this from now onwards"
Loved the teleport feature.
Likes Keyboard control much better than mouse controls
Overal found the system is intuitive to use.

User4 (remote)

Location: Pune, India

Age, 41

Female

Was able to use the interface effectively
Was a little shaky with navigation control but loved following when the other person controlled the teleport
Can you go to that left building (very very curious).
Logs suggest that she was playing with the teleport feature in offline mode after the session for many hours.
Likes it better than Skype.

Discovered usability issues

Issues	Users	Possible improvement	Severity
Could not post a tweet because was not registered on twitter and did not wish to.	User 1	Create independent data base for tweets.	Minor
When navigating Google Earth, tried to use mouse and did not figure out immediately to use keyboard controls.	User 1	Support mouse navigation alongside keyboard controls.	Minor
Was confused when taken to teleport's navigation window because did not know if the other person is still in chat mode.	User 1	Make it more obvious that person's live chat window moves to the sidebar, when system's mode changes.	Minor
When tried to speak a location, there were multiple errors.	User 1	Better speech parsing and understanding capabilities.	Minor
Keyboard does not have Page Up / Page Down.	User 2	Choose a different universal key.	Minor
The tweet option appears only when the user clicks the share button.	User 2	Include a separate button for the tweet option.	Minor
Audio distortion. The user had to refresh the browser to restore regular voice.	User 2, User 4	Most likely caused by internet connection.	Minor
Lag in Navigation Syncing	User 3, User 4	Because of bad internet connection on their end	Minor
Approving camera access	User 1, User 2, user 3, User 4	We need to buy SSL cert and put this on HTTPS	Major
Navigation Keyboard	User 3	Many Keys, difficult	Medium

Reflection

For our group, brainstorming and sketching ideas separately and then discussing them together as a group really expanded the amount of options and possible solutions we considered.
We feel like early paper prototyping was very helpful to us understand usability, efficiency and learnability issues.
During user testing we observed plenty of user behaviours that we could not have predicted ourselves.
We found that paper prototyping particularly helped us to find the most intuitive location for buttons and navigation controls; we used the same layout that we finalized in the paper-prototyping.
We think, we didn't scope our project well -- this project was pretty complex, required some serious engineering and the implementation time we had (for computer prototyping) wasn't enough. We got pretty bad grade in GR4 but we believe that it was a good idea to focus on the individual pieces rather than the layout. We wanted to ensure that we have all the technology we need for building this system. Our computer prototype did't connect the individual pieces together and while the TA viewed it as an incomplete computer prototype, we think we took the right approach.
We loved the class, and it definitely taught us how to approach building good user interfaces.