CampTix: Add an attendee content block with check-in

[ryelle]

Add a more obvious way (a block) to show content to only people who have registered for the event, and check them in as "attended" when it's viewed. This also cleans up the conditions for displaying login or content & the validation errors. Lastly, this removes the notices about logging in & the success message, since these are obvious from context and just create noise on the page.

This block can be used on pages to provide Zoom passwords or other "private" content, without relying on attendees saving an email.

Screenshots

In the editor, this wraps the InnerBlocks with some text explaining that the content will be private. IMO this needs the start & end visuals, since it's hard to know if you're in the inner-block container or not, and it would be bad for private content to be accidentally public. But I'd like a designer's eye for a better UI than this :)

On the front-end, it uses the camptix_private UI for everything. If unauthenticated, the form asks for an email. Once logged in, the protected content is displayed.

Errors verifying info will show above the form.

How to test the changes in this Pull Request:

1. Add an "Attendee Content" block to your page
2. You should only be allowed to add it once, but you can add it to multiple pages
3. Add any content inside the block
4. Save the page
5. View the page, you should see a login form instead of the content
6. Log in using a valid attendee email — make sure the attendee is not "marked attended" yet
7. After success, you should see the content, and now the attendee is marked as attended
8. Reload the page, the content should still be visible

Try creating edge cases by removing or altering the tix_view_token cookie, or tix_view_token meta value, or by changing the attendee to cancelled, or by using different emails, etc.

(Note: tagging as COVID-19 Response since it can help track attendance in online WordCamps)

[coreymckrill]

I realize this is still awaiting design, but here are a couple of initial thoughts:

• 👍 Worked in local testing. Setting a ticket to Refund after the cookie had already been set caused the private content to go back behind the login form. Reinstating the ticket then re-revealed the content without having to log in again.
• I think it might be worth adding a block setting to toggle whether accessing this particular piece of content automatically marks the person as attended or not. I can see a use case for this block of giving someone access to something before the event and not wanting it to actually mark them as attended.

[coreymckrill]

This is probably more relevant for block plugins that are being submitted to the Block Directory, but per the guidelines the block.json file should have at least one of editorScript/script and at least one of editorStyle/style properties.

[ryelle]

I left those out since we didn't have access to register_block_type_from_metadata on WC.org yet, but now that we do I think I'll add that in 👍

[iandunn]

adding a block setting to toggle whether accessing this particular piece of content automatically marks the person as attended or not. I can see a use case for this block of giving someone access to something before the event and not wanting it to actually mark them as attended.

+1

I think the option should be off-by-default too, since it doesn't seem like a safe assumption to me. That's especially true of in-person events.

[ryelle]

yep, that's what I went with in d1eac20

[ryelle]

oh wait, what do you mean by "off-by-default"? I think it should default to marking people as attended, since in person events will most likely be the main users of this, for day-of-event content.

[iandunn]

The check-in tool would still be the recommended way

I'm not sure I see the point in having this option for in-person events then. Wouldn't they already be checked-in before they access the day-of content?

If so, then this is only relevant for online events, so I think the option should be always-off for in-person events.

we're not tracking any attendance info from online events

That's a great point. I'm fine using "viewed day-of content" as a proxy for "attended an online event", just not in-person events.

Even for online events, though, I still think the button should be off by default. We have no way of knowing if the content inside the block is day-of content or something else.

[ryelle]

I understand what you're saying, but we're trying to build up the interaction piece for online events too. This isn't for hiding the livestream, so someone who only watches the talks wouldn't be "attended". This is for things like private zooms for hallway tracks, or other ways to interact with other attendees.

I imagine we'll see hybrid events before we move fully back in to in-person events, and even then I think someone who can't attend in-person (whether due to the current issues with covid, or more generally, a disability) but still gets involved should be considered attended.

I think "day of" content will be the majority use case. Even if not, organizers can turn off the check-in feature. And even if they don't, we'll only check-in people if they view it during the event. So I think for the least friction for most organizers, we should keep the default to on, "check in", for all events.

[iandunn]

Are you saying that it would only mark someone as attended if both of the following are true?

• it's an online event
• the person views the content while the event is happening

If so, then that's good enough for me.

[ryelle]

By default, we'll mark people attended only during the event, for any kind of event.

The organizer has the option to turn this off per-block, if they're adding content where that doesn't make sense.

[iandunn]

Yeah, I know there's an option to turn it off, but I don't think that's enough to keep the stats accurate. Most people will just go with whatever the default is, rather than paying close attention and considering the implications.

Although, that also means that if it were off by default, then there'd be lots of cases where the organizer should enable it, but doesn't, which would lead to inaccuracy in the other direction.

So maybe it'd make sense to set the default it to on for online events, but off for in-person events? That would reflect the correct setting in the majority of situations, and the organizer can still flip it if they want.

[ryelle]

adding a block setting to toggle whether accessing this particular piece of content automatically marks the person as attended or not

Good idea— I added that in d1eac20 — it defaults to on, but if it's turned off, attendees are not marked "attended".

[paaljoachim]

Thanks for the heads up in regards to this issue, Kelly! I noticed you mentioned the issue in the design slack channel.

Here is an example of where we need a conditional logic block. Something happens and if true do something. Could be show/hide blocks. In this case read a list of e-mail addresses from a list and if the users who has logged in has their e-mail address on the list then do something like show a group block with image, text and a zoom link. If they do not have their e-mail address on the list then show something else.

Instead of creating a very specific attendee conditional logic block what about creating a more general conditional block or perhaps there is already one out there that can be modified and used. Here is an older Conditional Blocks issue: WordPress/gutenberg#6866 (There are also some mentions of Conditional block plugins.)

Bottom line is if we get a conditional block into Gutenberg then this could also be extended for other uses later on.

[mapk]

Hey @ryelle, I've been thinking this through a bit. I'm not sure how to test this (where do I find the "Attendee Content" block?). But I worked through a flow that I thought might help.

I imagined the block working similarly to the Group block. It's basically a container, but it displays a login form on the frontend (unlike the Group block). Once the user logs in (on the frontend), they can see the contents of the block. Is that correct?

Assumptions:

1. The user wouldn't see the login form in the Editor. Rather, it would mimic the Group block behavior.
2. BUT when content is added, this block retains a dashed outline at all times indicating something special about this block's content. A dashed outline felt natural as a way to convey hidden content.
3. The block description would talk about how this blocks works?

Anyways, here's a go at it. Let me know if I'm way off. 😄