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.
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.
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.
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.
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 Features * 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 Data * 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