Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve UX of event types (and tickets) #563

Open
8 tasks
ddabble opened this issue Oct 21, 2022 · 0 comments
Open
8 tasks

Improve UX of event types (and tickets) #563

ddabble opened this issue Oct 21, 2022 · 0 comments
Labels
enhancement Issues describing small improvements/changes to existing features priority: 3 - medium

Comments

@ddabble
Copy link
Member

ddabble commented Oct 21, 2022

  • Maybe rename Event.Type.REPEATING to STANDARD and Event.Type.STANDALONE to MULTIPART?
    • This could make it easier to understand that the former is the event type that provides the behavior users normally would expect from creating multiple occurrences (time places), and that the latter is a special case for when an event consists of multiple parts (time places) with a common registration for all of them
    • If so, should also reword the tooltips for each of the radio buttons in the event form

On the admin page for a specific event:

  • Make it clearer what event_type an event is (maybe also display this in the event admin list?)
  • Make it clear to the user what the event_type means for how the event works / should be used; for example:
    • For a STANDALONE event whose time places are all in the past, show a message equivalent to "Are you sure you know what you are doing?" if a user tries to create more time places for that event - as that likely means that they think it's actually a REPEATING event, or have yet to understand what the event_type of events mean

In the event (change) form:

  • When a STANDALONE event is changed to REPEATING:
    If valid according to the logic below, set the event's number_of_tickets to 0.
    • If there are no existing tickets connected to the event:
      • Let the change happen without any further action
    • If there are existing tickets connected to the event:
      • If there are no existing time places for the event:
        • Don't implement, since it's not possible to register for an event with no time places
      • If there is 1 existing time place for the event:
        • # Don't use `tickets.update()` instead of this for loop, as we want any signals to be fired normally
          for ticket in <event>.tickets.all():
              ticket.timeplace = <existing time_place>
              ticket.event = None
              ticket.save()
      • If there are more than 1 existing time places for the event:
        • Raise an error saying that this is not possible, and that the user should contact the Dev committee (to potentially come up with a manual workaround - through the Django shell on the server), or create a new (duplicated) event with event_type REPEATING
  • When a REPEATING event is changed to STANDALONE:
    If valid according to the logic below, and there is one existing time place, set the time place's number_of_tickets to 0.
    • If there are no existing tickets connected to the event's time places:
      • Same as for STANDALONEREPEATING above
    • If there are existing tickets connected to the event's time places:
      • If there are no existing time places for the event:
        • Same as for STANDALONEREPEATING above
      • If there is 1 existing time place for the event:
        • # Don't use `tickets.update()` instead of this for loop, as we want any signals to be fired normally
          for ticket in <event>.tickets.all():
              ticket.event = <event>
              ticket.timeplace = None
              ticket.save()
      • If there are more than 1 existing time places for the event:
        • Same as for STANDALONEREPEATING above, except: [...] create a new (duplicated) event with event_type STANDALONE
  • If the event_type radio buttons are changed (i.e. either one of the above cases), show a message equivalent to "Are you sure you know what you are doing?", which requires the user to submit the form again, or some similar action

In the time place (change) form:

  • If there exist tickets connected to the time place, and if any of the fields (except number_of_tickets) are changed, show a message equivalent to "There are existing tickets that will have their info changed after this; are you sure you want to do this instead of for example duplicating the occurrence?", which requires the user to submit the form again, or some similar action
    • (In the past, users have e.g. changed the start_time and end_time fields of a past course to some days into the future, instead of duplicating / creating a new time place for the course, so this change could help prevent that)
@ddabble ddabble added enhancement Issues describing small improvements/changes to existing features priority: 3 - medium labels Oct 21, 2022
ddabble added a commit that referenced this issue Oct 28, 2022
Also prevent admins, because if a standalone event were to be changed to repeating, there would be no time places to transfer the tickets to
(after having implemented the changes mentioned in #563).
ddabble added a commit that referenced this issue Oct 28, 2022
* `REPEATING` should be the default choice for most events - even if the event is not planned to repeat,
  because if it's decided in the future that another occurrence should be created, that can be done without having to change the type,
  and because this event type has the most easily expected behavior for most users.
* `STANDALONE` should only be chosen if the time places need to have one common registration,
  which is why this event type has a more detailed description including an example, to make it appear more like a non-standard choice.

This change should also complement the planned renaming of the event types in #563.
ddabble added a commit that referenced this issue Mar 3, 2023
Also prevent admins, because if a standalone event were to be changed to repeating, there would be no time places to transfer the tickets to
(after having implemented the changes mentioned in #563).
ddabble added a commit that referenced this issue Mar 3, 2023
* `REPEATING` should be the default choice for most events - even if the event is not planned to repeat,
  because if it's decided in the future that another occurrence should be created, that can be done without having to change the type,
  and because this event type seems to have the most intuitive behavior for most users.
* `STANDALONE` should only be chosen if all the time places need to have one common registration,
  which is why this event type has a more detailed description including an example, to make it appear more like a non-standard choice.
  Also, the term "multipart" should be more fitting for which kind of event the option is intended to be used for.

These changes should also complement the planned renaming of the event types in #563.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Issues describing small improvements/changes to existing features priority: 3 - medium
Projects
Status: TODO
Development

No branches or pull requests

1 participant