You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

GR6 - User Testing

Design

Implementation

We decided to build a Web application, so we didn’t have to worry about users installing software, but this exposed our UI to the limitations of CSS. For example, we initially designed the grade entry form as a full-screen sheet that has horizontal and vertical scroll-bars, and the first row and first column are fixed to offer context. CSS made this hard enough that we didn’t have time for it.

We built upon a pre-existing code base, which allowed us to focus on front-end improvements, but might have subconsciously biased us towards preserving existing functionality and interactions.

The site’s stylesheets are written in SCSS, and make heavy use of variables, mixins, and nested rules to reduce selector complexity, and to separate generally useful rules from page-specific and site-specific rules. The generic rules have been extracted into a Rails plug-in, so that they can be reused in other applications, and so that bug fixes and enhancements can be easily back-ported into the course management site. We preferred CSS3 features to JavaScript (for example we used CSS3 Transitions instead of the fade jQuery UI effect) so that we can benefit from hardware acceleration on desktop and mobile devices, at the expense of Internet Explorer users.

The JavaScript is driven by markup, using the HTML5 data- attributes. This approach makes it easy to keep widget behavior consistent across the different features, because the JavaScript for an interaction is in one place, and because the easiness of adding a behavior greatly reduces the danger of developer laziness. However, the developing the JavaScript behavior library had a toll on development speed, and in turn on the UI’s polish.

We make liberal use of AJAX, because our Rails application will be deployed on a 4-core server where each core can respond to most requests in less than 10ms, so overloading the server is not an issue. This will need to be revisited if the site grows to Stellar’s size.

Evaluation

Users

Briefing

Tasks

Observations

  • User 1:
    • Task 1: Immediately got attracted to the home news page. He scrolled down to the bottom of the page, and selected Problem Set 1. He didn’t see the place to post grades. After couple seconds, clicked on Grading. Used Ctrl+F to search for Chad. Forgot to switch to Problem Set 1, but since the maximum grade was less than the point to enter, he soon found out, and switched to Problem Set 1. He used tabs to switch between blanks. He asked about whether there is a submit/save grade button. The facilitator explained that the system does auto-save.
    • Task 2: Before Task 2, he tried on his own to type in the textbox, and found the system does filter. Task 2 went very smoothly. He searched the names in the box, and used tabs to switch between blanks.
    • Task 3: He first clicked the dropdown menu for switching problem sets on the grading page, then searched under Grading dropdown menu. Quickly he clicked on Homework, and clicked on “+ Homework”. The rest of the task went smoothly except he got confused about Name and Filename, but soon he corrected that.
  • User 3:
    • Task 1: The user was able to complete the task with some difficulties. He went up to teacher, chose the grades spreadsheet, and chose the appropriate parameters, but couldn’t enter the grades. He then noticed the grading menu and completed the task without difficulties from there.
    • Task 2: He didn’t have any problems with this. Having seen the page from the previous task, he just started entering the grades, using the return key to advance between fields.
    • Task 3: Immediately found the +Homework menu and added the homework without any difficulties.

Reflection

Because we already had a functioning product, we thought that we could focus more on coding the front-end features that we wanted to perfect through this course. Unfortunately, we didn’t take into our risk consideration the fact that our back-end would have to change, which turned out to be a bad decision. Our back-end had to change considerably to accommodate the features that arose from the user interface design process, which took a lot of our time away.

We decided at the very beginning to focus on a few core features: assignment creation, grading, and submitting. We wanted to focus our attention on this small set of very important features to perfect the user interaction with them. Having said that, we feel happy with the way the features turned out, and plan to work on the UIs of the other features, as this website will be in use next semester in 6.006.

The feedback from the paper prototype, from HW2, and from Anh has helped us tremendously, although there is a lot of overlap among the different feedback. This overlap helped us decide which problems to tackle first, because multiple people complaining about the same thing means that it’s a problem that is noticeable.

We evaluated the results through this GR6 and through our own interactions with the final product. We learned that we still need to tweak a few small things from the user studies we conducted for GR6, like, for example, allowing the TA to enter grades from the “Teacher” menu as well as the “Grading” menu. We feel that the product is leaps and bounds ahead of our initial prototype, and that it is ready to be used in production with an MIT algorithms class. The class will provide a lot more feedback for the next iteration of the project.

  • No labels