...
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. .
-If we could do it again, what would we do differently?
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-Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.