General discussion about how to improve any aspect of the wish list process
1
1
Normal
Small
Posted by samlamiam

Another thread got hijacked (partly by me) in a discussion of different aspects of possibly improving the wish list process (creation, submission, processing) and related purchase of event tickets.  Derek Guder suggested a thread dedicated to the broad topic.  This seems like the most likely forum, since the topic is not specific to 2016 and is really a thread devoted to requesting new features.

http://www.gencon.com/forums/16-events-2016/topics/969-why-click-the-button 

This is a thread intended to allow discussion of all ideas intended to improve the wish list process for future years (not 2016). It's not intended to be negative of the current process.  I'm sure a ton of work has gone into creating the current process.  Some of the features requested may be difficult to implement, but this is not intended to be a discussion of the technical challenges presented but a "wish list" of improvement for user experience.

Suggestions from the prior thread and some of my own:

Topic  1.  Eliminate the "submit at this exact time or later" button.  Have wishlists submitted in advance by any users before a certain deadline.  This could be beneficial to people who aren't available at the particular time designated by GenCon.  For instance, I was in the middle of church at noon eastern today, so it would have been nice to submit my final wishlist sometime before the deadline.  It also might take some pressure of the GenCon servers if they didn't have thousands of people hitting submit at the exact same moment.  (For those familiar with math trades, a similar system is used - all users submit a want list by a certain deadline if they want to participate in the math trade.)

Topic 2.  Round Robin ticket distribution.  After giving a random priority number to those who submitted on time, start with user 1.  Give user 1 her first wanted item with tickets still available.  Then go to user 2 and so on through each user's wishlist until each user receives a ticket or runs out of wanted items.  After each user has received a ticket (or exhausted their list), start again.  Round 2 could have a new random draw to determine turn order, could go in reverse order, or could use the same order.  This would be a way to try to give as many people as possible their highest priority items on their wish list.

Topic 3.  Automatic ticket purchase.  Some suggest an optional or automatic system where tickets are automatically purchased and not just put in a cart for 2 hours.  I think an optional "Buy it if I get it!" box would be ideal.

Topic 4.  Allow for event alternates.  I think the system would benefit from having a way to say "If I don't get event X, give me one of these other events as an alternate"  Alternates might be other events in that time slot, or might be the same event in a different time slot.

For example, Wish list #1 - I want to play Ticket to Ride at 3:00 Saturday.    

#2  I want True Dungeon on Friday at 2:00.  If not available, 2A is True Dungeon at 2:30, 2B is True Dungeon at 3:00, etc. 

As soon as I get any event in this chain, the rest of the chain is deleted.  I only want one True Dungeon slot.  This feature might leave more tickets available early, because people won't be getting multiple tickets to the same event in different timeslots (unless they want them).

Topic 5.  Expand the consideration period to more than 2 hours for the first round of ticket purchases.  We are more than 2 months out, so we can relax.  People may be experiencing technical difficulties, it's the first day of getting tickets, etc.  It's hectic.  Give people 8 or 12 or even 24 hours to consider their first purchase.  No need to rush the process this early.  After a day or two, shorten the period down to 4 hours or 2 hours.  There will still be plenty of time for people to plan, return tickets, check back, etc.

Topic 6.  Wish list expressed like a calendar.  I'd love to be able to visualize my wish list on something that looks like Google Calendar or Outlook.  (Frankly, I'd love that way to look at the event list itself, even though it would be ginormous.)  

Discuss these topics or add your own.

I got all the events I wanted this year, even though I was #4700 or so in line, so I'm not unhappy with the process as it is.

Normal
Small
Posted by derekguder

I strongly recommend breaking each topic into its own thread for actual focused discussion, instead of bouncing back between each idea.

To address a couple of your points off the bat:


  • Topic 4 - Allow for event alternatives: The wish list already allows for this, it's just not automated. Put the other alternate events you might want to play in your wish list and remove any excess tickets from your cart before payment.
  • Topic 5 - Expand the consideration period: You mean how long it takes for items to expire from your cart? We've extended that in the past when they have been technical errors but unless something is actually broken, extending that expiry just confuses communication and drags out the process of tickets being returned to the pool for other attendees to pick up.
  • Topic 6 - Calendar view: For a final event schedule this would be great, but there's not really an easy way to display this for the wish list itself. It's difficult to express priority in that view and it'll get real messy real fast with lots of overlapping events.

-
Derek Guder
Event Manager
Gen Con LLC

Normal
Small
Posted by murry

Don't Sell out things that are in my cart while I'm shopping.  Between the wishlist disconnects this morning and now having stuff sold out from under me it feels as though my entire con has been taken.  If I'm good enough to give you my badge money in January and pay for a motel room in advance, the least you can do is provide a way for me to at least do something i wanted to do.

Normal
Small
Posted by tdb

There's another possible way to address event alternatives - add an option on the "buy tickets" sidebar to NOT buy tickets if you already have an event with the same title.  So if you put 8 True Dungeon runs in your wishlist, the first one is sold out, but the second one is available, the system would ignore 3-8 (provided you checked the box on 3-8).  That would mean the system would have to query your shopping cart and packets before adding the event to the cart, but only if the box is checked.

As for a round-robin process, I think it's a great idea, and it would be much more fair than a system that processes the first person's entire list before it begins to process the next person's.  Reversing the order for the next pass would be a little better.  I think a complete re-roll of "initiative" between passes would be OK too, but I'm not sure the overhead would be worth it. 

 

Normal
Small
Posted by samlamiam

Good comment tdb.

Topic 7. Queue/Waitlist for sold out events.  I would have a waitlist for people willing to auto-buy tickets that become available.

This would mean users don't have to check back all the time to try to get a ticket.  Also it would help those who are running events to know if there is a ton of pent up demand for a particular event.  If they see a long waitlist, maybe they open another table or something. 

Normal
Small
Posted by mhayward1978

Making a really equitable, optimal event assignments system is extremely complex - at a guess it's NP-complete and would probably require us all to (accurately) assign some kind of utility score to each event and combination of events on our wishlists.

Thinking it through poses some interesting questions, like:

1. Consider:


  • Alice has only a single event: "Fantastic RPG" event on their wishlist.
  • Bob has many events on their wishlist, but also lists "Fantastic RPG" as their first choice.

Should Alice get a higher priority to get into Fantastic RPG than Bob?

2. Alice, Bob, Carol and Dave each want 5 events.  


  • In one assignment, Alice, Bob, and Carol can get all 5, but Dave gets none: the group gets 15 events and 3 people are completely satisfied, and 1 is bummed.  
  • In another assignment, each of Alice, Bob, Carol, and Dave get 3 events: this group gets 12 events, and 4 people are moderately satisfied.

Which assignment is better?

     I don't ask these questions to solicit a "correct" answer - only to point out that getting to a fair resource allocation that is also optimal is not at all straightforward.

     Just doing equitable and not worrying about optimal is very easy: no one gets any events, problem solved ;0.

I suspect substantial research has gone into this field, and that GenCon could use some software, such as that used for universities, to create the schedules that would try to ensure that the most people get the most events possible.

We can, and should in my opinion, do better than the current "winner takes all" approach of (effectively) randomly assigning people in a queue and then processing the entire wishlist based on that order.

Doing it this way causes a few problems that lead to non optimal outcomes for everyone:


  • It encourages people to jam pack their wishlist with every item they could possibly want, and then drop the extras
  • Which in turn ensures people further back in the line don't get what they want (even though slots in things they want will open up once dropped)

I think the solution proposed above that processes each wishlist in serpentine order is an obvious improvement (although it in no way guarantees an optimal allocation).

Normal
Small
Posted by njseahawksfan

Several potential issues with serpentine method from a technical aspect ... No fixed number of people in queue.  Most serpentine methods I've seen in practice start with a defined number of people in queue.  Check out ... You're going to have most people checking out at once with that method, whereas the current method keeps a steady stream of people checking out.

Food for thought 

Normal
Small
Posted by mhayward1978 njseahawksfan

njseahawksfan wrote:
Several potential issues with serpentine method from a technical aspect ... No fixed number of people in queue.  Most serpentine methods I've seen in practice start with a defined number of people in queue.  Check out ... You're going to have most people checking out at once with that method, whereas the current method keeps a steady stream of people checking out.
Food for thought 

The proposed issue takes everyone who has submitted a wishlist prior to event registration, and processes them, all, before going on to everyone else.

So there is a fixed number of people in the queue: the number of people who submit a wishlist prior to registration.

Event assignment is the important part.  Hypothetical problems with checkout should not prevent us from fixing event assignments "winner take all" system.  Even if they materialize - so what - it's annoying to have to check out twice, but it's no where near as bad as not getting any of your events, when the person next to you got all of theirs, just because you drew the short straw.

Normal
Small
Posted by papalorax

The checkout problem could be helped by giving the items a 48 hour window to be purchased.

Normal
Small
Posted by njseahawksfan papalorax

papalorax wrote:
The checkout problem could be helped by giving the items a 48 hour window to be purchased.

Which has the end result of releasing unwanted tickets back into the wild much later than the current method.  Again, not saying that's bad, just pointing out that all of the solutions proposed have consequences.

Normal
Small
Posted by njseahawksfan mhayward1978

mhayward1978 wrote:
njseahawksfan wrote:
Several potential issues with serpentine method from a technical aspect ... No fixed number of people in queue.  Most serpentine methods I've seen in practice start with a defined number of people in queue.  Check out ... You're going to have most people checking out at once with that method, whereas the current method keeps a steady stream of people checking out.
Food for thought 

The proposed issue takes everyone who has submitted a wishlist prior to event registration, and processes them, all, before going on to everyone else.So there is a fixed number of people in the queue: the number of people who submit a wishlist prior to registration.
Event assignment is the important part.  Hypothetical problems with checkout should not prevent us from fixing event assignments "winner take all" system.  Even if they materialize - so what - it's annoying to have to check out twice, but it's no where near as bad as not getting any of your events, when the person next to you got all of theirs, just because you drew the short straw.
I'm with you on the first part.  Having the lists submitted beforehand certainly address my concern about the logistics of the serpentine method. 

On the other hand, I don't think the issue of having everyone's cart ready at once is a small issue.  If the system crashes a checkout, you get nothing.  That would be even worse than not getting any events via the current method.  Take it from someone who had a very very low number in the housing lottery last year (within the first 5 minutes) and due to a system error didn't get access to the housing portal for 2.5 hours; thinking you have something and having taken away by a computer glitch is way worse.

Again, not saying this idea doesn't have merit, but I'd like to see it completely thought through before I'm ready to pitch the current method of event registration.

Normal
Small
Posted by samlamiam

I think the cart crashing nightmare scenario could be alleviated by allowing auto-purchase of tickets.  Auto-purchase would be an easy decision (for me) if the system allowed wish list alternatives (i.e., purchase my first successful True Dungeon request, then cancel the others).

Another (and not mutually exclusive) solution to cart-crashing is to give more than 2 hours to check out after the first major wave of wishlist processing.

The proper amount of time is debatable.  48 hours?  24? 12?  Any of those is better than a nailbiting 2-hour window.

I think if you added the wishlist alternatives option it would substantially reduce the number of tickets that would ultimately go unpurchased from the initial allocations, because people would wind up with fewer tickets assigned to them after the first run.  So getting tickets back into circulation would be less urgent.

Adding a queue or waitlist for tickets to specific events would also eliminate the urgency of getting unpurchased tickets back into circulation, because unpurchased tickets would get immediately purchased by the person on the waitlist when they are given up.

And frankly, 70+ days before the convention, I think we can afford to give people more than 2 hours to think, call friends, and get a transaction processed.  Sure, as we get closer to August it makes sense to give people less time to make up their minds.

Normal
Small
Posted by derekguder

Auto-purchasing events is pretty much a non-starter, for a number of reasons.

-
Derek Guder
Event Manager
Gen Con LLC

Normal
Small
Posted by lanefan

I think my ideas will go a bit against the grain here, but someone's gotta say it...  Note these ideas are all to do with the initial crush.

First off, the idea of having the system auto-process all wishlists submitted before the deadline is very sound, and gets away from the silliness of trying to win a screen-refresh war. (and for overseas attendees, also gets away from having to be at a computer at exactly some weird hour of the day or night).  A further advantage is it then allows some tweaking to how wishlists get processed.  Probably simplest to have the timing go something like this:

--- 2 or 3 days prior: the "submit wishlist" button goes active, with a stern warning that you can only submit one (1) wishlist - get it right!
--- until noon: the "submit wishlist" button stays active but any wishlists submitted up to now go into a virtual holding pattern
--- noon: the "submit wishlist" button goes inactive (yes, the reverse of how it works now!) while all wishlists in the holding pattern are processed randomly and successful wishes are auto-added to cart; there is a 3-hour* window for those carts to be checked-out and purchased as normal
--- 3 p.m.*: the "submit wishlist" button goes hot again and things proceed as normal (though if a second crush develops maybe this sequence has to repeat?)

* - this time could be 2 hours?  4 hours?  long enough for the wishlists to process and to give people a reasonable chance to make their purchases.

OVERBOOKING:

A very fix-able part of the problem is people wish-listing events they don't intend to go to (e.g. wish-listing the same event ten times in hopes of getting into one), or - if they somehow get their entire wishlist fulfilled - can't go to (e.g. they've wishlisted 4 different events at the same time).  All this does is needlessly block out events for people further down the processing chain, as by the time the unwanted events are released back into the system thousands of other people have had their wishlists processed without access to those events.

So, solution #1. Do not allow overlapping events in the pre-registration wishlist.  Period.  If two or more of your desired events overlap then make a decision, pick one and wishlist it.

BLOCK-BUYING FOR GROUPS:

Another huge part of the problem (in my view, anyway) is being able to book and buy tickets for more than one person at a time.  Someone buying for a group who happens to be the very first in line can outright fill an RPG event before person #2 even gets a chance...and that just ain't right.

So, solution #2: have the initial round of wishlist processing only look at "for myself" purchases.  This would be do-able under my timing suggestion above as during the blackout period everyone's wishlist would in fact get processed twice - once for "for myself" tix and once for all other ticket types.

Just my thoughts...

Normal
Small
Posted by tdb lanefan

lanefan wrote:
I think my ideas will go a bit against the grain here, but someone's gotta say it...  Note these ideas are all to do with the initial crush.
First off, the idea of having the system auto-process all wishlists submitted before the deadline is very sound, and gets away from the silliness of trying to win a screen-refresh war. (and for overseas attendees, also gets away from having to be at a computer at exactly some weird hour of the day or night).  A further advantage is it then allows some tweaking to how wishlists get processed.  Probably simplest to have the timing go something like this:
--- 2 or 3 days prior: the "submit wishlist" button goes active, with a stern warning that you can only submit one (1) wishlist - get it right!
--- until noon: the "submit wishlist" button stays active but any wishlists submitted up to now go into a virtual holding pattern
--- noon: the "submit wishlist" button goes inactive (yes, the reverse of how it works now!) while all wishlists in the holding pattern are processed randomly and successful wishes are auto-added to cart; there is a 3-hour* window for those carts to be checked-out and purchased as normal
--- 3 p.m.*: the "submit wishlist" button goes hot again and things proceed as normal (though if a second crush develops maybe this sequence has to repeat?)
* - this time could be 2 hours?  4 hours?  long enough for the wishlists to process and to give people a reasonable chance to make their purchases.

This sounds like a good plan.  I would suggest a couple tweaks.
- At the end of the initial wishlist processing, send an email blast to anyone who had submitted a wishlist to notify them that their list has processed.  Start the timer for the window to check out your cart from the time the list processing is complete, rather than starting at a set time.  That way if there's a problem or slowdown in the list processing the checkout window won't end up shorter than promised.
- Don't re-enable the "submit wishlist" button until after the checkout time expires for the initial wishlists.  That ensures that any unwanted tickets from the first round have been returned, and makes them available for anyone submitting their list later.  Another email blast announcing when that will happen might be nice.  That could be done at the same time as the other email blast. 
lanefan wrote:

OVERBOOKING:
A very fix-able part of the problem is people wish-listing events they don't intend to go to (e.g. wish-listing the same event ten times in hopes of getting into one), or - if they somehow get their entire wishlist fulfilled - can't go to (e.g. they've wishlisted 4 different events at the same time).  All this does is needlessly block out events for people further down the processing chain, as by the time the unwanted events are released back into the system thousands of other people have had their wishlists processed without access to those events.
So, solution #1. Do not allow overlapping events in the pre-registration wishlist.  Period.  If two or more of your desired events overlap then make a decision, pick one and wishlist it.


The current wishlist processing already accounts for overbooking, so there's nothing to fix.  If I get an event from 7pm-8pm and there's a lower-priority event on my wishlist that runs  from 6pm-10pm the system won't let me buy it.  The whole point of allowing you to wishlist multiple events in the same time slot is to account for the possibility that the most desired event might be sold out before your wishlist is processed, so that you can get an alternate event instead.
lanefan wrote:

BLOCK-BUYING FOR GROUPS:
Another huge part of the problem (in my view, anyway) is being able to book and buy tickets for more than one person at a time.  Someone buying for a group who happens to be the very first in line can outright fill an RPG event before person #2 even gets a chance...and that just ain't right.
So, solution #2: have the initial round of wishlist processing only look at "for myself" purchases.  This would be do-able under my timing suggestion above as during the blackout period everyone's wishlist would in fact get processed twice - once for "for myself" tix and once for all other ticket types.
Just my thoughts...


I don't like this idea at all.  If the wishlists are being processed in some sort of round-robin process this rule would make it very difficult to play an RPG with friends or family, since everyone in the group would have to be randomly assigned a high enough spot in the queue to get one ticket before they all sell out.  If each person's wishlist is being processed in its entirety before moving on to the next person's list (as they are today) it simply forces the system to process the list twice, and doesn't really change anything, since no other tickets will be assigned before the second pass through the current person's list anyway.

 

Normal
Small
Posted by tdb derekguder

derekguder wrote:
Auto-purchasing events is pretty much a non-starter, for a number of reasons.
-
Derek Guder
Event Manager
Gen Con LLC

Are you at liberty to state the reasons?  There seem to be some creative IT types in this discussion, perhaps they may be able to suggest solutions if they know the problems that would have to be addressed.
 

Normal
Small
Posted by derekguder tdb

tdb wrote:
derekguder wrote:
Auto-purchasing events is pretty much a non-starter, for a number of reasons.
-
Derek Guder
Event Manager
Gen Con LLC

Are you at liberty to state the reasons?  There seem to be some creative IT types in this discussion, perhaps they may be able to suggest solutions if they know the problems that would have to be addressed.
 

It's not something we've explicitly discussed as a team, so this is not an official company response to the idea, but it's just not something I can ever see as actuality desirable.

Auto-purchase is attempting to solve a problem that doesn't exist by instituting a change that would have a huge impact on how we store credit cards and remove the ability for attendees to double-check and review their schedule before paying for it.

The only result I see from an auto-purchase system is more refunds and payment issues on top of a bunch of work to store credit cards in a way that really isn't worth the risk.

So it's not really worth considering, in my mind.

-
Derek Guder
Event Manager
Gen Con LLC

Normal
Small
Posted by tdb

I'm not sure there isn't a problem to address - some folks have stated that they have to take vacation from work in order to hang around by their computer on pre-registration Sunday, which seems to be a lot to ask of your customers.  Even people who don't work Sundays have to schedule a precious day off around the whole process.  Batch processing of wishlists would improve matters, but without auto-purchase that's only a partial solution.

If the cost of processing refunds exceeds the 5% surcharge, raise the surcharge.  That might serve as a disincentive for people to overbook, and they wouldn't need as many refunds. 

You could always make auto-purchase optional for to account for people who want to review their purchases.  But for people who would rather just build their wishlist, submit it, and get on with other things it seems very desirable.

Normal
Small
Posted by samlamiam

Another thought I had for auto-purchase is that there is a way to do it without storing credit card info.  People who want to auto-purchase (for whatever reason) could prepay a certain amount, which GenCon would hold as a credit (perhaps nonrefundable, like credits from leftover general tickets from a prior year).  Users could check a box saying "Apply existing credits to purchase these tickets if they are assigned to me."  People know they will spend a certain number of dollars on tickets every year, many would be willing to prepay in order to ensure their tickets were autopurchased.  Unused dollars would just go to buying general tickets before the Con.

I don't think auto-purchase is super important if the initial checkout period is extended.  Auto-purchase would be important if you had a waitlist/queue for sold-out events.  Otherwise the waitlist could become a bottleneck of putting tickets into a cart and waiting for it to expire before moving on to the next person.

I echo the comment saying group purchase is important to retain.

Normal
Small
Posted by lanefan tdb

tdb wrote:
lanefan wrote:BLOCK-BUYING FOR GROUPS:
Another huge part of the problem (in my view, anyway) is being able to book and buy tickets for more than one person at a time.  Someone buying for a group who happens to be the very first in line can outright fill an RPG event before person #2 even gets a chance...and that just ain't right.
So, solution #2: have the initial round of wishlist processing only look at "for myself" purchases.  This would be do-able under my timing suggestion above as during the blackout period everyone's wishlist would in fact get processed twice - once for "for myself" tix and once for all other ticket types.
Just my thoughts...

I don't like this idea at all.  If the wishlists are being processed in some sort of round-robin process this rule would make it very difficult to play an RPG with friends or family, since everyone in the group would have to be randomly assigned a high enough spot in the queue to get one ticket before they all sell out.  If each person's wishlist is being processed in its entirety before moving on to the next person's list (as they are today) it simply forces the system to process the list twice, and doesn't really change anything, since no other tickets will be assigned before the second pass through the current person's list anyway. 

In my idea the holding-pattern wishlists would ALL be processed through once, looking only at "for myself" tickets; then they would all be processed a second time, this time adding all other types of tickets while ignoring "for myself" as those are already done.

The reason I propose this is, I admit, a little selfish: I always go solo, and would like a chance of getting into some of the smaller (and even some larger) events before the block groups fill them up.

Sign in to write a new post. New Post
1
1