[Lab] QR / Registration / ??? Concept

Thu Jan 30 16:48:01 EST 2014

>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:
1) pre-registered with tickets (of some form, ie. electronic, printout,
preprinted event tickets, etc. )
2) drop-ins or registered without documents/lost docs.

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.

Group 1 generally has two requirements:
a) generate ID (lanyard/badge typically)
b) pickup package of materials

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:

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.
2) pass through security and present ID (could be at each kiosk or a
separate line like at an airport), log.
2) go to appropriate booth for your materials. (present ID to volunteer,
scan ID QR, log materials transaction)

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.

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.

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.

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.
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.
Note 2: Highly personalized material is probably best handled with a custom
event app these days.

My two cents :)

On Thu, Jan 30, 2014 at 12:40 PM, Aurelius R <maxrowsell at gmail.com> wrote:

> 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.
>
> 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.
>
> ____________________
> Peace, Love, Empathy
>
> Alexander Max Rowsell
>
>
> On 29 January 2014 13:45, Jamie <jamie at steppinofftheedge.com> wrote:
>
>> Thx Alan.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>
>> On Wed, Jan 29, 2014 at 12:18 PM, Alan Gardner <alanctgardner at gmail.com>wrote:
>>
>>> 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:
>>>
>>> - 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?).
>>> - Have n terminals, each with a range of last names, with a B&W laser
>>> printer attached directly
>>> - 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.
>>>
>>> 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.
>>>
>>> Just a thought.
>>>
>>>
>>> On Wed, Jan 29, 2014 at 12:07 PM, Jamie <jamie at steppinofftheedge.com>wrote:
>>>
>>>> Hello,
>>>>
>>>> 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?
>>>>
>>>>
>>>> *The Details*
>>>>
>>>>    - 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.
>>>>
>>>>    - Some use QR code or kiosk to input email and on-demand print of
>>>>    same name badges, materials, etc.
>>>>
>>>>    - 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.
>>>>
>>>> My brain went to grocery store self-checkout change return system
>>>> concept. Some kind of setup that allows:
>>>>
>>>>    - pre-printed materials placed into envelopes that are numbered
>>>>    and/or QR coded
>>>>    - When person arrives they provide email or QR code
>>>>    - The system drops their envelope out for pickup.
>>>>    - If network goes down, volunteers only need to check name to # to
>>>>    numerically find an envelope.
>>>>
>>>> No idea of budget - but I'd be happy to connect the dots for anyone
>>>> interested in pursuing.
>>>>
>>>> Jamie
>>>>
>>>> _______________________________________________
>>>> Lab mailing list
>>>> 1. subscribe http://artengine.ca/mailman/listinfo/lab
>>>> 2. then email Lab at artengine.ca to send your message to the list
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Lab mailing list
>> 1. subscribe http://artengine.ca/mailman/listinfo/lab
>> 2. then email Lab at artengine.ca to send your message to the list
>>
>
>
> _______________________________________________
> Lab mailing list
> 1. subscribe http://artengine.ca/mailman/listinfo/lab
> 2. then email Lab at artengine.ca to send your message to the list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://artengine.ca/pipermail/lab/attachments/20140130/d65374ac/attachment.html>