<div dir="ltr">From what I've seen at conferences I've been to, the problem is how to handle a large number of people as quickly as possible (Obviously :) ). There are generally two classes of attendees:<div>1) pre-registered with tickets (of some form, ie. electronic, printout, preprinted event tickets, etc. )</div>
<div>2) drop-ins or registered without documents/lost docs.</div><div><br></div><div>Group 2 will always have to be managed manually. However, once they're in the system and have their tickets they can proceed as group 1.</div>
<div><br></div><div>Group 1 generally has two requirements:</div><div>a) generate ID (lanyard/badge typically)</div><div>b) pickup package of materials</div><div><br></div><div>Typically, only the badge/ID is personal and therefore in need of on-demand capability. The materials are generally common to a class of people (eg. exhibitor, government attendee, public, VIP, sponsor, etc.) Once they have their ID, they can then proceed to pickup their appropriate materials package. I think the key to quick processing is to separate these steps, so the process is: </div>
<div><br></div><div>1) print your ID, (think airport kiosks - scan QR from ticket, print ID (differentiated by attendee type with name and QR containing personal info and maybe take a picture for security, if needed), then log transaction.</div>
<div>2) pass through security and present ID (could be at each kiosk or a separate line like at an airport), log.</div><div>2) go to appropriate booth for your materials. (present ID to volunteer, scan ID QR, log materials transaction)</div>
<div><br></div><div>That way you can aggregate all common materials in one place (ie. one booth per attendee type) and scale your army appropriately based on the number of kiosks you have and how many of each attendee type you're expecting. Separating ID printing from access security from materials pickup gives people lots of options (eg. print ID now and come back later, don't bother with the materials, etc.) and makes the process at each station more streamlined. </div>
<div><br></div><div>The only hard point-of-failure is the ID kiosks and hopefully you will have many of them so if any one printer goes down, there are others available. Kiosk network dependance can be limited by storing the attendee database locally (even a database with 1000's of attendees can be stored on a small device like a RPi or beaglebone). The kiosk will only poll the network for updates occasionally or if the presented ticket is not in the local database. It is also used to update a central server with log info which is not essential if it fails. This will mitigate occasional network/server/internet outages if they happen. <br>
</div><div><br></div><div>Keep in mind that the point of failure in most networks like this is not actually the network itself (assuming a private, wired LAN), but access to a database server that is trying to handle many transactions at once. If the server is not local, then the on-site internet bandwidth is usually the bottleneck. This is the issue that needs the most foresight when planning an event at a hotel or conference center. Another frequently overlooked bottleneck is wifi - never use local wifi at a large venue for your infrastructure - just don't. It's always a nightmare of conflict and will always be unreliable and of dubious security (it is always easier to secure a wired LAN in a public place than wifi). If you must have internet access, arrange for a dedicated, wired connection to the outside world with the venue owner. Even then, don't depend on broadband availability - you will likely still be sharing at some point with others (ie. exhibitors, video conferencing, etc.). Plan for low-bandwidth database pulls (eg. last minute, online registrations) and non-essential outputs (like attendee counts, event pics/web updates, etc.) A low cost, portable database server can easily be connected to a wired LAN and handle dozens or hundreds of kiosk transactions per second. Even a pair of redundant servers is not an expensive proposition these days.</div>
<div><br></div><div>You will also need a booth/help desk to handle issues that do come up (they always do, no matter how well you plan) but hopefully this will be mainly a backup/failover to take the outliers and keep the rest of the system running smoothly.</div>
<div><div>Note: for events that don't require security checkpoint access inside, printing a separate ID may be redundant - scanning+logging the ticket at the main security checkpoint may be enough.</div><div>Note 2: Highly personalized material is probably best handled with a custom event app these days.</div>
<div><br></div></div><div>My two cents :)</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 12:40 PM, Aurelius R <span dir="ltr"><<a href="mailto:maxrowsell@gmail.com" target="_blank">maxrowsell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What's the big problem with a network? It's the easiest, most reliable way to do it. I've never had problems with networks that are set up correctly. By default, they should be robust and reliable.<div>
<br></div><div>There are many ways to implement what you propose... but I think the easiest would be a simple app scanning QR codes, with a small LCD screen that shows what the camera is seeing (from the scanner's point of view, like with barcode scanner apps on smartphones). This could be run from a small Linux box, even, perhaps, a Raspberry Pi. Then have one (or two) boxes sitting where the organizers are, with screens, simply monitoring progress as people check in. That way they can go to any of the available kiosks, they scan their QR code, it looks them up and spits out the agenda via laser printer... done. Easy. Simple. </div>
</div><div class="gmail_extra"><br clear="all"><div>____________________<br>Peace, Love, Empathy<br><br>Alexander Max Rowsell<br></div><div><div class="h5">
<br><br><div class="gmail_quote">On 29 January 2014 13:45, Jamie <span dir="ltr"><<a href="mailto:jamie@steppinofftheedge.com" target="_blank">jamie@steppinofftheedge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Thx Alan.<br><br>I think their driving hope was to get away from the last name partitioning. I agree the robot aspect could be failure-prone. Of course if I were building it it'd probably have big giant flashing screens.like that selection system in Starship Troopers. <br>
<br></div><div>If they had a local copy of the db on each machine or local network they could handle the just-in-time print with mitigating the network concerns.<br><br><br></div></div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jan 29, 2014 at 12:18 PM, Alan Gardner <span dir="ltr"><<a href="mailto:alanctgardner@gmail.com" target="_blank">alanctgardner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">The idea of using a robot to dispense pre-printed materials is alluring, but it seems like it might be more failure-prone than print-on-demand. My low(ish)-cost proposal:<div><br></div><div>- Partition your attendees by last name, so each last name can only use one terminal. Put the attendee list for each terminal on a USB key (maybe a SQLite database?).</div>
<div>- Have n terminals, each with a range of last names, with a B&W laser printer attached directly</div><div>- Attendees check-in on the terminal with a unique code from an email, and the local printer prints on demand and updates the database on the USB key.</div>
<div><br></div><div>Each terminal is stand-alone, so there's no risk of network issues. You might want to have n+1 terminals, so you can move the USB key to a new terminal in the event of a printer/computer failure. </div>
<div><br></div><div>Just a thought.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Jan 29, 2014 at 12:07 PM, Jamie <span dir="ltr"><<a href="mailto:jamie@steppinofftheedge.com" target="_blank">jamie@steppinofftheedge.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>Hello,<br><br></div>I'm working on web site component of a conference with Carleton U and the organizer mentioned a desire to improve the registration check-in process. Thought maybe someone on this list might have seen a solid solution or have an idea on creating one?<br>
<br></div><b>The Details<br></b><ul><li>Most conferences default to having pre-printed schedules, name badges and materials available through a volunteer base co-ordinating people into lines based on last name to get their materials.<br>
<br></li><li>Some use QR code or kiosk to input email and on-demand print of same name badges, materials, etc.<br><br></li><li>They would like to find a balance between the two which have the pros of each and none of the cons - no lines, small need for volunteer army to checkin but not at-risk of printer malfunction or network issue from on-demand print.</li>
</ul><p>My brain went to grocery store self-checkout change return system concept. Some kind of setup that allows:</p><ul><li> pre-printed materials placed into envelopes that are numbered and/or QR coded</li><li>When person arrives they provide email or QR code</li>
<li>The system drops their envelope out for pickup.</li><li>If network goes down, volunteers only need to check name to # to numerically find an envelope.</li></ul><p> No idea of budget - but I'd be happy to connect the dots for anyone interested in pursuing.</p>
<span><font color="#888888">
<p>Jamie<br></p></font></span></div>
<br></div></div>_______________________________________________<br>
Lab mailing list<br>
1. subscribe <a href="http://artengine.ca/mailman/listinfo/lab" target="_blank">http://artengine.ca/mailman/listinfo/lab</a><br>
2. then email <a href="mailto:Lab@artengine.ca" target="_blank">Lab@artengine.ca</a> to send your message to the list<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Lab mailing list<br>
1. subscribe <a href="http://artengine.ca/mailman/listinfo/lab" target="_blank">http://artengine.ca/mailman/listinfo/lab</a><br>
2. then email <a href="mailto:Lab@artengine.ca" target="_blank">Lab@artengine.ca</a> to send your message to the list<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Lab mailing list<br>
1. subscribe <a href="http://artengine.ca/mailman/listinfo/lab" target="_blank">http://artengine.ca/mailman/listinfo/lab</a><br>
2. then email <a href="mailto:Lab@artengine.ca">Lab@artengine.ca</a> to send your message to the list<br></blockquote></div><br></div>