CampTix QR Code Feature

[usmankhalid]

Hello,

On the event day, the registration process is a real pain around the world in our WordCamps. I would suggest there should be a QR code in the camptix that would be generated for each ticket. On the day of registration, attendee just scan the QR code this will help to save 1000's of hours in our WordCamps.

This would include the following:

1. QR Code generation in the Camptix
2. Mobile App that read QR Code & Process Attendee

[dd32]

Removing the Q1 milestone as it's not applicable to WordCamp tickets.

@usmankhalid you may want to run this past the Community team at make.wordpress.org/community or in the #community-events/#community-team channels on ​WordPress Slack in order to find out if it's something the team is interested in building.

[casiepa]

Post on Community P2 : ​https://make.wordpress.org/community/2019/07/07/proposal-qr-code-for-wordcamp-badges/

[casiepa]

After discussion on slack #meta-wordcamp (starting from ​https://wordpress.slack.com/archives/C08M59V3P/p1566495258147700) the following steps were identified for Phase I:
1.1 Identify a QR code generator that is very popular, has unit tests, is actively maintained, etc
Something that gives a lot of signals that it won't have security vulnerabilities or bugs. And that has a composer package, because then we’d get automatic notifications from GitHub about security updates
1.2 Create as an enhancement for the existing camptix-attendance plugin (​https://github.com/WordPress/wordcamp.org/tree/production/public_html/wp-content/plugins/camptix-attendance)
1.3 add the QR code to the Notify feature, so that orgs could send out an extra email a couple days before the camp, telling people to save the email and bring it with them for registration on their phone or tablet
1.4 have the QR code hook into the attendance check in to mark an attendee as checked in. Volunteer needs to be logged in and URL could then be ​https://2019.narnia.wordcamp.org/wp-admin/?camptix-checkin=1&attendee_id=1234

For consideration:
2.1 For the QR string, if the full URL could not be used, {site ID}-{attendee ID} might be a bit better than {partial site slug}-{attendee ID}; it'd be easier to parse out
2.2 The volunteer would need to be editor or something on the WordCamp site. It's worth considering the implications of that. We could potentially do somewhere where, if a user opens the existing hidden check-in URL, they get a cookie or something that lets them also open that new check-in URL

[dd32]

A few weeks back at WordCamp Brisbane, I ran a test of this using a QR code checkin based on the WordCamp attendance UI.

We ultimately used "FirstName LastName" as the QR code contents, for several reasons:

• The existing UI searches by name, and as it supports exact-matching name searches it worked well
• The QR code isn't being shown publicly, it's only in an email with the attendee name, so we didn't consider having the name in the QR code a privacy issue
• Embedding the QR code into Camptix Notify functions could be done without any modifications there (We used Google QR code as an <img> element)

The feedback from those using the feature on the day was positive, although as we didn't really test it in advance as I mostly cobbled it together in an hour two days before the event, so there were a few issues..
The Instascan QR Code library used

1. Only supported modern devices - HTML5 Camera required, most libraries are the same
2. Camera feed froze up on apple mobile devices - Unsure why, it worked a few months ago
3. Had issues with scanning "complex" QR codes unless it had a super-clear and well aligned image
4. Gracefully degraded if the device didn't support it - A positive!

The QR Codes containing First Last worked well, but had two major drawbacks and several negatives

1. If you bought multiple tickets, that was multiple QR codes (ie. John Smith brought along his family, that's 4 QR codes to scan even though it was one purchase). In those cases it was easier to manually search Smith and select each manually
2. The longer the name, the more complex the QR code is, and the less easy it was for the QR scanner to read without a clear image
3. The QR image was emailed out at the bottom of the day-before "What you need to know for tomorrow" email - it should've been placed first
4. The Error correction was turned to 'High' allowing for 30% dataloss as it made the scans during testing quicker. As a result though, for the longer-name attendees it also required the more 'complex' QR codes for some that were harder to scan

As a result, here's my personal take on it:

• Yes, it was a success - but required more testing
• One of the first feedback fixes added was "If QR scan results in a single attendee, open the checkin dialogue immediately" and worked well thereafter
• The QR Code needs to be at the top of the "WordCamp is tomorrow" email, otherwise it's too hard to find at checkin time
• Should've been 1 QR per order. Using an order token here makes sense rather than their name
• Google QR Code embeds worked well - But ​is potentially deprecated even though the deprecation policy appears to have been invalidated
• Using a ​16 character alphanumeric token with 25% dataloss (Q) seems to be a good middle-ground for the contents of the QR code
• Using the 2nd half of the attendee's access_token as the QR code contents would be back-compat with previously bought tickets, and would fit the above QR option

Based on the above, I have a ​Github Branch which I've implemented most of the above in.

• Switched to using a ​more recently updated scanner in the hopes of getting Apple mobile support back (I haven't yet tested that)
• Cleaned up the code I used on the day
• Switched to using the 2nd half of the access_token as the QR code - That should be secure enough in this case
• Added a global "Enable QR scanning?" camptix attendance option, rather than the per-phone client-side setting we used (that wasn't needed)

Still needed:

• Adding a [qr] shortcode to Camptix Notify - Initially could just wrap the above mentioned Google Charts, but ideally encoding it into a data: uri image for offline viewing would be best
• Adding the QR Code Contents to the Export functionality, to allow it to be integrated with 3rd-party checkin systems (I guess?)
• Verifying it works with Apple mobile devices

(edit: The Apple device problem could've been due to not having the muted, playsinline attributes set on the <video> preview element - haven't yet confirmed that was the case though)

[casiepa]

@dd32 Thanks a lot for the testing, it for sure brings some nice extra info to think of!
I had been thinking this weekend a bit further after I passed registration at WordCamp Verona: How about adding a .pkpass as attachment? Saving that to your iPhone Wallet (or any existing tool on Android, I'm using e.g. Stocard to store my plane tickets AND my shopping cards) might be useful:

• The tool is made to store full screen QR codes. If the code cannot be read, all info needed is displayed on screen
• The screen by default (on most of the tools) goes to full lightning/brightness while showing the QR code, making it easier for scanners to scan the code.

I'm still thinking the attendee ID offers more possibilities then having first/name lastname, but we'll see when going more into the brainstorming or testing ;-)

[dd32]

Replying to casiepa:

How about adding a .pkpass as attachment? Saving that to your iPhone Wallet (or any existing tool on Android, I'm using e.g. Stocard to store my plane tickets AND my shopping cards)

That sounds interesting - As an Android user I have never actually seen a .pkpass file though, It seems I have a single email from an EU airline in 2016 which attached that and a PNG QR code. Maybe a "Add to wallet" link below it that downloads it would be an option for those users? (It's probably far more used outside of Australia.. we tend to use Google Pay/Apple Pay for the same thing here - but it doesn't support Event/Airline tickets unless purchased through their platforms AFAIK)

I'm still thinking the attendee ID offers more possibilities then having first/name lastname, but we'll see when going more into the brainstorming or testing ;-)

As mentioned above, I suggested (and the latest patch does) replacing it with a hash - It's far more targeted to a ticket but also not "guessable". It means that the QR stays the same if the name changes, don't have to worry about name lengths, privacy of the QR being read, etc.