Event Monger Delay

I’m sorry to announce that development on Event Monger (my BTC-FTC project) has been delayed until after the Australian Tech.Ed event (beginning of September).

Unfortunately I’ve been pretty busy over the course of the last month or so on various projects and whilst I’ve been on leave this week I haven’t really had the focused time I’ve required to sit down and tackle this project.

Event Monger has a relatively large scope in terms of the scenarios it needs to support to be useful, as such it breaks the BTC-FTC mold a little bit (which is ironic given that it was supposed to be the first cab off the rank).

So – my sincere apologies for the delay, once I start work on the project again I’ll post up here with progress reports.

Who is going to use Event Monger and how are they going to use it?

In my previous post about Event Monger I said that I would post up a list of specific end-user scenarios. A scenario is a dirt simple – plain english description of how someone will use the system. They aren’t really supposed to be a technical description, but more something that you can agree with the customer on – in this case the customer is me so it was easy to reach agreement.

Defining Personas

In Event Monger there are really three different types of users, Organisers, Speakers and Attendees. To help understand these users a little bit more those links go to copies of (very small) persona documents that I have written. If I find out more about the users that will be using the system I’ll update those documents.

The Workflow

The users of the system participate in an overall workflow which results in the running of a successful event. The workflow, combined with the use of Event Monger will have five stages that I’ve been able to distill, these are Install, Plan, Promote, Attend and Review.

Each of these steps in the workflow have scenarios that support them, and those scenarios can be mapped against the personas.

Installation Scenarios

The following scenarios are related to the initial installation of the Event Monger software. I want this to be as seemless as possible. The people doing the work should only need to have some ASP.NET 2.0 hosting space with a SQL Server account.

• Event Organiser
• The event organiser installs and configures Event Monger at a remote ASP.NET hosting provider.
• The event organiser logs into Event Monger and defines a list of other event organisers.
• The event organiser logs into Event Monger and adds event specific flair.

Planning Scenarios

This is really just the initial data entry required to get the event kicking over itself, doing things like setting the themes for the event by defining tracks for example.

• Event Organiser
• The event organiser defines a list of venues, rooms and dates, and provides links to useful information resources.
• The event organiser defines a list of event tracks with a brief overview of what they are about.

Promotion Scenarios

For a technical community event its a pretty good idea to put your ear to the ground and figure out what people want to hear about (within broad guidelines). So this is all about getting speakers to submit things they are happy to present on and then getting people who _might_ attend to vote on those submissions.

• Event Organiser
• The event organiser opens the Event Monger site up for submission of session abstracts.
• The event organiser accepts a session abstract.
• The event organiser rejects a session abstract.
• The event organiser opens the Event Monger site up for voting on accepted session abstracts.
• The event organiser creates the final schedule for the event based on prospective event attendee feedback.
• The event organiser sends a notification to prospective event speakers asking them to confirm their attendance.
• The event organiser sends a notification to prospective event attendees asking them to confirm their attendance.
• The event organiser sends a reminder to event speakers and attendees about the upcoming event.
• The event organiser changes the schedule based on a speaker cancellation.
• Event Speaker
• The prospective event speaker registers on the site and submits a session abstract.
• The prospective event speaker registers on the site and submits an additional session abstract.
• The prospective event speaker logs into the Event Monger site and confirms their attendance.
• Event Attendee
• The prospective event attendee registers on the site and votes on session abstracts.
• The prospective event attendee logs into Event Monger and votes on more session abstracts.
• The prospective event attendee logs into the Event Monger site and confirms their attendance at a particular venue.
• The prospective event attendee registers on the site for the first time and confirms their attendance.

Attendance Scenarios

Once you are at the event the site tends to be forgotten, but it can actually be a useful posting area for all sorts of information. For example, at Code Camp Oz last year a whole bunch of MVPs held a number of informal sessions on a much more diverse range of topics than the Code Camp was really intended to cover. A specific room wasn’t scheduled for them so they just put up on a whiteboard which room they were doing their stuff in – great for BOF sessions too.

Of course – this is also a good time to collect all the collateral that the presenters used during their session if they are happy to share it.

• Event Organiser
• The event organiser opens up the Event Monger site for the submission of community notices.
• Event Speaker
• The event speaker uploads slide decks and any other collateral to the Event Monger site and associates it with their session abstracts.
• Event Attendee
• The event attendee logs into the Event Monger site and reviews and adds to the community notices.

Review Scenarios

That’s a wrap! After the event there are a few things that need to be done like writing up a quick review of the event so that if someone comes to visit the site its clear that the event has passed. Its also a good time to send thank-yous so that hopefully the speakers and attendees come back again next time. I’m not quite sure how this part of the workflow works with multi-venue events that span different time periods.

• Event Organiser
• The event organiser closes down registration and writes a post event synopsis.
• The event organiser downloads a mailing list of all event speakers and attendees.
• The event organiser sends a thank-you message to event speakers.
• The event organiser sends a thank-you message to event attendees.
• Event Attendee
• The event attendee downloads collateral assocaited with their favourite sessions.

Your thoughts?

What are you thoughts about the scenarios that I have outlined above? I’m not sure if I am going to get to all of them before the 4th of August so I’m going to do a little bit of prioritisation. I’d love to hear from you on what is most important, what can be dropped, and have I missed something completely?

Introducing Event Monger

Well, the votes are in and it appears that my “By the Community, For the Community” project is to build an ASP.NET-based event management site – I have decided to call it Event Monger. My objective is to ship this application out on or before the 4th of August which means that I had better get cracking. I’m going to use my blog to document the process of designing and building the application.

What is Event Monger – really?

Event Monger is something that I have wanted to have for a long time as an co-organiser of a technical event like Code Camp Oz. The problem is that all the tools out there to date are really good at content management, but not that great at automating the workflow of an event, including things like:

• Accepting session submissions
• Ranking session submissions
• Scheduling accepted sessions
• Accepting attendee registrations
• Sending attendee and speaker notifications
• Presenting venue information
• Posting of during-event notices
• Accepting speaker uploads

In my next post on Event Monger I am going to list out the specific end-user scenarios that are going to be supported and where they sit in the overal workflow of managing an event. I’ll use the scenarios to drive the development forward and keep track of how things are progressing.