Design
Navigational Buttons
For our final interface design, we decided to stick with our initial idea of placing the buttons used for navigation along the top of the screen in “chronological order”, meaning from left to right, we have previous classes (past), current registration (present), and required courses (future).
Both the comments from our TA in GR4 and the comments from our classmates in HW2 stated that we needed to rework the navigational buttons because they were too difficult both to read the text and to see the current status of the data below the buttons. As a result, we made dedicated buttons with a colored background behind them. When not active, the buttons have a red background. When active, the buttons have a green background. This makes the instantaneous status more visible to the user as shown below: 
Above: User is currently browsing all classes.
Above: User is currently browsing previously taken classes.
Search
Another design decision we made came from our users in testing and from our classmates in HW2. In our GR4, we hadn’t done anything with capturing keyboard strokes to use in navigating the interface. For GR5, we enable searching by hitting the enter key. Users mentioned that it is a standard for websites to complete a search query by striking the “Enter” key (gmail search, etc.) so we added this functionality (in addition to being able to search by typing in a query and clicking on the “Search” button). Below is a screenshot of a user searching for 6.005:
Displaying Course Information
Our users in testing mentioned that we need to have a better method of displaying the significance of the data they are viewing. Specifically, we needed to (a) always show users the status of a class whenever it is displayed (already taken, currently registered for, not registered for) and (b) show users when course information is being viewed. Below are screenshots showing the decisions we made for both:
Above: When all courses are listed, the buttons to the right of the course name reflect the status of the class (“Completed” if taken already, “Remove” if class is already in current registration, and “Add” if class can still be taken).
Above: Course information about 6.00 has not yet been loaded (by selecting the “plus” sign)...
Above: Course information for 6.00 has been loaded.
Implementation
Front End
The front end of the website was created using HTML and Javascript with CSS for formatting. Our first computer implementation (GR4) used an iframe to display the content. For GR5, we decided to ditch the iframe and instead use HTML divs in the page to dynamically update the page content using Javascript.
When the content of the page is loaded (all classes, previous classes, current registration, required classes, or search results), we are able to access all parts of the class (expanded info, buttons, etc.) by the name of the class. With this implemented, it is very easy to edit the data displayed in the content area. We can remove a class to the displayed list, change the text on the buttons, etc.
Another key change between GR4 and GR5 for the front-end implementation side was showing the registration status of a class in the button to the right of the course name. If the course has already been taken, the button displays “Completed” and is disabled. If the course has not yet been taken but is on the registration list, the button displays “Remove” and if clicked on will remove the class from the registration. If the course has not yet been taken and is not on the registration list, the button displays “Add” and if clicked on will add the class to the registration.
Another feature worth mentioning from the front-end side of implementation is that the courses are sorted by course number. This keeps the order of classes consistent no matter the order of adding and removing (when viewing the current registration page).
Back End
Data about courses and users was stored in a MySQL database, which we queried using PHP. We decided that the most appropriate and implementable solution to dynamically interacting with the database was to extract information from the database using PHP, then pass it to Javascript so that we could modify the displayed content.
Because of a combination of lack of time and the particular implementation we chose, we decided to leave out search filters and wildcards, since those would require an additional layer of implementation inserted between user actions and the database.
Evaluation
We decided to test with users from different courses and years (in order to obtain a fairly representative range of user experiences) and with somewhat varied computer experience. Our users were:
Alpha: civil engineering junior with language concentration; often uses desktop applications for data entry as opposed to web tools
Beta: physics senior with music concentration; frequently uses google docs and web tools; has some programming knowledge
Gamma: political science sophomore; generally does not use web toolsAll users had previously used the student subject listing for preregistration. Only Alpha had previously used the Course Picker tool. Everyone was given the same briefing, as described above, and no preliminary demonstration was given.
Briefing
ManCourses is a website for MIT students to select their classes. This system is an improvement over the current MIT course management system because users have:
- Integrated course evaluations,
- A list of courses they have taken in the past, and
- A list of required classes which need to be taken in order to graduate.
You are an MIT student who is using the website for the first time. Please following the following scenario:
Tasks (Scenario)
- View your current registration and remove one of the classes.
- Add a required class to your current course registration.
- View information about a previously taken class (6.01).
- View information regarding 6.005 (Elements of Software Construction) by using the “search” functionality.
Usability Problems
real-world convention / visibility (minor)
Problem: At the beginning of usage, Alpha attempted to click on the shaded table cell surrounding the "Required Classes" button, instead of the button itself.
Solution: It might be preferable to make the entire partitioned area clickable. Alternatively, in keeping with our original concept of the top partitions as physical folder tabs, we could have clickable images of folder tabs.
aesthetic (cosmetic)
Problem: Beta stated that the overall feel of the website was amateur, and that changing fonts and layouts might help it look more professional. Beta also criticized the green and red color scheme.
Solution: We could spend more time improving superficial UI elements such as fonts, color schemes, layout flow, etc.
recognition / visibility (minor)
Problem: All three users wished that classes in each course could be browsed. Beta attempted to do a wildcard search (“21M.3*”), but that feature was not implemented.
Solution: Simply set the default "Browse" content area to contain a list of majors, each item linking to the search results for all courses in that major. Additionally, implement wildcard and conditional searches.
visibility (minor)
Problem: Alpha and Gamma did not realize for some time that the calendar icon opened a calendar with the current registration. (It turned out later that neither of them use online planners such as Google Calendar.)
Solution: Make the icon larger or more obvious, and add a bevel, border, or other design element implying its clickability.
efficiency (minor)
Problem: All users appeared to grow frustrated with having to click so often to expand course information.
Solution: Have more information than just the course title available in the unexpanded summary.
efficiency (minor)
Problem: Alpha and Beta complained about the variable placement of the Add / Remove / Completed buttons.
Solution: Give the buttons a separate column, or place them on the left instead of after course titles.
efficiency (major):
Problem: All three users complained about the lack of search filters, which is a prominent feature in the MIT subject listing search.
Solution: While the addition of search filters is not functionally difficult to implement, designing a good UI will take some time. However, search filters are probably essential to a good course registration tool.
Reflection
The iterative design process provided three main learning paradigms that helped us to become better developers: (1) early designing provides easier changes, (2) iterative designing is more likely to find bugs, and (3) using iterative design helps develop a more detailed framework.
We came across the first point when we were working on GR2, the storyboards. It was clear that each of us had a different view of what could be improved and used in the project, and being able to play with the different ideas allowed us to combine the ideas that worked well, and leave out the ideas that were not as well fleshed out. For example, one of our members wanted to use a split screen for search, but we decided to incorporate search as a separate tab. If we had started developing a computer prototype from the beginning, our design would have been majorly flawed, and many of the ideas we came up with for the final product would not have been implemented.
Similarly, developing using iterative design allowed our team to find large bugs early on. This was especially clear when we tested GR3, the paper prototyping on our classmates. There were a lot of ideas that were not fully developed, and the major flaws stood out crystal clear. If we had not used this step to test, we would probably have to go over our code many times in order to make our ideas concrete.
Finally, the iterative design allowed us to understand our project to a greater depth. In particular, we were unsure how the structure of our project would turn out. Using the paper prototyping and computer prototyping allowed us to see how the different objects in our interface would be interacting, and how those interactions would affect the user’s experience.
If we had the opportunity to re-do our design, the first thing we would do is take the iterative design more seriously. For the majority of the work, our group was skeptical as to how effective designing in iteration would be, as our previous experience did not deal with programming in steps. However, we soon found out how useful this design system worked, and we would have definitely placed more emphasis in having better prototypes.
Furthermore, our project seemed to be very simple on a superficial level, but the back-end ending up being hell. We would probably choose a project that focused more on the user interface and much less on back end. This would help us utilize more aspects of the class in our design, and take away the aspect of taking time on a back-end. This would have placed more emphasis on GR4 and much less on GR5.