search

WordPress / wordcamp.org

WordCamps are casual, locally-organized conferences covering everything related to WordPress.
https://wordcamp.org
127 stars 69 forks source link

CampTix QR Code Feature #613

Open ghost opened 5 years ago

ghost commented 5 years ago

Imported from https://meta.trac.wordpress.org/ticket/4162 Created by @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
ghost commented 5 years ago

Comment by @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.

ghost commented 5 years ago

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by coreymckrill. View the logs.

ghost commented 5 years ago

Comment by @ePascalC:

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

ghost commented 5 years ago

Comment by @ePascalC:

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

ghost commented 5 years ago

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by casiepa. View the logs.

ghost commented 5 years ago

Comment by @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 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:

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

(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)

ghost commented 4 years ago

Comment by @ePascalC:

@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:

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 ;-)

ghost commented 4 years ago

Comment by @dd32:

Replying to @ePascalC:

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.

ghost commented 4 years ago

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by nao. View the logs.

ghost commented 4 years ago

Comment by slackbot:

This ticket was mentioned in Slack in #meta-wordcamp by ryelle. View the logs.

CdrMarks commented 2 years ago

@timiwahalahti I saw your note in #meta-wordcamp. Is an option to throttle the emails being sent to mitigate this issue? Two ways I could imagine this could work:

  1. Research the number of emails per timeframe that Google allows. Throttle the speed at which emails are sent to be lower, maybe 10%, than that rate. One potential problem: if the rate is lowered and the throttled rated remains hard-coded, this problem could occur again.
  2. Monitor the email response codes when the email is handed off to Google for delivery. If an email fails to be accepted for delivery due to the rate limit, mark the current email as unsent, stop sending further emails, schedule a cron event to run one hour, maybe more, from now and keep sending.
iandunn commented 1 year ago

@vachan Hey 👋🏻 , I heard you were interested in contributing a check-in tool for WC Asia. Have you seen the work that's been done here? I think building on it might be a better approach than starting something new from scratch.

In addition to this ticket, here's some past discussions that'd be good to review:

@dd32 also has a prototype at https://github.com/WordPress/wordcamp.org/compare/production...dd32:feature/attendance-qr . A good place to start might be adding a feature flag to that, so we can merge it without affecting production. It could be something simple like:

if ( ! apply_filters( 'enable_qr_checkin', false ) ) {
    return;
}

Then, we could start opening issues in the milestone 10 to discuss specific additions/changes/etc.

What does everyone think about that?

dd32 commented 1 year ago

I saw your note in #meta-wordcamp. Is an option to throttle the emails being sent to mitigate this issue?

Just responding to this specifically about email throttling; WordCamp itself doesn't have any visibility into the email deliverability, as that's handled by our outgoing SMTP servers - they should be appropriately throttling emails to providers such as gmail and yahoo who are known to throttle incoming emails, I know there's definitely been some changes to that throttling setup in the last year.

dd32 also has a prototype at https://github.com/WordPress/wordcamp.org/compare/production...dd32:feature/attendance-qr

Just noting that the major issues I ran into using that, was that at the time, web pages processing a video stream for QR codes was really not that great an experience, it was clunky, slow on last-generation phones, and sometimes just didn't work at all. It was used at a WordCamp I was an organiser for in 2019. The QR codes in my experimental branch above didn't use a custom QR Code values, instead, the QR Code was simply their name (John Smith) to mimic the existing checkin apps search-by-name functionality. This is not ideal for several reasons, as it means you can't use the same QR codes for other things without sharing their name. WCEU in the past used a QR system on badges I believe where sponsors could scan your badge and get your details shared with them after the event - that just shared a unique per-person token string that could be exchanged after the event for Name+Email.