The New Plan

After research, thought, and discussion with Professor Nimeroff, I've formulated a plan that shifts the focus of my work. 

The mere scheduling aspect of the site is not novel, and the management of scheduling data in my own database would be extremely tedious and time consuming. So, I decided to look into the offerings of various calendar toolkits already available on the web. It turns out Google Calendars has all of the functionality that I would need for the scheduling aspect of the site. Google Calendars supports creation of new calendars, adding and deleting events (including recurring events), and viewing the schedule. The API for this toolkit is openly available online and will prove to be very helpful in harnessing this technology towards my project.

http://code.google.com/apis/calendar/docs/2.0/developers_guide_protocol.html#AuthAuthSub

While this calendar application will be very useful, my project will extend far beyond the simplicity of a generic calendar application. SalonBook is more than just a scheduler, it is an online salon management tool and salon community. There will be three distinct interfaces customized for three distinct groups of users. Salons, stylists, and clients will all create accounts and experience SalonBook is a different way. Below are the "use cases" that my site will set out to handle, organized by user type:

After thinking through all of the use cases, I had to revisit my data tables in order to capture all of the data I would need. The use cases dictate what data you will need access to at what points in a user experience, and so as stepped through the data tables as dictated by the use cases, I found many deficiencies in my initial tables. In order to allow for more flexible relationships between salons, services, and stylists, I created tables with "many-to-one" relationships that could represent a wide array of cases without redundancies. I also decided to split "services" into two separate categories: hair services and beauty services. The two aspects are distinctly different when it comes to salon management and schedule organization. It became very messy to try to treat them as different instances of the same "service" object. Below is a screenshot of my new set of data tables as I've designed them so far:

Its clear from this that the scope and functionality of my website will go far beyond a generic scheduler. Google Calendars will assist in back-end management of only a small portion of the data being stored, managed, and queried. Building the three distinct user interfaces and linking all of these pieces and data together will be a substantial undertaking. Thus, Professor Nimeroff suggested Amazon Web Services as a potential way of offloading the grudge work of managing my own database. It turns out Amazon has a service called SimpleDB that is perfect for the needs of this project. SimpleDB allows developers to create and store data tables, then access and manipulate that data with simple function calls from my program.

http://aws.amazon.com/simpledb/

Using SimpleDB will allow me to focus my efforts on the interfaces and pull together a rich, cohesive, and novel application. To do this, I'm going to employ OpenLaszlo. It's syntax is relatively straightforward and is capable of deploying applications in a number of different formats, abstracting away gritty compatibility issues.

So, this is the new plan. The next steps from here are to finalize the data tables and use cases, and to create a features matrix with all the features I want for my application against all the various tools that already exist and are relevant to this project.