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
*paste here*
Evaluation
*paste here*
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.