Eurofurence Information > Feedback

Queues and Queuing: The Who, The Why, The Where and the When

<< < (8/10) > >>

Cheetah:
Thank you to everyone for their innovative ideas! It would be very helpful if you could provide real-world examples - I'm all for trying out new things, but before I start experimenting with 1000 people at an already delayed convention, I would like to constrain the experiments to procedures that are proven to having worked at least once at a comparable event in the past :)

Cubitus:
Okay Cheetah, okay. I see that flight boarding is, even if it's a 99% matching use case, still not the same, as an airline got a different infrastructure.

So the concept ("how to avoid a super queue in my boarding area") is proven, but still it's likely EF would have different/own technology which still could fail (unless we borrow airline's equipment :)

So I'll go finding a best practice example in event branch! Promise! :)

EDIT: Would be cooler (for EF) to test a new procedure at a smaller event. I guess there are many..

Druon:

--- Quote from: Cubitus on 07.09.2014, 12:47:22 ---So the concept ("how to avoid a super queue in my boarding area") is proven, but still it's likely EF would have different/own technology which still could fail (unless we borrow airline's equipment :)

--- End quote ---

I think it isn't transferable to any kind of event just like that and it brings the problem that we are probably lacking equipment for it. There is simply no means to properly "call" a group. We don't have loudspeaker units in place all over the hotel to do public announcements. At the very least we would need a couple of display panels at strategic point just to make that part of the plan work.  Then there is the added stress of creating, distributing and managing those tokens. Keep in mind that you still want sponsors to have an edge. You need a lot of extra manpower for that.


I think we need to focus on maybe less elegant, but far more practical solutions. One thing I have in mind is to handle delays with pessimistic time estimates, rather than optimistic ones. It means that an event that is delayed due to technical issues of any kind will automatically announce a set amount of time for the delay, say an hour, to give them proper time to fix it as well as make things easy to communicate to the waiting audience.  Even if they should manage to fix the issue after ten minutes, they are still going to wait the rest of the 50 minutes before the start of the seating. That way people won't stick around because the doors may open sooner than the announced hour.

Should the problem prove to be more extensive than originally estimated,  this whole hour usually gives you ample time to add and announce extra time towards the delay. And again, I would suggest using a large unit of time again - ten minute increments are an appeal to start the queue. You don't want that unless you have the show/event ready to go.

Cubitus:
Druon, from your experience, how large are the queues right before the scheduled door opening times?

Just assuming (!) everything works prettily perfect and seating starts exactly as planned, there usually will still be a massive queue already, right? Because people come VERY early... (I guess you surely could not make them go away and come back later..)

Druon:
Cubitus, my intention isn't to reduce the size of a queue, but to prevent people from queuing for 3+ hours like they did during the last con. I doubt we have the means to keep large queues from happening, but we can improve with how they are managed. :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page