That’s a good point that doodlz touches on: the working philosophy of the current recurrence system needs an update. For example a Poetry Weekend that occurs on Friday 4PM – 9PM, Saturday 9AM – 9PM and Sunday 10AM – 6PM can be added in three different ways:
- One individual event. This is what users chose most commonly when we hadn’t customized this part of EM. This is not a good choice, since an event that starts on Friday and ends on Sunday is going to last every minute of Saturday, which is incorrect.
- A recurring one that occurs on these three consecutive dates. This is what we currently try to get all users to do by automatically checking the
[ ] This is a recurring event checkbox if the event start and end dates have at least one day in between them. However, this does not allow for different start and end dates, so we get incorrect event information.
- Three individual events. This is the most correct option when the event times are different on each day, but this requires triple the work for user. Our site lives or dies based on the convenience of the user experience we provide, so we have a vested interest in forcing this last option upon users as seldom as possible.
Issue
As doodlz’s wrote that “though it’s not a recurring event”, users shouldn’t really have to think about whether an event is a recurring one or not. All a user knows is that it happens when it happens, and that’s all they should have to think about.
Solution: UI part
Instead of a recurrence checkbox, there should be a single dropdown:
This event [does not have a repeat rule|repeats daily|repeats weekly|repeats bi-weekly|repeats monthly|repeats annually].
If a repeat rule is selected, the repeat options would be displayed: weekdays with separate times for each, or list of the days of month (like it currently is, but with the ability to add multiple monthly repeat rules).
The information in these fields would only be used in the calendar and event date list below. These two will be side by side. The calendar shows visually on which dates does the event occur, and user can add or remove dates with a single click. The event date list shows a list of every occurrence of the event, where you can set an occurrence to have exceptional timing or remove it altogether.
The only thing saved in the database would be the values of the fields in the date list. The repeat rules and the calendar would exist in the user interface only to help populate the date list.
Database
The event date field in the database would contain the date information in a serialized format. One way to do this is to write each time the event starts and ends in the format of Unix timestamp pairs, or in pairs where the other part is a timestamp and the other is the duration of the occurrence.
For optimal database performance a new database table can be created to host the unserialized data of the event date field. For each occurrence of each event there would be one row with the familiar columns:
event_id | event_start_date | event_end_date | event_start_time | event_end_time
Thus the only changes in EM_Events and EM_Event classes’ search functions would be limited to making them look for the event date information in this table, and then find the rest of the information in the usual table.
Comments
I would also have it so that all the comments are linked to the same event_id, so a comment made to last week’s Book Club Gathering would be shown for the next week’s Book Club Gathering as well.
This way every time an event’s dates are changed, all the fields related to that event_id in the event_dates table can be deleted and recreated without losing a single comment.
Further
After this is done, it will be a far smaller matter to let individual occurrences have varying descriptions. We can start planning a suitable way of implementing that after we have ran the revised date system live for a month or more and gathered user feedback.
