FEATURE: Events

[jeturcotte]

An 'EVENT' is an internal and external representation of any one, well... event. A place and time folk can congregate for a reason. While not all EVENTs are limited, some are, and so the underlying mechanics of these objects (and external 'user experience') wrapped around them must be able to present and control the limited nature of any individual EVENT.

Note that all all-caps words refer to conceptual 'objects' ... we have a MEMBER, a SIGNUP, a COMMENT, a LOCALE, a SEASON, and an EVENT thus far. Each simply contain internal structures, strictures, and interfaces and operate in concert to provide a service. For example, a MEMBER signs up to an EVENT at a LOCAL during any given SEASON. A SEASON will contain many EVENTS, while a LOCALE can be the site of many EVENTS as well, while an EVENT may contain many MEMBERs. Meanwhile a MEMBER can COMMENT on any EVENT or even any LOCALE (separately,) often in response to some other COMMENT.

• MEMBER interface requirements:
  • FEATURE: Listing page of EVENTs
  • FEATURE: Details page for any one EVENT
    • SUBFEATURE: Show details of EVENT
      • REQUIRES: Name
      • REQUIRES: Show date of EVENT and current SEASON
      • REQUIRES: Show duration of EVENT
      • REQUIRES: Show fee of EVENT
      • REQUIRES: Show unique description of this particular EVENT
      • REQUIRES: Show further details about LOCALE
        • REQUIRES: Show general description of the LOCALE
        • REQUIRES: Show general parking/travel considerations of the LOCALE
        • REQUIRES: Show general difficulty/rigor of the LOCALE
        • REQUIRES: Show special accommodations of the LOCALE (if any)
      • REQUIRES: Show/substitute unique parking/travel considerations of the EVENT (if any)
      • REQUIRES: Show Fullness of Event
    • SUBFEATURE: Show sign-up / decline / resign interface for EVENT
      • REQUIRES: Show 'sign up' button for EVENT if not already full and if the MEMBER hasn't signed up for any EVENT at this same LOCALE
      • REQUIRES: Show 'wait list' button for EVENT if either full or if MEMBER has already signed up for any other EVENT at this same LOCALE
      • REQUIRES: Show 'resign' button for EVENT
    • SUBFEATURE: Show conversation about EVENT
      • REQUIRES: Show box+button+captcha to add a COMMENT about the EVENT
      • REQUIRES: Show box+button+captcha to add a COMMENT to a COMMENT (e.g., a reply)
      • REQUIRES: Show COMMENT to MEMBER at all times
        • REQUIRES: COMMENT has text, date, and MEMBER name
        • REQUIRES: COMMENT does not display to others until a moderator approves it

[jeturcotte]

Right now, 3 times a dig season, I send out to the current membership, by way of a no-reply email, a list of Digs they can sign up for in each two-month 'session'. I include enough basic information so they can decide whether it's something they want to try. This will continue to be the case, but we're tweaking the bylaws concerning the cut-off date for renewal of membership, so I can send the list out earlier in the season without that I end up confirming people to attend who don't end up renewing, and then you have to chase them down and stuff - it's a pain. The only thing you have to know about that part, I guess, is that for next year I'd like to be able to list the whole season at once, and if this goes smoothly we'll probably use the process year round to set up other events, such as museum trips and so forth, so the app ought to be able to accommodate as much as 30 events at once? Not sure if that's an issue. ( to be continued)

Right now, that no-reply email includes a link to my email address, and my inbox gets FLOODED with emails which I print out on junk paper, and I have to sort through one by one and manually list in a notebook which digs each wants to get into. I'm hearing from the Primary of the membership. A lot of our membership are only single memberships, but a lot are 'family' memberships. These emails might look like:

May 19 - Bennett Quarry
I keep hitting enter
Joe, Mary, Bella and Hortense
They'd be telling me for each Dig who they'd like to get in.
Sometimes a Single will sign up for themselves and a friend.
It's tedious and fraught with human error potential.
I assign each request a number as it comes in. Then, when that's done, I take a random number list so that I can sort from the requests fairly, and fill in the slots available per dig, based on the limits provided by the mine operators. Some digs have no limits.
Once filled, I continue filling in the waiting list.

I'm hoping for them to be able to see the whole season schedule in the online thing. I always have multiple dates set up for the popular places like Havey. One thing that releasing the schedule for signups earlier would help with is that if demand was different from what I anticipated I'd have time to adjust. By May, most mines are booked up, so no flexibility left.

If they can see it online all at once they'd have the multiple dates laid out and could pick which dates to go for. I guess there'd need to be a provision for once one was full it'd either default to another date and start filling that, or there'd be a waiting list?
I picture that Membership Dude would be the one making sure the site has everyone's current email addresses, and nobody else should be able to access that part.
If the site automatically confirmed for people which Digs they're in on, I wouldn't have to type up multitudinous emails telling them - which is another place human error creeps in. People get miffed at me.

If each Dig Date's attendees could constitute some kind of 'group', which the field trip leader could contact through the app with the details of that particular Dig date? Then I could have a field trip team of 20, even, without worrying about disseminating sensitive information further than a lot of people are comfortable with.

[jeturcotte]