How much work was put in by the organisers to get the register ready for use?
There are many different parts that go together to make a functioning register, which I will look at one by one. Every change made in the ERS is logged which makes it easy to put things back to how they were if a mistake is made. It also allows me to measure how much work the administrators are putting in to various areas.
Excessive amounts of editing. This will indicate that the design of the ERS is flawed & is difficult to use.
Edits after registration has opened (bad).
Edits during the festival (worse).
These could be down to legitimate changes in circumstances, but this will also indicate where things have previously been set up wrong which could either be problems with the system that I will need to fix or things that the orgnising team have overlooked which is information we need to pass on to future teams. Ideally we don't want to be changing information halfway through registration otherwise the people in the first half will miss it. We definitely don't want to be changing things during the festival because there is already too much work to be done.
42 edits in total
3 title changes
2 tagline changes
4 logo changes
10 email address changes. This was a bug in the system that has been fixed.
2 terms changes
2 VAT changes
15 changes to available languages. The ERS is fully translatable but this feature was never used.
3 status changes (opening/closing register to the public)
2018-11-24 Alternate language options turned off
The text of the products was still being altered right up to the opening of registration so no translations were in place. It was decided that linking to partially translated orderforms would be more confusing.
2019-08-03 Registration closed to public (technically a timeline edit but closing the regster was quicker).
Prior to the event it was discussed that registration would be open online to allow people in the queue to enter their order to save work for the reg desk. However this was reversed to save confusion among the regdesk team. All the orders confirmed prior to the festival had packs prepared, anyone paying by PayPal on the day would also show as confirmed on the system but would not have a preprepared pack.
It would've been possible to differentiate between prepacked & new orders by the order creation date, but this is not really obvious enough in the system for a busy regdesk to be practical. I think having online registration open could've still helped if we disabled the PayPal option. Customers would be able to fill in their order details on the system but the order would clearly show as 'Awaiting Payment'.
26 edits in total
13 of which were changing formatting of bank transfer details. I can't force a fixed layout because bank account formats vary greatly by country.
2018-11-24 EUR bank transfer details corrected, wrong account specified (user error)
49 customers in total were given the wrong details, 13 of which had paid by PayPal so were unaffected. I identified all customers affected & passed the details to reg team to make contact. I changed the text in confirmation emails replacing the payment details text with a link to the payment details at the ERS, this would limit who would get to see the wrong information if this happens again.
Future organisers: Get more people to check your set up!
2018-11-25 Default currency changed from GBP to EUR after several European customers paid in GBP. Wording of currency buttons also changed to be clearer.
2018-08-02 Default currency changed from EUR to GBP as unable to accept EUR on the door. Bank transfer & cheque (non instant) options disabled assuming public would be using the system to create their own orders.
54 edits in total
Usage data not particularly useful as the way the timeline was specified went through 3 structural changes over the course of registration as I added ever finer granular control.
More important discussion about registration timelines coming up under PayPal analysis.
5 edits in total
This is a feature where organisers can select other juggling events from the Edge events database where their reps can accept cash payments. The 'Payment received at...' shortcuts were never used for processing any orders so no idea whether any payments at other events even took place. Doesn't look like this feature was used.
Complete: Replace with simpler free text field, organisers can specify where customers can meet them to part with cash.
48 edits in total
Several problems caused by exceeding character limits. Character limits increased to accommodate.
Lots of experimentation to work around ERS limitations, for example system was initially set up for one terms & conditions statement but the EJC needed 4 separate statements. A survey question with tick boxes was set up as a workaround before I upgraded the system to handle multiple terms statements properly.
Minor corrections to wording & we added 'Choose option' to the start of list of countries because everyone who didn't want to answer was defaulting to Afghanistan.
75 edits in total
No technical issues. Lots of experimentation with wording. Far too much text used!
Only 5 changes to wording.
5 Edits simplifying text removing all pre festival registration info, again assuming that register was going to be open to the public.
35 edits in total
Several problems caused by exceeding character limits. Character limits increased to accommodate. Normal experimentation with wording.
10 changes to wording, one of which caused some problems.
At the end of the first phase we started getting complaints from customers trying to pay for orders after the due date. Turns out the note about the order due date was replaced with a note saying they had an extra 10 days to pay. Describing how you want the system to work to the customer does not actually change how the system works, you do need to talk to the developer first! ERS changed to allow customisable due dates specific to each registration stage & the due date notice was removed from admin editable texts.
Not used.
This is a feature that allows organisers to set up a checklist of points for reg-desk staff to go through when they check customers into an event. If this is needed a better solution is a printed list taped to the registration desk. Low tech solutions are better than high tech solutions. Also the code slows down the checkin process even when not used (see server load analysis).
Complete: Feature removed.
Who can access & edit different parts of the register.
20 edits in total
6 people had access to edit the register. Only 2 instances where a user's access level was changed more than once.
5 generic accounts with access limited to editing orders were added for reg desk volunteers just prior to the event.
2019-08-07 Had request to set up extra admin accounts, which I did but none of them were eventually used.
786 edits in total
519 edits after registration opened
82 edits during event
This is a disaster.
There was a code error that caused day tickets to stop working on 2019-08-07 which resulted in another productline being set up. This issue has been fixed but is a bit irrelevant.
Breakdown of changes made:
| Change made | Frequency |
|---|---|
| Added new product | 148 |
| Change registration stage product available in | 184 |
| Change alternative language text | 1 |
| Change category (ticket or merchandise) | 5 |
| Change product name | 52 |
| Change product description | 199 |
| Change price in EUR | 11 |
| Change price in GBP | 10 |
| Change product image | 40 |
| Change options (t-shirt sizes etc.) | 97 |
| Change display order of productlines on order form | 39 |
In total there were 148 different product lines set up.
There were actually 3 separate registers used for the EJC: one for the EJC, one for the EUC, & a 3rd for managing volunteers/suppliers etc. These other registers were later merged back into one main register. Some of the standard products were included on more than one register. 17 products were duplicated, 11 were triplicated & 2 were quadruplicated(?), that's a total of 45 duplicated productlines to keep in synch.
There were 4 pre-event registration phases with up to 3 choices of the same ticket.
In the supplier register there were:
11 different types of service supplier
5 different types of performer
2 different manager tickets
3 different member tickets
8 supplier day tickets
Ignoring reason/choice of/who for behind the different product types there were:
27 (or possibly 56 it is not clear what a lot of the tickets are for, they could be for one day or one show) different products that translated to an adult full week ticket
19 different products that translated to a youth full week tickets
5 different adult & 5 different youth EUC tickets
Fewer registration phases will be more beneficial (see PayPal fees analysis).
In the current set up the pricing is fixed to the product, so when the pricing changes based on when the product is bought/who is buying/some other reason, that reason is also tied to the product. This was by design but clearly doesn't scale when there are a lot of reasons. This needs to be separated out.
Complete: Completely rewrite how productlines are stored & created. My apologies to all who touched it.