GR6 - User Testing

Design

The Home Page.

This is the homepage. In the main panel there is a display of the most popular streams, each stream consisting of a screencap, stream title, and channel title. On the left there is a column with various stream categories. Clicking on these labels will bring up a thumbnail (screencap, name, user) view of the live streams from that category. Some categories have subcategories; clicking on these categories causes the left panel to update with the subcategories. Clicking "Home Page" takes the user up a level, in the case of subcategories. There is no case where there is more than two levels of subcategories.

Also, clicking on the "StreamBrowser" title itself takes the user back to the home page. The user can also use the back and forward navigation buttons on the browser to the same effect.

The streams in Gaming

On the top right there is a search box. Typing search terms into the box and then pressing enter brings up a thumbnail view of the streams that match the search. If no streams are found, a message saying that no streams were found appears instead.

Searching for "starcraft"

Clicking on any of the streams in the thumbnail view takes the user to the embedded player for that stream. Underneath the embedded player is the description of the stream.

Watching the NHL playoffs

Whenever the user watches a stream, the stream thumbnail appears in the bottom "viewing history" panel. The streams here are ordered from most recently watched to least recently watched. Clicking on any stream in this panel takes the user to the embedded player. In between the first and second screenshots above, the user watched the NHL Playoffs stream, so it appears in the Viewing History. Clicking on the "Clear History" button on the right side of the Viewing history bar clears the viewing history.

Finally, we have a neat little spinner for when the page is waiting for a request to a third-party server:

Waiting for the "football" search to go through

Implementation

StreamBrowser is implemented mostly in javascript with some php. Everything is implemented in one page, and different things are ajaxed in and out based on the request that is sent. Finding the streams are done by making calls to third party sources (currently only justin.tv api). The viewing history is stored as a cookie on the user's browser. This allows the history to work without having to go through a login system, but on the other hand if a user has multiple computers then the viewing history will not go with them. Since users usually don't want to make new accounts for small features, we feel this is a good tradeoff. It would still be possible to implement a login system later. 

Evalutation

Users

We took users from people that we live with in our living groups. They are certainly in our target population, especially the gamer population, who tend to be college-age and good with computers. However, our user group does not represent well older people that might want to use this service, as well as people who are more computer-illiterate.

User Brief

This is StreamBrowser, a site designed to help you find and browse live internet streams. Streams are grouped by categories and are searchable. We want to emulate the experience of TV channel browsing for internet streaming. Streams on StreamBrowser are provided by Justin.tv.

User Tasks

- Please find and watch any stream you want.

- Please find and watch a stream under the Strategy Games category.

- Please find and watch watch Artosis's stream (or another specific stream if Artosis was offline).

- Please go back to the first stream that you watched.

Usability Problems

Some users tried to drag and drop thumbnails around in the Viewing History tab. One user commented that the Viewing History tab reminded him of Youtube's playlist, and on Youtube you can drag thumbnails of videos around to reorder the playlist. Although we originally envisioned the Viewing History as a simple list, rather than a playlist, it would be good to implement dragging and dropping of thumbnails in the Viewing History. The solution to this problem would be to simply implement this feature.

Some users were confused that the stream video did not automatically start playing when reaching the page (one person took a full minute trying to find the play button on the embedded video player). We should try to make the stream video start playing immediately after loading, but this may be a restriction of the stream provider itself on the embedding of their player on third party sites (for example, embedded Youtube videos do not autoplay).

On some slower computers, our interface suffered a few bugs is display the css and js elements correctly. One bug was that there a noticeable delay between the end of the loading animation and the thumbnail display of results, such that the results page looks blank and empty for 1-3 seconds. This caused one user to click away from the results page while the browser was trying to load the data. Another rare bug was that the grid layout of video thumbnails freeze up and none of the results are clickable. The user who encountered this just had to refresh the page.

The last usability problem lies in the fundamental design choice to group stream by categories. Categories are at times limiting and restrictive. One user was not sure how to navigate to a particular stream because she did not know enough about the stream to narrow it down by categories (and did not see or choose to use the search box). Categories seem good for mindless perusing, but inefficient to finding specific streams. We also need to find a balance on how many categories and subcategories to display. Too many can overwhelm users; too few doesn't give the users enough information. We currently err on the side of too few categories (except for gaming and sports, which we expect our target audience to be looking for).

Positive Feedback

During our last round of user testing, we received a positive feedback as well as the usability problems outlined above. People overall tend to like our simple and efficient design. Because of the minimalist design, user tasks are done overall immediately obvious and quickly executed. The history bar was also intuitive and noticeable (we feared otherwise based on the feedback on the paper model). For users who are good at internet searching, the search box was something they found easy to use and efficient. Our loading animations were able to keep users patient as intended. Lastly, because Streambrowser eliminates the clutter of advertisement and chat, some users found it to be faster to use our site than Justin.tv and other similar sites.

Reflection

From the iterative process, we learned many things about computer user interface design, and looking back at our development process, there doesn't seem like there's any other logical way to go about it. It's important to establish some the start what we wanted our website to do, so that we can optimize the interface for it (GR1). If we hadn't done that, we would be faced with problems of clutter and inconsistency that plagues many websites today. The next step of the iterative process taught us that each developer has a different sense of what's important to an UI (GR2). During this process, we were able to come together and agree on the important aspects of the design that needs to be focused on.

The next phases of the iterative design process involves prototyping (GR3 and GR4). Although we learned about how paper and digital prototypes stress different design aspect in lecture, we didn't fully realize it until we prototyped. During paper prototyping, we ran into problems of communicating animation and state changes due to the static nature of paper. However we learned a lot about the importance of simple layout and information display during this process. During computer prototyping, we learned lessons in implementation. Some of the things we took for granted in design are not so easy to implement on a computer. Computer prototyping made us think about the practicality of interface design. Things like compatibility and graphic rendering were brought to our attention through this process.

Ultimately all the earlier steps of the iterative process leads up to the final implementation of  our design. Without feedback from experts (6.813 staff) and users, it's incredibly easy to miss usability flaws that seem trivial to the developers. There were also definitely features and affordances (or lack thereof) that we as developers skipped out of laziness that were later revealed to be important to the overall usability of our interface. Each step of the iterative process is like a reality check for us. It helps to guide us in the right path of design and implementation and reveals what needs to be done.

If we were to redo the project, there would be a few things we could improve on. We could have spent more time in the earlier design phases of the project. We borrowed a lot of usability tools and design techniques were preexisting website. This is a good thing because users are immediately familiar with some parts of our UI, but these choices are not optimized for our tasks and is not too impressive or revolutionary. We also could have put more thought into the organization of data. Currently we are confined by the categories of Justin.tv, our source of streams, which these categories can be limiting and inefficient in some use cases. Lastly, our stream player is the generic embed player from Justin.tv, so it is designed for Justin.tv's websites. Because of this, its usability features do not completely complement StreamBrowser, and we should have thought about how to better integrate it into our interface.