Developing common code: use cases and ideas?
Hello everyone!
At the recent DrupalCamp UK session on running events with Drupal, the current state of things was awarded a resounding 3/10.
Several of us agreed that we should aim to work together to produce reusable, generic modules, rather than keep building one-shot sites.
Obviously this requires more effort and organization, but the benefits are considerable :)
So to get the ball rolling: what do we need from event sites? What use cases do we have? What do we need to consider?
Also, any ideas on the architecture: how do we split this into modules? And which modules do we need to interact with?
Groups:
Login to post comments
Context, Features and Spaces
Context, Features and Spaces modules are well worth a look, they let you bundle up a bunch of functionality, and drop it into another site. Then spaces adds a whole lot more.
Use cases
[Blah! This is the 3rd time I will have written this. Thanks Firefox.]
Hi Joachim,
Here's a list of one-line use cases. Many of these you saw at my talk.
Event web site. For big events which are non-repeatable - e.g. DrupalCon Paris.
Event group of pages/subsite - OG style for repeated events on the same site.
Event page - for simple events
Series page/subsite - for events which form part of a series
Invitations - printed & emailed - for by invitation events
Confirmation/RSVP - web for by-invitation events
Campaign - email & printed campaign management includes personalisation & response management tracking replies.
Registration - web & paper - with custom registration forms & data cleaning for duplicate registrations
Streaming - for events with multiple streams & limited capacity in the streams
Ticket sales - for paid events
Ticketing - printing of tickets & web distribution of tickets
Event Confirmation & Communication - responding to registrations with custom responses, including possible self-printed tickets. Includes ongoing communication
Badging - badge printing
Participant programmes - individualised programmes
Participant list - online & printed. Ability for particpants to update.
Participant meetings - ability of attendees to arrange meetings with each other
Participant communication - ability to have virtual discussion, whether river-of-news, irc, forums, etc
On-the-day desk - includes registration, badging & entry control
Data integration - Ability to re-integrate on-the-day dat
Resource booking - to allocate & track limited resources, including room booking
Event organisation - dealing with speakerl, staff & volunteers: requirements, training, information, resources, etc
Ad-hoc reports
Service integration - for tools like eventbrite
Event repetition - do it again, either as part of a series, or as an individual event
I'm sure I've left some things out which I wrote the last two times.
Many of these things are processes: for instance, campaigns - you send communications to people at the appropriate point in their particular cycle: if they've already heard something about the event, you try not to repeat the previous mail. Or if someone has registered. Different people may be at different points on the cycle: for instance - someone who has just heard of the event may be getting the first campaign mail at the same time that someone who has expressed interest in the event is getting their last reminder to complete their registration.
You should probably break
You should probably break your thinking / functionality into phases: pre-event > day of event > post event activities.
I.E. :
Name tags -> pre-event
Attendance -> would be recorded day of event.
Certificates -> post-event, conditional upon paid, attended, etc other conditions
I think the campaign stuff
I think the campaign stuff should be handled by Simplenews if that's at all feasible.
There's support for actions in Simplenews, so it's easy to say "new registrations get sent a copy of newsletter issue 1" for example.
If we need more specific stuff we could always do a helper module for simplenews.
Anything that's a list of data should be views:
- participant list
- badge printing
- maybe even ticket printing
We could provide ready-made defaults in a module once we know what our data structure is.
The biggie is the actual registration -- see my subsequent post on possible webform/ubercart tie-in.
The other thing is resource allocation.
Could this be done in an API module? I'm thinking of something like votingapi that just gets told one of:
- "resource id foo is reserved until timestamp"
- "resource id foo is booked permanently"
- "resource id foo is cancelled and free again"
and then gets asked:
- "how many resources of type bar are free?"
- "is resource id foo available?"
This module would then be totally independent of what the resources are -- it would just know the calling module and the ids it's given.
Resource allocation
There's Booking Systems group. I 'm guessing there's some overlap. There's the Bookings API module, which books slots. A sophisticated API would have reservation and release as part.
I think the operations you suggest are sensible, but I think it's a bit more complex:
For example, if you are booking seating for a party, then often the people want to be seated together. In this case you have a group of resources to reserve together. You can't do them sequentially because if demand is high you might have somebody else managing to book in the middle; if Group 1 has person A & person B, and Group 2 has persons C & D, then sequential hold & release can lead to this sequence hold seat 1 for A, hold seat 2 for C, hold seat 3 for B, hold seat 4 for D. Or some other interleaving. Of course, for this small example, it's easily sorted between the participant at the time, but that's not always the case. What if the hold/release resource is limited, and D doesn't get a seat.
So, I think it needs atomic, group hold & release.
BUT this only matters to the extent that an event has limited resources. Many events don't have absolutely fixed resources which must be parcelled just so. And many events don't have an overwhelming demand so that even if there are fixed limits, there's no resource contention.
I had a quick look at the
I had a quick look at the page for the booking API module (did you post a link to it? I'm starting to get lost in all the threads...!)
I was disappointed to see for the 6 version they are thinking of going from an abstract approach to a node booking -- this is the wrong way IMO.
I think a resource reservation API needs to be fairly abstract, and it's up to calling modules to know what their resources actually mean.
The matter of sequential group bookings is one to ponder though -- whose responsibility is it to say what counts as a sequence?
There's a group here for the bookings API module -- should we go over there and see if we can convince them to stay off the node approach?
Depends
It depends on what they mean by a node approach.
If a node represents a resource and a resource can represent a group of resources - for instance if a node can represent a plane, and is able to book subresources - seats - then this can work.
A view of the node would be a representation of the current booking state for a particular booking slot - in this case a flight.
That would work nicely with the D rights; only booked passengers could see seat assignments.
All speculation though.
I think from what I read of
I think from what I read of the project page and the groups stuff it's going to be 1 node = 1 thing to book.
Having to create a node to represent each seat would be crazy!
Though come to think of it, how would that data be entered?
Suppose it's a fleet of planes, or a theatre floorplan?
I don't think this sort of thing is going to be high on our list of priorities, but as you've said, we should aim to have an architecture that allows it in future.
Campaign
I haven't used Simplenews before, but campaigns typically need to do things like:
Send this mail (e.g. "Our great conference - Latest update") to all prospects who haven't had it yet, who have already had the previous mail (e.g. "Introducing our great conference").
So you need to be able to track who has had what mail, and you need to be able to express the conditions under which a mail is sent. This includes the ability to differentiate between different groups of people - e.g. prospects, attendees, staff, etc - as part of the condition under which a mail is sent.
Does simplenews track what emails have been sent to who?
There is potential in
There is potential in simplenews for this.
- can synchronize newsletter subscriptions to roles -- and presumably to other things. Furthermore, subscriptions needn't be registered users.
- simplenews_actions allows sending a particular newsletter (so an old mailing could be sent to new registrants)
- it can track who has opened what, with a contrib statistics module. Don't know if it keeps a record of who was subscribed at the time -- if not, I'm sure we can get that feature in or get an API hook so a contrib module can do it.
Overall, I think simplenews does a lot of stuff already, so rather than reinvent the wheel we should see how it can be built on.
Sounds good.
Yeah, that sounds good.
BTW, you can do campaign management outside Drupal. But you do need a way to register changes of status. For instance, once someone has registered, they should no longer receive marketing email.
Lists
Yes, I agree about Views for lists, with one reservation:
Many of the lists are part of a process. You don't for instance, typically, print name badges once. You usually do it several times if you have a small enough event. (At large events you may have mailed participants their badges - a list process - or you might produce them on the door - not a list.) Each time you print the badges that weren't printed last time. So you need to track what's already been done.
I can imagine this progressive production process being done in 2 ways: either by using a module like flag to track state for each item, or by keeping an audit log of events, and querying the log. Probably the normal log wouldn't be suitable because it's cleaned from time to time by cron, isn't it? With old events being deleted.
An audit log could also be used for campaign management.
Role Models
I generally see the following roles:
Excludes = someone the system knows about, who should receive no marketing material.
Prospect = someone who the system knows about, who should receive marketing material.
Attendee/Guest = someone who is registered to attend the event
Group Contact = someone who is dealing with the registration for a group. Not necessarily an attendee
Staff/Organiser
Press
Speaker/Performer
Helper
The language is good for conferences but it doesn't match the language for, say, weddings, although a wedding has similarities. What I wonder is are there any events, where this list of roles isn't sufficient? There maybe sub-roles, for instance, not all staff are likely to have the same permissions at a large event.
On the Signup module feature requests, someone pointed out that they could do with tracking definite signups, maybes and definite no's. These aren't quite roles, but they are another sort of categorisation of the people known to the event.
More use cases
The signup module has lots of feature requests that describe use cases.
Basic Event Registration...
My current use case isn't much more than a basic Registered/Waitlisted thing:
-Set limits on number of Registrants, overflow is placed in a Waitlisted queue
-confirmation emails which tell the users their status
-on screen status listing for end-users (a listing of events a user has registered for and their status in each, as well as a status notification when the user visits the node describing the event)
-If a Registrant drops, next user in Waitlisted queue is promoted and sent email confirmation (although there should be a limit on how late a registrant can drop so that people aren't given 3 minutes notice of their promotion)
-At-a-glance listing of a registrant's statuses: an admin should see the user's Registered or Waitlisted status next to their names, and also see something to the effect of a registered/total + waitlisted readout (i.e. 12/12 4 waitlisted)
-Ability to send messages by status
Though there are a few other features that would be useful:
-Self-sign-in for registrants. Instead of event leader taking role or something, registrants should have some way of checking themselves into an event and having that data recorded. There needs to be some way of making sure that this check-in can only occur at the physical location of the event.
-Ability to track users and suggest other events they may be interested in
...I could go on and on, but I'll stop there.
The point being that event registration is, as this whole group is aware, something that almost everyone needs. If Drupal had something like this in core out of the box, it would only strengthen it's position in the CMS market...