I just realized how futile it is to try to create a "franchise" script. Originally I kept all the school data separate, but this is going to be pretty pointless; even if another school has an interest in using our script, there are enough differences in the way classes are assigned ... argh.

I just realized that I can completely redo the way title additions are done assuming we get a full book listing from Student Stores.

Basically when you input your class dept and class name, it will cross check against the book list (which will be in our database) to pull out the full listing of books that are being used.

On the second page you select the book, or you can input the title yourself. This removes my matching algorithm (which would scale HORRIBLY on 1000+ books) and would allow for more standardizations.

If we also get the book listing, we can also store the ISBN numbers, which we can then use Amazon's Web Services to offer links to students (both Amazon.co.uk and Amazon.com) for them to buy online. This might give us some referral money, which would be so very nice.

I need to start working on the professor search engine, as well as the general class search engine.

The new CampusExchange UI needs to reflect the three portions of the site distinctly:

1.) Textbook Exchange
2.) UNC Course Search Engine (with full class info, e.g. what is a requirement for what majors, what's a prereq for what, and what a class is a prereq for)
3.) Professor Search Engine (with commentability and grade distribution data)

I know almost no other schools, even if they launch the textbook exchange portion will get access to the latter two (maybe the last one, but not the third one), so this presents a problem: if I use static UI for all schools, a third of the UI will not be usable by other schools.

So what if I just use one static DB, but each webfront is a separate school? That is a likely use ... argh.

Not sure. So confused. Need guidance.