Skip to content

Instantly share code, notes, and snippets.

@joshfeck
Created June 17, 2015 17:32
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save joshfeck/158e934023658b12cf9e to your computer and use it in GitHub Desktop.
Save joshfeck/158e934023658b12cf9e to your computer and use it in GitHub Desktop.
Options for EE4 Multi Day/Multi Time use-cases

Datetime Selector

Almost the same as what we have now, except the inclusion of a dropdown, checkbox, or multi-select at the top of the Ticket Selector. The rest of the Ticket Selector is initially blank. The dropdown is filled with the Datetime options for that event. Selecting an option from the datetime dropdown populates the rest of the Ticket Selector table, just like we have now, but you would ONLY see ticket options that are for the selected datetime.

Pros:

  • Less clicks to select tickets ( datetime, then qty )
  • More information available at one time

Cons:

  • Uses more screen real estate
  • Still possibly too much information

Cascading Datetime Selector

You have a table with 3 columns:

[ Datetime ][ Ticket ][ Quantity ]

Selecting an option from the first dropdown for the datetime, would then populate the next dropdown with the ticket options for that date, and selecting an option from this dropdown populates the quantity selector based on the availability of that ticket option.

Pros:

  • Uses far less screen real estate
  • Possibly less confusing for user since options are broken down into smaller chunks

Cons:

  • Requires way more clicking
  • Hard to compare ticket information from multiple datetimes

Cascading Date && Time Selectors

Same as above, but with dedicated dropdowns for both Date and Time You have a table with 4 columns:

[ Date ][ Time ][ Ticket ][ Quantity ]

Selecting an option from the first dropdown for the date, populates the time dropdown, which then populates the ticket option dropdown, which populates the quantity selector.

Pros:

  • Uses far less screen real estate
  • Possibly less confusing for user since options are broken down into smaller chunks

Cons:

  • Requires way more clicking, possibly too much
  • Hard to compare ticket information from multiple datetimes

Thoughts, comments, 22nd century insults?

@vilhellem
Copy link

I would say that the 3 column version seems to be the most reasonable alternative for this use case. I am currently developing a site where I would really need this functionality.

@pheouk
Copy link

pheouk commented Oct 12, 2016

Firstly, I would mock all three up and have users (e.g. us) test, watch how long it takes, whether people get confused (e.g. via a tool like Userzoom or similar)

Secondly, it would be great if you could have more granularity on the ticket selector on a particular page. e.g. at the moment I'm using complicated PHP to put tickets on one page, but not on another (my use case being customised group ticket pages for specific groups, with branding and a particular price/ticket type). It would be great if I could add the ticket selector with config options in the UI - e.g. drop it on, then hide only ticket IDs 1,2,3. This would replicate the PHP code you have in the repository.

@lucasevmiller
Copy link

We use Event Espresso for movie tickets and a dropdown for datetimes would be a big help in terms of saving screen real estate. The current set-up just takes up way to much space and confuses visitors. Please put this option in a future update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment