...

The HTML provided our skeleton for everything that was static: each of our bins, including the semesters and our requirement bins, along with their headers and titles.  Then everything else (our classes) were added dynamically through the Javascript; this was done to facilitate the functionality that would be added to each object such as dragging, clicking of the information button, and excluding the semesters a class is not offered.  .  Lastly, CSS was used to pick out classes and unique elements and to give them the look and appearance that we wanted.

There were not many design decisions that occurred in the implementation level that affected the usability of the design.  A few of the implementation decisions made were the use of JSON dictionary to hold all of the information for the classes rather using a server-side programming to dynamically pull information.  This greatly simplified our implementation by allowing us to focus on the usability aspects of our project and not have to worry about our back-end.  It facilitated us having all of our information parsed and working, without having to worry that the server may return something wrong.  This did lead to a small problem where at every update to the dictionary we had to re-add the biology classes, which were parsed by themselves, leading to one of our bugs in our current prototype.  Another design decision made was the use of the JQuery Draggable and Droppable.  It made this feature very easy to use and implement, though in slower computers there is a slight lag, from the mouse and the location of the element.  They may be different if we implemented draggable and droppable ourselves, but it would have added complexity at re-inventing something that already is successful and works.

Evaluation

User Testing

Users were selected from our network. Because QuickPick is currently focused for students in 6-3, we selected MIT students who were 6-3. Two of them knew they wanted to major in CS when they arrived to MIT. One of them was course 2 first, and then switched to course 6. This is representative of the user population of QuickPick in its current state. When we expand to other majors, our users testing population should be expanded and diversified to reflect this change.  There was no demo, but rather we gave them the tasks (included below) and access to the live site on one of our computers. 

...

• GIRs are red, course requirements are green. While, functionally speaking, the colors make no difference, picking colors not linked for colorblindness in 5-7% of the male population might be better. 

Reflection

The iterative design process was really helpful in making many of our design decisions and narrowing our scope.  Through talking with many users, MIT students, we were able to find out what they cared about and what they were interested in in a four-year planner.

Our initial design, we quickly realized, was too large in scope.  We wanted to create a four-year planner, then allow users to create their schedule for the current semester, and finally share their schedule with friends.  We quickly realized that when people wanted a four-year planner, they care less about these other features, and thus we narrowed our scope to just a four-year planner that would be easy to use and learn.

Throughout our process, we continuously went through friends to help us make some design decisions for our projects.  We would ask questions like "what kind of interaction would you want?" and many other questions to get feedback that would help us through our design.

From our paper prototypes, heuristic evaluations, and our user testings we saw flaws in what we thought was intuitive was actually not for the average user.  From our paper prototype, we kind of mentioned the feedback that would happen from their actions, making it appear a bit like magic.  When it came time to implement these in our prototype, we quickly saw that it would not be as easy as we thought and not as intuitive for why these things would occur.  Our heuristic evaluations helped us see flaws in some of our design.  We got answers to questions we had like "Does it make sense to press this button to get information, or to return the class?"  Lastly, our user testing showed us some things that we took for granted.  Because undergraduates are used to using Course Numbers, we used this "shortcut" everywhere when referencing a class, sometimes forgetting about the class name which is equally important especially for classes that you do not know of or about.

If we had to re-do our project, I do not think we would have changed our process too much.  The work we did to get feedback from users and friends was invaluable and greatly helped shape our design.  As we completed our deliverable though, we did not get to implement everything exactly as we had hoped, and maybe we should have gotten feedback on what was most important to represent for the usability of the project.