[wp-meta] [Making WordPress.org] #262: Automate WordCamp Gravatar Badge Creation

[Making WordPress.org]

#262: Automate WordCamp Gravatar Badge Creation
----------------------------------------+-----------------------
 Reporter:  iandunn                     |       Owner:  (none)
     Type:  enhancement                 |      Status:  assigned
 Priority:  high                        |   Milestone:
Component:  WordCamp Site & Plugins     |  Resolution:
 Keywords:  needs-patch good-first-bug  |
----------------------------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:17 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.

 > 2. 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.

 > 3. 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.


 > 4. 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
 [https://make.wordpress.org/design/2019/04/24/widgets-to-blocks-ux-flow-
 proposal/ 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 [https://make.wordpress.org/community/2016/04/26
 /new-tool-for-creating-personalized-wordcamp-badges/ 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 :) )

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/262#comment:18>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org