Closed matthijskooijman closed 4 years ago
Another challenge is how to indicate fullness of an option. Something like "These options are full: Player, Female God" might be acceptable, but not all options will be that self-explanatory (e.g. "These options are full: Yes" when there is a "Budget ticket: Yes/No" option). This is mostly an issue for 3., since for 1. and 2. you are always showing a full option list, so you could already just add "(Full)" in appropriate places.
I agree, but that's down to configuration a bit as well.
We could change things like that to "Ticket type: 'Budget Ticket/Normal Ticket'" or something like that.
Or we could print a list of whole options instead of shorthands, like: "These options are full: 'Budget ticket - Yes', 'Divine gender - female god', 'Registration type - player'".
We recently discussed this. I think, for now, it was good enough to show whether or not your current selections would result in being moved to the waiting list, but we would not provide "alternative options" which would work.
Currently, you can only see that you're registering for the waitinglist, after you fully completed the registration. It would be good to have some foreshadowing, such as:
One challenge in 3. is to distinguish between some option that is full, or the entire event which is full (which means that there is some selection for which all options are full, or maybe even that there exists no combination of options that are not full, which might be different when dependencies are involved. This might also be relevant for 1. since knowing that the entire event is full would mean there is no point in going back to the option selection to see if any other options would not be full.
I guess that initially, implementing just 1. and 2. would be fine. Is this something for MVP? I think so?