Making WordPress.org

Opened 10 years ago

Closed 3 years ago

Last modified 3 years ago

#262 closed enhancement (reported-upstream)

Automate WordCamp Gravatar Badge Creation

Reported by: iandunn's profile iandunn Owned by:
Milestone: Priority: high
Component: WordCamp Site & Plugins Keywords: needs-patch good-first-bug
Cc:

Description

The process for creating Gravatar badges for WordCamp attendees is kind of clunky and is more work for organizers than it should be. There are steps of the process that we can automate to make it easier for them.

Basically, we should make it so that all they have to do is visit a page in the Admin Panels, enter a few options, and then hit submit. Then they should get a .zip file containing everything they need to take into InDesign.

1) Generate better CampTix attendee CSV, that only has the data needed. Let them customize which data fields to include.
2) Take the generated CSV and runs the script to slurp Gravatars and generate the final CSV. Prompt for the filesystem path they want to use. Send zip file.

After this is done, the documentation should be updated to reflect the new process.

In terms of architecture, my initial thought would be to build an independent plugin that extends the CampTix_Addon class.

Attachments (7)

patch_262_meta.diff (21.4 KB) - added by bansod_deven 9 years ago.
Patch for #262 Meta
262.2.diff (8.6 KB) - added by iandunn 7 years ago.
UX flow.png (31.0 KB) - added by tinkerbelly 5 years ago.
Suggested UX flow
Badge Generation Screen.png (33.4 KB) - added by tinkerbelly 5 years ago.
Badge generation screen
2019-06-10 20.25.43.gif (204.3 KB) - added by tinkerbelly 5 years ago.
Badge landing page.png (53.7 KB) - added by tinkerbelly 5 years ago.
Screenshot 2019-07-09 at 18.37.16.png (337.8 KB) - added by tinkerbelly 5 years ago.

Download all attachments as: .zip

Change History (33)

#1 @bansod_deven
9 years ago

  • Keywords needs-testing dev-feedback added

Patch Added

Changed Steps will be :

  1. Go to Tickets > Tools > Export Selected Columns
  2. Select Columns to Export from all Columns
  3. Select Questions to Export from all Questions (Blank if the ticket does not have that question)

Here, the fields needed in InDesign Badge making (i.e. Columns 'first_name', 'last_name', 'email', 'twitter') are checked by default.

  1. If you want to fetch the Gravatars of the attendees too, then check the Checkbox.(checked by Default)
  2. Select the Folder where Temporarily ZIP file contents can be stored on the server. (Should have adequate permissions.)
  3. Click Generate CSV/ ZIP. This generates a CSV if the Gravtars checkbox is not checked. Or else generates a ZIP containing the CSV for InDesign and the Gravatar Images that were pulled using the Email IDs.

Testing and Feedback needed though. Any Changes that the past organizers would like to suggest, please post them here, I will surely try to include them.

@bansod_deven
9 years ago

Patch for #262 Meta

#2 @bansod_deven
9 years ago

Have made out the Patch with the above mentioned Process as a Plugin available at :
Camptix - Fetch and Export Addon

Have submitted it for Plugin Review too.

Also, can anyone please confirm if I am moving in the right direction or suggest any changes regarding the patch as well as the new process.

#3 @iandunn
9 years ago

  • Keywords good-first-bug added; needs-testing dev-feedback removed
  • Owner set to iandunn
  • Status changed from new to accepted

That's awesome, you've made great progress on this :)

Here's what I think the next steps are:

  1. PHP doesn't come with ZipArchive activated by default, so we should display an error message on the page if it's not available.
  2. A lot of the columns would never be used on a badge, so we should only have options for the relevant ones:
    • First and Last name
    • E-mail Address
    • Ticket Type
    • WordPress.org Username
    • Coupon
  3. We don't need an option to 'Include Gravatars', since the whole goal of this ticket is to get them.
  4. If a camp has hundreds or thousands of attendees, the script will take a very long time to run, so we shouldn't make the user wait that whole time.

    Instead, after they submit the form, we should display a message saying that the script is running, and to check back in a few minutes. Then, we can fire off an asynchronous process to generate the zip file.

    Once that's done, we'll show the user a link to download the file through their browser, rather than the pending message. This is also more user-friendly than asking them to download the zip file over s/FTP.

    We can't store the zip file in wp-content, though, because that would expose any private information (like e-mail addresses). So, instead the file should be stored in get_temp_dir(), and then the download link will actually be a form submission, and the function that handles the POST will just output the zip file contents as a download, similar to how the regular Export tool works.
  5. The plugin should usleep( 100000 ) just like the CLI script did, so that Gravatar.com isn't flooded with requests.

#4 @valeriosza
9 years ago

  • Cc valeriosza@… added

#5 @iandunn
8 years ago

The script has had some updates lately, so those will need to be incorporated into the patch too.

#6 @iandunn
8 years ago

Related: https://make.wordpress.org/community/2016/02/12/name-badges-are-hard-to-make-and-confusing-for-organizers/

One idea that came up there was using the Customizer so organizers could design the badge colors, fonts, etc

#7 @iandunn
8 years ago

There's a new tool for creating badges in HTML/CSS, so the InDesign script should be integrated with that, rather than being a separate plugin.

#8 @iandunn
7 years ago

In 4316:

CampTix Badge Generator: Move attendee data functionality to common.php

This makes it accessible by both the HTML module and the InDesign module.

See #262

#9 @iandunn
7 years ago

In 4326:

CampTix Badge Generator: Add core functions for generating InDesign badges

See #262

@iandunn
7 years ago

#10 follow-up: @iandunn
7 years ago

  • Priority changed from normal to high

r4326 merged and improved the core functions from the old bin script, so this just needs UI now.

262.2.diff contains a notes and stubs to establish a direction for that.

#11 in reply to: ↑ 10 @cwittie
7 years ago

Replying to iandunn:

r4326 merged and improved the core functions from the old bin script, so this just needs UI now.

262.2.diff contains a notes and stubs to establish a direction for that.

Can you confirm that by UI, you just need a PNG mock-up of a badge design?

This ticket was mentioned in Slack in #community-events by bph. View the logs.


7 years ago

#13 @iandunn
7 years ago

No, this plugin doesn't actually interact with the InDesign file, it just generates the CSV file that gets imported into InDesign's data merge tool.

The UI that's needed is the interface for the plugin itself, within wp-admin. Right now, the only interface available is WP-CLI commands that only a few people have access to run.

#14 @iandunn
6 years ago

  • Owner iandunn deleted
  • Status changed from accepted to assigned

#15 @iandunn
5 years ago

At this point, I'd probably discard 262.2.diff and start from scratch with a React/REST based solution, since this page will benefit greatly from interactive flow, and

Conventions for that are still being established, though, so it'd be good to get feedback early-and-often as the patch develops.

#16 follow-up: @iandunn
5 years ago

Design

We're basically trying to automate these manual steps.

To see the current page (which is just a placeholder), you can visit Tickets > Tools > Generate Badges > InDesign in any wordcamp.org site or local sandbox.

That screen will need to provide a way for organizers to enter some parameters, and then download a ZIP file. The ZIP file can take several minutes to generate, which is why it'd be helpful to have something interactive here.

The options that they can enter are:

  • Which ticket(s) they'd like to include. By default we'll generate badges for all attendees regardless of what ticket they bought, but if specific ticket(s) are chosen here, then we'll only generate badges for the attendees who purchased those tickets. Probably a list of checkboxes. This would be optional and all checked by default.
  • A date/time field to specify which attendees should be included. All attendees who registered on/after this point in time will be included. This is useful because organizers often want to run multiple batches, and it's easier if the subsequent batches don't include attendees who've already gotten a badge. For example, a organizer might run a batch and send it to the printer 1 week before the event, and that would cover 90% of attendees, but they'd need to do a second batch the night before the event to cover the remaining 10%). Probably a text field with a date picker popup. This would be optional and default to being empty.
  • Which CampTix admin flags they'd like to filter by. By default we'll generate badges for all attendees, regardless of which flags they're assigned (if any). If flag(s) are selected here, then we'll only generate badges for attendees who have those flags. You can see how admin flags are configured under Tickets > Setup > Admin Flags. Common examples are speakers, sponsors, etc. Probably a list of checkboxes. Optional and all checked by default.

The generated ZIP file will contain:

  • A CSV file that can be modified as needed, and then imported into InDesign's
  • Gravatars for each of the attendees.

I'm imaging something along these lines:

  1. User chooses options and clicks submit button
  2. A <Modal> appears, and inside of it is a <Spinner> and a message to "please wait, this can take a few minutes, don't navigate away from the page." I think a modal is appropriate here, because we don't want to do anything else until they download the file, but it may be a grey area.
  3. If the ZIP fails to generate or nothing happens after a long time, the spinner is replace with an error message and a button to retry.
  4. Once the ZIP file is successfully generated, the spinner/message is replaced with a download button.
  5. After the user starts the download, they can close the modal and browse to other screens while its being downloaded. We could tell them that above the download button or something.

Development

I think it'd be good to do something similar to the way that Quick Navigation Interface uses Gutenberg's abstraction layer for React and its components to build a standard React application inside of wp-admin.

@tinkerbelly
5 years ago

Suggested UX flow

@tinkerbelly
5 years ago

Badge generation screen

#17 follow-up: @tinkerbelly
5 years ago

Attached above are rough mockups suggesting how this might work from a user experience point of view.

Notes & questions:

  1. I struggled with getting the labels right here. "Ticket type" feels confusing because there are types of *tickets*, and also types of *attendees*. I tried to avoid the label "Admin flag" because it feels a wee bit unclear, but it may be that if whomever is generating the badges is familiar with the ticket setup process (in which they would have set the admin flag, or are those provided by default?) understands this phrasing.
  1. Instead of "generate registrations since [x] date", which requires that organisers remember the exact date (and possibly time, for accuracy) that they last generated tickets, what about a toggle that only generates tickets that haven't already been generated? This would require storing data somewhere about what tickets had been generated already, but would allow for much easier batch printing like this.
  1. Instead of using a modal and spinner and asking people to wait whilst the job completes, would it be possible to run the job in the background? This would allow people to navigate elsewhere rather than waiting around, and then we could allow for downloading generated badges in a centralised place as well.
  1. This is using components from @wordpress/packages for simplicity (since those components exist in Figma!) but it'd probably make more sense to use the default WordPress input controls here for now, so as to be consistent with other wp-admin pages. The checkboxes may end up being a wee bit harder to parse on large screen with the side-by-side label alignment, but otherwise the functionality will be more or less the same.

Note for the future: it might also be possible to finagle a way of generating these badges with Figma, which more designers may have access to (and can easily access via the WordPress account). That said, Figma isn't a print design tool, their API is still limited, and it might not wind up being helpful at all. It has PDF export functionality but doesn't support the CMYK colour space, or any crop marks on artboards (without a hacky solution). Just throwing it out there for future consideration.

#18 in reply to: ↑ 17 @iandunn
5 years ago

Replying to tinkerbelly:

Attached above are rough mockups suggesting how this might work from a user experience point of view.

Thanks! These are great :D

"Ticket type" feels confusing because there are types of *tickets*, and also types of *attendees*.

Yeah, that's a problem in CampTix itself too, not just this. "Ticket Type" seems clear enough to me personally, though, and I'm not sure what a better alternative would be.

I tried to avoid the label "Admin flag" because it feels a wee bit unclear

Yeah, it's probably not the best name for the feature. It seems like using the name of the feature may be important, though, because otherwise the organizer won't know where those labels are coming from, etc. Well, I guess we could add a link to the Admin Flag screen, maybe that'd be a good idea regardless of what we call it on this screen.

"Generate Tickets"

It seems like "Generate Badges" might be a more accurate label for that button, or even more accurately: "Generate Badge Data", since we're just generating the pieces of information that will be used to create the actual badges, rather than generating the badges themselves.

  1. Instead of "generate registrations since [x] date", which requires that organisers remember the exact date (and possibly time, for accuracy) that they last generated tickets, what about a toggle that only generates tickets that haven't already been generated? This would require storing data somewhere about what tickets had been generated already, but would allow for much easier batch printing like this.

I think that's a really great idea. I do worry that there may be some edge cases where it'd break down, but in those situations someone could always just export everything, and manually remove the unwanted entries. I think it'll probably save time more often than it adds time.

  1. Instead of using a modal and spinner and asking people to wait whilst the job completes, would it be possible to run the job in the background? This would allow people to navigate elsewhere rather than waiting around, and then we could allow for downloading generated badges in a centralised place as well.

From a technical perspective, the job will run in the background either way, so we can provide a way for them to leave and come back if we'd like. I just assumed that people would leave it open and then create new tabs (since that's what I'd do).

I'm guessing there are some who'd do that, so maybe we still want the modal/spinner, but we can also tell them that they can leave the page if they want, and they'll get an email when it's ready.

When they come back, we can shown them a "Download" button above the form or something? But if they're still there when it finishes, we show them a download button inside the modal? It seems like it'd be nicer if they got the same UI in both situations, though.

For v1, we might want to keep it simple and just support one method or the other, though.

For the notification, were you thinking about a desktop notification through the browser, or did you only mean the email?

Once this is all worked out, it'd be helpful to have a wireframe to clearly communicate how it'll look/flow.

  1. This is using components from wordpress/packages for simplicity (since those components exist in Figma!) but it'd probably make more sense to use the default WordPress input controls here for now, so as to be consistent with other wp-admin pages.

Hmmm, I'm not sure about that. It feels like Phase 2 of Gutenberg will be expanding those components outside the editor, and I'll go out on a limb and assume that the new wp-admin screens created in the future will be React pages (at least if the content/interaction of that screen warrants it). So, given those assumptions, it seems like doing this screen with G's components would future-proof it, and also help experiment with ways that plugins (and eventually Core itself) can adopt the new UI.

I'm not 100% sure about that, though, what does everything else think?

Note for the future: it might also be possible to finagle a way of generating these badges with Figma

That's a cool idea, thanks!

We've also already got an HTML generator inside the Customizer, for people who don't have access to InDesign. That's geared more towards camps without a designer, while the InDesign tool is geared more towards ones that have professional designers volunteering, and want to have high-quality badges. The InDesign process has been around for a long time, though, so maybe designers don't even use InDesign as much anymore? I'm not sure what the most popular tools are today.

If Figma could provide similar features, and be more accessible, then that'd be a great thing to explore ( in another ticket :) )

#19 in reply to: ↑ 16 @iandunn
5 years ago

Replying to iandunn:

Development

I think it'd be good to do something similar to the way that Quick Navigation Interface uses Gutenberg's abstraction layer for React and its components to build a standard React application inside of wp-admin.

Actually, Compassionate Comments is probably a better example, since it creates an actual admin screen just like this one would.

#20 @tinkerbelly
5 years ago

This is great feedback, thank you! Rather than working line-by-line, I'm going to try to point-form some responses here so as not to get too wall-of-texty:

  • I've added (Admin flag) in parentheses beside the header—that way, users will know where these are coming from, and can link back to the page, but the header still makes sense.
  • Definitely typed "Generate Tickets" all over for no good reason other than not being 100% attention-paying-y. Fixed now! Side note, is there a better term than "generate"? It feels so .... clinical. Would "Building" or "making" work better in some places, to be a bit friendlier? Or maybe, if we were to go with "Generating badge data", would "Exporting badge data" or "building badge data" or similar work better?
  • Let's use a modal as well as giving the option to come back later—this allows for more user flexibility and the modal makes it feel a lot more like something is happening, where before the flow sort of came to a dead end. If you'd like to prioritise one over the other, the modal approach is probably the most expected and immediate flow, so let's start there.
  • If we're going to allow for users to return back and download the generated badge data, we probably want to add a section for that to the generate badges landing page, so it's easy to find in a centralised place. I can mock this up as well... and maybe we can streamline the page a bit while we're at it?
  • In terms of a notification: I think it would make sense to a) send an email and b) send a Dashboard/wp-admin Notice to let them know their badge data is available for download. Would there b a way to avoid triggering these notices if the data has already been downloaded though? That would be super groovy.

#21 @iandunn
5 years ago

  • I agree that "building" and "making" are more friendly than "generating". "Generating" sounds more "correct" to me, but that's probably just because I'm an engineer. "Exporting" sounds "correct" to me too, but probably isn't as friendly as "building" and "making". I agree that, for something like this, it makes sense to go with something more user-friendly. "Building badge data" has a nice alliterative ring to it :) It'd be fun if there were a good synonym for "data" that starts with a "b", but I can't find one :(
  • Adding a note to the badges landing page sounds good to me. For the InDesign page, I was thinking that, when they come back, if the data is still being built, the modal would pop up with the progress bar, just like it would as if they'd never left the page. Then, once it's finished, the spinner goes away and the download link is shown. So, they get a consistent interface/flow regardless of whether or not they stay on the page the whole time. That's just my first thought, though, I'm open to any other ideas you have!
    • The modal should be dismissible, though, so that they can restart the process if it gets stuck or something.
  • Streamlining the landing page sounds great!
  • The email notification should be fine. The wp-admin notice is doable, but might take a bit more time than we want to invest v1, since we'd have to add code to track if they've downloaded it or not.
  • Those Figma wireframes look great!
  • I'm guessing we'll want a spinner rather than a progress bar, since determining how far along in the process the script is will probably be too much of a time investment for v1. It'd be good to have some text letting the user know that the process could take up to 10 minutes, though.
  • I really like the friendliness of the "in progress" text, but the pedantic/literalist in me is a little offput by the promise that the data will be ready when they return, since it can take 5-10 minutes, and they might return before that. Maybe something like,

    Your badge data is being compiled. This can take up to 10 minutes, so feel free to navigate elsewhere while you wait, and you'll receive an email when it's finished.


    That's just a rough draft, though, and I'm definitely open to other ideas.

#22 @tinkerbelly
5 years ago

"Building badge buckets?" ;) I'm not convinced that either "making" or "building" are really good terms here—there's something that feel inherently awkward. Would "Preparing" (as in, "Preparing badge data") maybe work better here?

I'm not opposed to showing the Modal if the process is still in progress, but I wonder about users who might dismiss the dialogue, especially since it could take some time to complete. We'd probably want to provide a way here for them to see a) the exports they've created in the past and b) the current status of the process. Here's a quick mock for what that might look like:

https://meta.trac.wordpress.org/attachment/ticket/262/Badge%20landing%20page.png

I think if a progress bar isn't possible, maybe just a notification that the process is in progress might suffice. I'm a bit wary of spinners that just loop infinitely and don't really give a clear indication of progress.

What about this:

https://meta.trac.wordpress.org/attachment/ticket/262/Screenshot%202019-07-09%20at%2018.37.16.png

#23 @iandunn
5 years ago

  • "preparing" sounds good to me.
  • Leaving the spinner off sounds good too.
  • If we store the past exports, we'll need to delete them once the camp is over, to avoid eventually taking up too much disk space. I don't think that'll take too much time, but if it becomes a rabbit hole it'd probably be best to push it to v2.
  • On the current landing page, there isn't an HTML/CSS export for the organizer to download; instead the button links to a tool in the Customizer where they can enter the custom CSS they want, and then print the badges. I've added you to the 2017 Testing site so that you can see how it works. In light of that, do you think there should be a secondary page for the InDesign export/download process, or maybe it would still be best to have it streamlined on the same page as the HTML/CSS button?

#24 @tinkerbelly
5 years ago

👍👍👍

This all sounds good by me!

As per the last point, perhaps the two buttons should be labelled to better indicate the actions they take:

  • Create badges with CSS
  • Get data for InDesign

We could also move the "past downloads" section to the InDesign page, rather than having it on the main badges page, which might make a bit more sense in this context.

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


4 years ago

#26 @dd32
3 years ago

  • Resolution set to reported-upstream
  • Status changed from assigned to closed

This ticket has been moved to GitHub https://github.com/WordPress/wordcamp.org/issues/572

Note: See TracTickets for help on using tickets.