After Lars suggested it and modified the database code to allow it, I implemented basic security on the login passwords. I have also given the others access to the MySQL and FTP for gdp.fatalmelon.com, and implemented a changelog for it.

I have set up an area here on FatalMelon.com for the GDP project. The main site is at http://gdp.fatalmelon.com, and the static template version at http://gdp.fatalmelon.com/static.

Our client chose BSO two, as we had hoped he would. I made the static version of the site based on the initial designs I made in PowerPoint, using XHTML and CSS. Lars has started implementing the database with MySQL and I have implemented login/logout functionality using PHP. Peter is testing it right now.

I have done the initial GUI (Graphical User Interface) designs for the three BSO's (Business System Options), using PowerPoint. Daniel is putting them into a single presentation along with some other stuff, ready for our practice presentation later. The first level BSO is very basic, with Access forms, and can't do lots of the things the customer wants. The second BSO has many more features, and like the first would only be used by the theatre's staff. It would run on PHP and MySQL, hosted internally. The third BSO includes the features of the second, but extends it to also have a web page on the internet where customers can pre-book tickets.

Lars hasn't been in much recently because he's not very well, so we haven't talked much about the design of the database. This early in the project I'm not massively worried about it, but once the client has chosen a BSO to work with (our recommended one is BSO 2) we'll have to get the database design sorted before I can do much with the GUI. I could get on with stuff like the CSS (Cascading Style Sheet, controls formatting on web pages), but the database will have to be built or at least in the final stages of design before I can start making PHP functions that make calls to it.

Daniel and Eleanor interviewed the client and found out more about the requirements of the system. There is one theatre room with 100 seats (10 rows of 10). Tickets are for a specific seat. Sometimes, the front row or the front two rows aren't available, for example if the stage has to be expanded or there are potential safety issues (such as a swordfight on the front edge of the stage).

My current task is to design the interfaces for the three different solutions.

I'm doing a group design project as part of my Computer Science BSc course. I am working in a group with 4 other people on a project in which we are making a theatre ticket booking system for a (fictional) small theatre. I have got to keep a log of some kind, documenting my role in the project. One option for this is to use a blog, so here it is.

The group is comprised as follows:

• Daniel: Group leader, requirements analysis, presentation, client interview planner.
• Eleanor: Requirements analysis, presentation, client interviews.
• Lars: Lead database designer and implementer, hardware researcher.
• Richard: GUI designer and implementer, assistant database designer and implementer.
• Peter: Database tester, meeting documenter.

We had an interesting discussion in our group meeting about how to do the seat booking. The simple way would be to have a number of available tickets and simply track how many places are still available. The more complicated way, which Lars suggested, would be for each ticket to be for a specific seat. I was sceptical about the benefits of this, due to the complexity, but suggested that we could maybe have it as an option alongside the more simple system, so that specific shows could have set seating and the majority could be freeform. Daniel said that Lars should make a proof-of-concept by next week's meeting so we can see whether it's worth continuing with.

There are three levels of complexity we could implement the system at:

• The simplest form would be for the system to simply be used by the ticket vendor in the theatre to sell tickets in person to the customers.
• Next, and the one we seem to be leaning toward currently, is having the above functionality as well as a telephone booking system, where a member of staff operating the system can book a ticket for someone and give them some sort of code so they can collect their ticket in person before the show.
• Finally, we could also make a web front-end for the customer to see what shows are going to happen and book them and pay for them online.

Daniel and Eleanor are going to do the interview with the "client" (our tutor) to get the exact requirements for the system within the next week, so we don't yet have any full-on database design to do quite yet. My task for this week is simply to start looking into how I'm going to do the GUI. We are currently planning to run the database on MySQL and for the GUI I build to be a PHP web application.

I just accidentally lost everything on here while moving the blog to it's new home, here at blog.fatalmelon.com. Oh well, at least I only lost the blog stuff. We didn't have anything particularly important or irreplaceable on here anyway.

Anyway, everything is fixed, some of it better than before, so onwards and upwards to greater things!