...
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).
...
Issues | Users | Possible improvement | Severity | ||||
---|---|---|---|---|---|---|---|
Could not post a tweet because | User 1 | Create independent data base for tweets. | Minor | ||||
When navigating Google Earth, tried to use mouse | User 1 | Support mouse navigation alongside keyboard controls. | Minor | ||||
Was confused when taken to teleport's navigation | User 1 | Make it more obvious that person's live chat window moves | 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 | User 2 | Include a separate button for the tweet option. | Minor | ||||
Audio distortion. The user had to refresh the browser to | User 2, | 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.