Events Use Cases and User/Event Relationships

I'm adding this post to the relationships group, too, since I'd love to get those folks to look at what we're talking about and add their wisdom, too. this cross-posting stuff is such a cool feature of groups.drupal.org! props (again) to moshe. this is great stuff...

dww,

I very much like your http://baterialucha.org/ web site and the way you're using the events and signup modules!

I agree with drob's comment about...

the subtle differences between all these different possible steps one can take in relationship to an Event.

Often, I receive postcards, email, letters, etc. that include "Please RSVP" when they really meant "Please Register." In my professional experience, an RSVP should always, always be answered in some way, usually "Yes, I will attend" or "No, I will not attend." A registration request, on the contrary, can easily be discarded and does not need a response.

So yes, there are subtle differences between the two.

BTW, dww, I am absolutely loving all the signup module possibilities! You rock!

Walt Esquivel, MBA, MA, Captain - U.S. Marine Corps (Veteran)

President, Wellness Corps, LLC

"events" is a pretty big universe. My personal goal is to deal with events that are commonly dealt with by the organizations we work with. Pretty much they come in the flavor of "House Parties" and "Candidate or Organizational" meetings. Which cuts down on the complexity. I would be very happy to document these use cases and add them to the list. I think just having documentation available is of long-term utility to the community. I will shortly be publishing a subset of the UCs above that will describe the focus of my "first pass" at this work.

good feature requests. the more of this kind of stuff we get on the table, the more likely that whatever big redesigns get hashed out will actually handle most of the problems. ;)

that said, a lot of what you just wrote can already be done, at least with signup (the module i'm most familiar with in this space):

• Register more than one person for event

  there's a patch for this in the issue queue. now that i maintain it, i'll consider bumping the priority. i also have code in my local copy of signup for signup admins to register other users, which is a similar use.

• Paid events - differentiated prices for participants

  there's a signup_ecommerce contrib module i've never played with, but it's supposed to do exactly this

• Event series - frequency - number

  event_repeat.module. it's kinda wonky, and i think we can do better, but it's a start.

• Event with several tracks

  i think this is just abusing the notion of an "event". what you really have are a bunch of different events (the individual talks, sessions, tracks, whatever), all of which are grouped into some larger-scale "event". sounds like a job for taxonomy or relationships. but the underlying event-management infrastructure (e.g. signup.module) should operate on the smallest level of the events themselves. i think this is more up to the site admin to decide how they want to represent the data than anything we really need to worry about in the code.

• Unregister for event - check if deadline for unregistering is past.

  signup lets you cancel a signup. it also lets you automatically "close signups" at a certain period before the event starts (which prevents folks from canceling).

• Evaluation or feedback regarding event

  survey.module? poll.module? comment.module? forum.module? drupal hardly seems lacking in ways people can provide feedback. ;)

just wanted to sketch out some ideas on what's currently possible, while we're thinking about the Grand Unified Redesign(tm).

I like these events discussions. :)

How is the info in your image "an example of having too much information in an event registration page"?

What would you delete?

Thanks,
Walt