All of this discussion about an event registration module has me wanting to program a mock-up of this that would work for FunPub's business model. I'm trying to think of what would be needed in order for this to work for them. Here are a few thoughts off the top of my head just to give some you an idea about the scope behind a project like this.
This project should be quoted as a flat price. A project of this size and scope should never be quoted hourly in my professional opinion.
Please note, I am a senior application developer. I am not a project manager. This is not a proper project plan ... this is just a general outline that I came up with us I walk through the process mentally.
0. One of the first orders of discussion would need to be the discussion of what language this module is to be programmed in. I'm a die-hard PHP programmer ... this could potentially be a problem if their existing website is programmed in another language such as Java, .NET, Perl, Python, Ruby on Rails, or Cold Fusion. Another area of concern is their existing database. I'm a die-hard MySQL database guy. If they're using something else (such as Oracle, SQL, Access (please god let's hope not), etc), this would also be an area of concern. One simple solution would be to have the store / event registration system on a separate subdomain which could be pointed at another server which could be setup with the desired environment needed to program the website application. If this route is taken, a discussion would need to be had at some point about good subdomains for this (such as registration.primary-domain.com or store.primary-domain.com, etc).
1. I'd advise that the system be setup up so that it could work with multiple websites. Same shared database, multiple sites with unique site IDs, different unique events.
2. Depending on preference, the sites could be setup to share a common admin section at one site which would allow them to filter by domain or by going to domain-1.com/admin (or domain-2.com/admin) it would automatically filter it for them. The admin section is needed in order for them to manage the websites and therefore our information.
3. Build a module that would allow them to create new events. Each event could be assigned to a particular website. If desired, the same event could appear on multiple websites though my gut instinct tells me that the event will always be specific to the site. The only way I could see them needing to have the same event appear on multiple websites is if they decided to combine the GI Joe convention with the Transformers convention.
4a. Client would need ability to create and assign "products" (items, other events, packages, tours, etc) to each event that would be available for people to "purchase" or "register for". Some items will need to be dependent on other items being in the cart/order.
4b. Alternatively, instead of creating events, the actual event could just be an "item" that you add to your cart/order. Just like "4a" above, items would be dependent upon each other (i.e. in order to purchase "item x", you must first purchase "item y").
4x. jQuery and AJAX would be great solutions to make adding items to an order/registration pretty seamless for the customer. This should be very customer friendly and idiot-proof. The customer should not be told that they need to add something to their order without being able to easily get back to the item that they need to add. Further discussion of ideas regarding this process would be required as well as possibly reviewing other websites that function in a similar fashion.
4y (addendum). I'm not a fan of the 4b solution because I think you could do more in the long run by having it as events with items assigned as mentioned in 4a. 4a could be tied into a content management system (CMS) that would allow you to do different things such as display content on a page outside of the "store" or "registration process". Bottom line is that there is a variety of ways to accomplish the same thing so a proper discussion would need to be have to further analyze the different scenarios and outcomes.
5. During the "checkout" or "registration" process, the user should be prompted to create an account in similar fashion to Zen-Cart or other popular shopping cart systems. I'd have to think some more about how to handle one individual ordering event packages for multiple people (such as a spouse, child, other family member, or friend). I still think you'd want people to create an account so that their information would be saved from year to year. Perhaps this would just be tied in with their existing club membership ... but then you have to consider that option as well (having people sign in to their club account).
6. Speaking of which, you'd have to have separate pricing for Club members and non-Club members (if for no other reason than for display purposes to prompt/encourage people to register for the club to get the discounts which pay for themselves). I would recommend that people just have to order a club membership or have a club membership as a required item if they're not logged in.
7. In addition to all of the above, you have to also consider quantity limits, item/event expirations or deadlines, etc. Quantity limits might affect possible display of messages informing the customer that only a certain amount of registrations are left before the room is booked. Client might desire quantity limits to display or other special messages (i.e. "only 5 days remaining" or "limited space available" are such examples that come to mind ... though these could also be incorporate easily into an item's description that the client would have to maintain on their own. Client would have to weigh cost vs convenience).
8. Upon completing their order, customer would be prompted for payment and shipping information if needed. An
SSL certificate would be required in order to make the credit card processing secure (preferably from
Verisign or
GeoTrust, but there are other options available that are less expensive). I would recommend that payments are authorized and handled by
Authorize.net (one of the largest payment processors out there). I can't remember off the top of my head which system of theirs I would recommend, but it's the one where they handle all credit card information so that none of it is stored on the client's database. I'm pretty sure it's their
CIM module (
Customer Information Manager). This would also make the whole process
PCI Compliant. Authorize.net provides a unique code during the process that we could store in the database in order to handle future transactions.
9. Skipping ahead, once the user registers, notifications have to be sent out to the customer as well as the client. Depending on the amount of registrations, it might be ideal to send daily digest summary notifications to the client instead of sending them as they happen in real time. Notifications to the customer would be real-time. This would be a preference issue.
10 Client would need to be able to login to their site specific admin section(s) or their master admin section to view existing orders, limits, view reports (as needed and to include dollar amounts, profits, losses, remaining quantities, event specific registrations, etc).
11. One of the most challenging parts of this, or with any website, is the testing process. It must be thorough. It must work. Client must have multiple people testing the code ... and not just people who are familiar with this concept. It would be ideal to have someone who is not familiar with these concepts to go through the event registration process and document what errors or difficulties they encountered. Client should have 1 week of testing after initial development process has been completed. After that, the programmer(s) should make the fixes/changes/modifications that the client reported, go through the testing process again, and provide the client with access to the application again. Client should verify that their changes have been completed to their satisfaction. If not, process should be completed again. It is important to note that it is at this phase that scope creep generally happens (i.e. client realizes something that they wanted was never discussed or it didn't work the way that it was originally discussed). If new features or additional programming outside of the original project's scope are needed, a quote will be given based upon the rate agreed upon prior to the start of the project. Please note that additional work at this phase might be quoted hourly with hour estimates or a complete price might be given for the quoted changes.
NOTE: Now that I'm really thinking about this, I would want to build them a custom application that handled their store as well as the event registrations. Kill two birds with one stone. One system. That'd be ideal.
I've got more to add, but this was just off the top of my head. As I think of more throughout the next day or two, I'll update this topic. Hopefully this thread helps educate some of you who think this is something that can be done in a week (because it can't) and for those of you who keep comparing this to HTML (it's far, far, far more advanced than that).
It'll be up when it's up. Just be patient.
JoeCon is 
