The initial few weeks were spent just on planning and thinking about the representation of information, the database structure and the architecture. We discussed many possible features in those meetings - those that we would want to include as well as those we wanted to support so we could easily add in the capability later. As far as the database structure was concerned, taking into account all the different cases beforehand definitely paid off. That way things like cross listed courses were taken care of in the database. Even so, we had to make changes to the structure along the way, the most drastic being the shift to thinking of a pursuit as a member of a group of it's own instead of being associated with a pursuit code.

We also spent a lot of those meetings thinking about the GUI design and making rough sketches of what we wanted so that our design would be able to support all of the features that we would ultimately like to include.

One of the challenges that we encountered was figuring out how to access the Princeton LDAP server securely. As of now, we aren't able to create a secure connection, either using ldaps or OpenSSL. Ultimately, we decided to create our own password storage system in the database under a hashed field. If we eventually do release the product, our intention would be to authentication using the LDAP server.

Despite the attention we gave to the database structure in the beginning, we ended up needing to change the database structure to make the implementation of the report generator possible. While it was a significant change to be making at the last minute, it was necessary.

The modularization of the program structure helped a lot. At various stages, major components were restructured or reimplemented but since it was so modular, these changes didn't affect any of the other components.

The progress that we made on the project differed slightly from the schedule that we initially laid out in our Design Document. Firstly, we ended up spending longer in the planning phases than we anticipated, and started coding later than we were expecting. The extra time planning was largely spent on finalizing the architecture and the format of the PHP interfaces, and almost definitely saved us time later when we did begin to code. Once we did begin to code, a basic prototype came together fairly quickly. In the final weeks, we had anticipated that much of our time coding would be spent adding features. While this was the case, we also spent a significant amount of time changing bits of the implementation that we realized could have been more efficiently done.

Eirik Bakke

Surprises, etc.
  • There are still many constraints that cannot be elegantly specified by the current format of prerequisite expressions (see Installation). Deciding on proper additional language constructs cannot be done until much more work have been spent trying to specify a large variety of requirements from the Undergraduate Announcement.
    Important design decisions

    Arthi Ramachandran

    Spending a long time with the design in the initial phases definitely paid off. While in the beginning, it felt like we weren't getting much done since no coding was taking place. When we finally did start coding, it was relatively easier because we had a good idea of the program structure. Coming up with a prerequisite string expression that would accurately define prerequisites was not easy though I don't think we expected it to be. Just trying to go through the Undergraduate Announcement and understand what they were trying to say was tedious. Trying to develop an easy to understand language to define prerequisites accurately was even more so.

    There were several changes to the database which were made when we realized the existing structure wouldn't allow for certain features. However, since it was a learning process, I think it was inevitable. Having the importing being done with a single script made it fairly easy to change and test the database structure without too much difficulty.

    In retrospect, what I would have liked to have done differently: I think I would have liked to work on more things in various parts of the code so I could have been exposed to more of the coding going on behind those features.

    Alison Reynolds

    Personally, there were a couple parts of the project that I found to be particularly notable. Firstly, this was the first project I've worked on that required the use of source control, and group development of a product. I felt as though our group worked pretty well together, and that key was communication within the group. While we found it very challenging to find times when all of us were available to meet in person, the use of e-mail (at times almost to excess) enabled everyone to pretty much be up to date with significant progress and changes being made in all components of the system.

    One of the aspects of the project that I really enjoyed, but also found to be a challenge was the number of new tools and languages being used on the project. I worked on pieces of the back end, the interfaces, and the front end, and was not familiar with HTML, Javascript, or PHP before doing this project. While I did enjoy learning all of these, it did mean that often mean that a lot of time was spent looking up particular commands before any code was written. One thing that I would have done differently if I were doing this project would be to spend more time initially looking at language tutorials before beginning to code, rather than starting to code and looking up commands as I went along. While it would have taken more time initially, I think having a more fundamental understanding of the languages before beginning to code would have made coding more efficient overall.

    David Weiss

    I spent almost all of my time working on the GUI, in Javascript and PHP. If there was one thing I go back and tell myself from the beginning, it's to always read the documentation first. HTML/CSS/Javascript is a really tricky combination; the usual debugging technique of "tinkering" is guaranteed to make things worse. If the CSS isn't displaying properly, it's most likely because you're not using a property correctly, or you don't know that a given browser doesn't support the property you're trying to use. I finally learned my lesson a few weeks into the project, and realized I needed to rewrite the GUI from the ground up. And this time, I would need to spend as much time reading documentation on the Scriptaculous and Prototype libraries as I did programming. Ultimately, taking the time to step back and just read pages of documentation and tutorials saved me an enormous number of headaches later on. I was able to fully take advantage of Prototype's awesome utility functions, and I don't think I wrote a single for loop in the entire 1000+ lines of code.

    In terms of design lessons, I think the lesson I learned the most was simply: listen to your peers and users, even if it means throwing away something you spent a lot of time on. It took me hours to get a "Point" style floating design, with a fixed with page seeming to float above a grey background with a drop shadow effect, but we found that it ultimately didn't have enough room for all the information we needed to display. I didn't want to change it at first, but when I finally gave in, I was amazed at how much easier to use the program felt.

    Finally, if I had a chance to redesign the interface over again, my main strategy change would be: plan not just the layout and visual elements from the start, but the architecture, too! The GUI ended up with almost as many layers of complexity as the rest of the modules, but I implemented it in bits and pieces without sitting down and writing out interfaces first. Once I had that, then I have a few tips: wrap everything in a javascript class and build lots of optional function parameters that can be passed in to add functionality you may not anticipate in the future. Where ever possible, use functions that don't depend on a fixed number of data attributes, and if you ever--EVER--copy and paste javascript code put it into a separate function.

    Known Bugs / To-Dos

    Throughout the project, we've maintained a list of bugs and features we'd like to add in the future. It is included below. We hope that by next year we will be able to integrate our system with Point, and by that time would hope to have these features implemented.
    Bugs (or things that appear to the user to be bugs)
    * Report generator does not properly simplify &-expression with single branch, e. g. (a & 1)
    * The front-end, when substituting group titles for group codes, must output something like "()", without a link, if the group code does not actually exist, otherwise it seems like a bug (it is actually just an invalidly entered prerequisite expression).
    * Import script must not try to parse prerequisite expressions.
    * Schedules past a certain report size don't work
    * Secure LDAP authentication or alternative login method
    * Allow entering of course codes in debug script so that Kernighan can try out the prerequisite expression system / report generator.
    * Don't display course preqreqs if satisfied
    * Add course counting to BSE/AB requirements (36 courses needed, etc.)
    Don't bother for now
    (feel free to move stuff out of or into here if you want to implement something or don't have time to do something else)
    * regwebURL input
    * Fix web unsafe colors
    * Create generic courses
    * Warning for future courses - disclaimer
    * Components accessing database must be more robust with respect to special character escaping and such.
    * Printer friendly page
    * Auto add
    * Order should be changeable
    * Add back in delete button(?)
    * Replace cookie stuff with session stuff.
    * Load only one page of search results at a time
    * Limit maximum number of AJAX requests.
    * Semester-only scrollbar