This was a work-in-progress prototype and as such no design has been applied other than a basic set of styles. Ideally this would be used as a base and through further iterations code and styles will be re-factored and amended.
After a few iterations version 4 was ready for internal testing with a few bugs and inconsistencies.
- Live Search
- Live Filters
- date range
- event type
- Toggle on or off events in the past
Additional Features per event listing
Event details + number of tickets remaining
Mergefields to generate
- QR code for easy registration on mobile
- Add to calendar
- Register button
- List Agenda sessions
- List Speakers
- Generate map of the event locations
Server side data lookups
This means all data loads on the page before the page renders. This works fine for small sets of events but when you reach greater than 200 events to list the load time increases and user abandonment may become an issue.
- Lazy load the data in afterwards (not possible in the current system), would require extra framework and api access which is out of bounds.
- iframe in the calendar itself to other pages and add a loader to the section so it appears to be ‘loading’. But this seems a bit backwards.
Include information with screeshots of load time for 30 events and for 1400 big events on test accounts
API is called multiple times to create the calendar data AND the calendar filters and then multiple loops occur through the data.
- Cache the data on first call to hit the server with 1 data request, and then use that cached dataset to create the calendar data and the calendar filter.
Live search started off using keyup so did a lot of data processing after each letter was pressed
- First solution was to replace this with waiting for at least 3 letters to be entered but this was a bad user experience as testing showed that users were not sure what was happening or what they needed to do to get search working (eg someone wanted to search for us, and 2 characters would not trigger the search function.
- Second solution was to switch to a timeout feature so that the page would wait until 400ms after any keyup before firing the search function. This was a much better solution as this works for single letter searches but is not firing after every keyup, so you could theoretically type a lot more characters and have the search fire once at the end of your string, rather than it firing every time a letter was entered.
Things to Add
- Pre-population of search fields from querystrings or allowing data to be passed into the page on load.
The product was tested by a few people, as proof of concept. Primarily in the team and some of management. As of July 2019 this calendar product is on hold. The slow response time of the server and the way that the twig page renders data is a major roadblock for any further use.