|
Even Onsager
|
June 27, 2012 at 3:23 am
I’ve been thinking of a few ways the REM could be better integrated into the process of adding events. Some, if not all, of these might be tough or even impossible to implement. They’re ideas, nothing more, but it never hurts to throw them out there. 🙂
First of all, I would move the “is this a recurring event” up to the main window and make it a checkbox.
If checked, the fields from the REM below will appear (or become ungrayed-out). I.e. the dates (daily, etc) and all that. The registration dates and event dates boxes are duplicated now, so if the duplicates could be removed, that would make the process a lot simpler for event editors.
Adding an option of different start times for the recurring events would also be great. When editing a recurring event today, I often have to edit the start time for one or more event with irregular start times. Today, f I edit the description for all the recurrences, all the start times are changed back into being the same as the first event. (This is quite a hassle for me, but I might be the only one having problems with this.)
Also, I might be overlooking a use case, but I can’t think of any situation where “Add additional time” and using the REM will work properly together. If I’m right, I would prefer if it could be grayed out if recurring is checked. If possible.
Also, while technically not a REM idea, I posted this a while ago on the old forum regarding the REM and waitlist events:
– Upon creating a waitlist event, Event Espresso could check whether or not there’s an existing primary event with the exact same start date, end date, start time, end time, venue (and maybe even more variables just to be 110 percent sure). If yes, it will auto-assign (maybe after a prompt?) the new waitlist event as overflow event to the primary event. (If there is no such primary event, obviously nothing will happen.) Come to think of it, if all these variables check out, a prompt should be unnecessary.
– Even more preferable (and possibly even more impossible): check for all instances of a recurring event when adding a recurring waitlist event, and auto-assign all waitlist events as overflow events to the corresponding primary events.
– If it worked, a message could say something like “X [e.g. 5 in my case] events succesfully assigned as overflow events” if the values matched and it worked.
I don’t know if you have a roadmap for the REM. You might have thought of some of these already, and several others might be impossible to implement. Anyway, just some ideas. 🙂
|
|
mpurse
|
June 27, 2012 at 4:24 am
Yeah to all this! Plus, the ability to some make events not recurring… but ‘sessions’ of the first event – like an 8 week course.
Its SUCH a good feature anyway that it just makes us want to do more with it!
|
|
Josh
|
June 27, 2012 at 8:11 am
Thanks for the feedback. I’ll bookmark this for when we are ready to tackle REM. As it stands now, REM is going to need a re-write from the ground up (much the same way that Multi Event Registration did).
|
|
teta
|
August 22, 2012 at 9:30 am
I’d also like to see a way to set cascading close dates for events, i.e. set up a series of identical events (e.g. from Sept 2-30) that have the same registration open date (e.g. August 25) but different registration close dates for each occurrence (e.g. close on Sept 1 for Sept 2, close on Sept 2 for Sept 3, etc). It could look something like ‘close registration x hours/days before event start’.
The only way it can be done right now is to set the series up in bulk using a registration window that covers all of the events in the series (e.g. August 25 – Sept 29) and then manually update the close for each occurrence. This is a lot of manual effort, as I have hundreds of events in my calendar.
|
|
Chris Reynolds
|
August 22, 2012 at 10:32 am
So, there are a lot of good ideas here. There’s also a lot of good ideas going into Event Espresso 3.2, and some of those overlap with current needs and what people have been asking for from REM. I’m not going to go through the entire list that you suggested, but I will let you know what’s coming with 3.2 and what our current plans are for REM when we tackle that.
-
With Event Espresso 3.2, a single event can have multiple different event dates/times. (Currently, an event can have multiple different start times, but not different dates.) Each one is displayed and handled as a different iteration of that event but is still considered the same event. This will be the workaround for people who want to upgrade but are currently using REM and need to create recurring events since the existing REM will need to be rewritten before it will work with 3.2. It adds a lot more flexibility than the current system, because you aren’t bound to the same event start/end times or a specific formula for creating a recurring series.
-
Therefore, REM will really be focussing on the formula part of things. Since you can already create a series of events within a single event for multiple different dates and times, the REM add-on will make this process easier for when you want to create a large number of recurring events (when it would be unreasonable to expect someone to create all those events manually) or if you know you want to build a series of events according to a specific formula. In addition, we’re planning on allowing formulas like “the third Thursday of the month” to work, which is currently unsupported in REM.
Registration open/close dates are still a bit up in the air, but we realize the current registration open/close system isn’t ideal and that is something that will be addressed as well. When we start working on REM 2.0, we’ll definitely take these and any other ideas you guys have into consideration as we start tearing the code apart.
-
This reply was modified 12 years, 4 months ago by
 Chris Reynolds. Reason: clarification of current multiple start time functionality
|
|
Even Onsager
|
August 23, 2012 at 3:29 am
Now that’s interesting news. I guess I’m the target audience for making recurring events a part of the main plugin (and making the REM more of a helper plugin to automate the process), primarily because I would think it would make the concept of recurring events better integrated in the main plugin. Like I described in the first post, a lot of the fields on the edit/create event screen are counter-intuitive when you use the REM, and information has to be filled out twice in several spots. Also, I desperately want the 3.2 enhancements, but I can’t afford to lose recurring events compatibility (90 percent of our events are recurring). Since lot of our events recur only twice or thrice, I’d rather have EE 3.2 with some manual work than have the EE 3.1.22/REM 1.1.7 combination longer than I have to.
Btw, I’m very happy (and our attendees are too) with the expanding/collapsing list of recurrences where a click on the event will expand into an unordered list of event dates. I hope it’s possible to keep this like it is with a REM-less 3.2, even if it will take php hacks or css trickery.
Also, when you eventually rewrite the REM, please consider integrating it with assigning waitlist events (like I described in the original post). Assigning waitlists for recurring events as it is today is extremely difficult when you have a lot of recurrences, and it’s by far the most common human error in my team. Sending out attendee emails with “Sorry you got assigned to the wrong waiting list” is the most embarrassing thing I’ve had to do so far in this job. 😉
|
|
Chris Reynolds
|
August 24, 2012 at 4:28 pm
We’ll definitely keep all this stuff in mind when we start working on REM 2.0. We all agree over here, too, that integrating recurring events into the core plugin is a better way of handling things and has essentially been something we’ve been asked for without anyone actually saying that out loud.
Re: expanding/collapsing recurrences — we’ll probably do something, though what, exactly, remains to be seen. That said, we’re using some of those same sorts of ideas in the new registration/checkout process (by putting the whole process on a single page and expanding different sections of the process when you get to that part). For the REM-less 3.2, it would likely be displayed as a list of event dates/times under the main event (so it could be customized with CSS if you wanted to hide those dates/times by default).
|
