[{"data":1,"prerenderedAt":187},["ShallowReactive",2],{"case-study-pears-events":3},{"id":4,"title":5,"accent":6,"body":7,"description":149,"extension":160,"liveUrl":161,"meta":162,"metrics":163,"navigation":173,"order":150,"path":174,"role":175,"seo":176,"stem":177,"summary":178,"tech":179,"year":185,"__hash__":186},"caseStudies\u002Fcase-studies\u002Fpears-events.md","PEARS Event Registration","blue",{"type":8,"value":9,"toc":148},"minimark",[10,15,19,22,26,29,35,39,42,45,68,76,79,83,86,106,111,115,118,127,131,134,138,141,145],[11,12,14],"h2",{"id":13},"the-problem","The problem",[16,17,18],"p",{},"Event registration looks like a solved problem: put some fields on a page, collect a payment, done. It isn't. Underneath a \"simple\" signup sits federally-required demographic data, a photo and video waiver, layered fees, and the messy human cases nobody plans for. When any of that goes wrong, a real organization pays for it: people can't find or finish registering, the org falls out of compliance, dirty data lands on the backend, and payments are left half-finished.",[16,20,21],{},"PEARS is a production platform that university extension programs and public-health organizations use to run their events. My work on it was the part everyone touches and nobody notices when it works: the public registration flow.",[11,23,25],{"id":24},"what-a-registrant-sees","What a registrant sees",[16,27,28],{},"The public flow is native Vue: a registrant lands on a white-label event page, passes through a role screener, fills out the event's form (rendered with Vueform), then checks out. Simple on the surface. The whole job was keeping it that way while the requirements underneath multiplied.",[30,31],"media-figure",{"alt":32,"caption":33,"src":34},"A public PEARS event page","A white-label event page: organizations brand it as their own.","\u002Fimages\u002Fpears\u002Fpublic-page.png",[11,36,38],{"id":37},"the-screener-a-page-not-a-modal","The screener: a page, not a modal",[16,40,41],{},"The original plan was a modal wizard. I argued for a dedicated, full-page screener instead, and I took real pushback for it.",[16,43,44],{},"Three things convinced me the modal was wrong:",[46,47,48,56,62],"ul",{},[49,50,51,55],"li",{},[52,53,54],"strong",{},"Style fights."," Vueform doesn't integrate with Bootstrap as deeply as we needed, so a modal's styles would fight the form's. What looked like a small UI choice was really a technical liability.",[49,57,58,61],{},[52,59,60],{},"Lost context."," Event forms range from a single page to many. Dropping a user from a modal, into a multi-step form, into a checkout page invites the exact question you never want: \"wait, why am I going from a modal, to a form, to a checkout?\"",[49,63,64,67],{},[52,65,66],{},"Anonymous edits."," Registrants without an account still need to come back and edit their data. A modal made that awkward; a page made it natural.",[16,69,70,71,75],{},"I had just finished ",[72,73,74],"em",{},"Don't Make Me Think",", and I wanted the decision settled by users, not opinions. So I pushed for something we didn't usually do: private feedback demos with org admins. The full-page screener held up.",[16,77,78],{},"The real vindication came later. As requirements and edge cases piled on, the screener's complexity grew with them, and a page absorbed that weight where a modal would have buckled.",[11,80,82],{"id":81},"designing-complexity-into-calm","Designing complexity into calm",[16,84,85],{},"The screener exists to answer one question before the form ever loads: who are you, and what do you actually need to fill out? That is where the hard cases live.",[46,87,88,94,100],{},[49,89,90,93],{},[52,91,92],{},"Registering for someone else."," A parent signs their kids up for a summer camp they won't attend themselves. The kids have no email, but the event still needs a way to identify each of them. A proxy can register a whole group, and then each member finishes their own form.",[49,95,96,99],{},[52,97,98],{},"Fees that stack."," A registration fee that depends on your role (sponsor, volunteer, participant), plus session fees and add-on fees that change based on what you select in the form. Three fee types, combining differently for almost every registrant.",[49,101,102,105],{},[52,103,104],{},"Plain language over legalese."," The government demographic categories are unavoidable; confusing wording isn't. Progressive disclosure keeps any one screen from feeling heavy.",[30,107],{"alt":108,"caption":109,"src":110},"The PEARS registration form","A compliance-heavy form kept calm: clear grouping, plain language, one step at a time.","\u002Fimages\u002Fpears\u002Fform.png",[11,112,114],{"id":113},"running-the-event","Running the event",[16,116,117],{},"Registration is only the front door. On the admin side, an organizer builds the whole event under the Plan module: multiple sessions, locations, capacity limits, file uploads, and the fee structure. The registration form itself is composed from templates, so a team collects exactly the contact fields, attendance types, and demographic questions its funders require. Payments run through Stripe, Transact, or Authorize.net, and organizers can view, edit, or export registrants and track attendance and payment status per person or per group.",[16,119,120,121,126],{},"The payoff is why this lives inside PEARS instead of a generic event tool: an event links to Program Activities, so registration and attendance flow back as clean, reportable data, and into the CRM, without anyone re-keying it. The organizer runs an event; the platform turns it into the numbers the organization answers to funders with. For the broader story of building data tools inside PEARS without code, see ",[122,123,125],"a",{"href":124},"\u002Fwork\u002Fmodule-builder","PEARS Module Builder",".",[11,128,130],{"id":129},"what-i-owned","What I owned",[16,132,133],{},"I want to be precise about my role, because \"I built PEARS\" would be a stretch. I designed and built parts of the public flow, and I was central to designing the flow itself; the full-page screener was my call to make and to defend. I also designed and helped build the admin side described above, where organizations manage and export their registrations and author their event details and forms. I expanded the accounting and fee features. I did not build the payment architecture. The interesting work was rarely a single feature; it was making all of these fit together without the seams showing.",[11,135,137],{"id":136},"what-shipped","What shipped",[16,139,140],{},"The flow is live and in daily use. Over 10,000 registrations have moved through it at MU Extension, across 5+ organizations running their own events on the platform. It is production software that real organizations, and the real people signing up for their events, depend on.",[11,142,144],{"id":143},"what-it-proves","What it proves",[16,146,147],{},"Anyone can build a form. The job here was harder and quieter: a compliance-bound, multi-fee, proxy-friendly process that still feels effortless to the person filling it out. That is what production product work is. When the judgment is right it is invisible, and the person just registers for their event and gets on with their day.",{"title":149,"searchDepth":150,"depth":150,"links":151},"",2,[152,153,154,155,156,157,158,159],{"id":13,"depth":150,"text":14},{"id":24,"depth":150,"text":25},{"id":37,"depth":150,"text":38},{"id":81,"depth":150,"text":82},{"id":113,"depth":150,"text":114},{"id":129,"depth":150,"text":130},{"id":136,"depth":150,"text":137},{"id":143,"depth":150,"text":144},"md","https:\u002F\u002Fpears.io\u002Fevents",{},[164,167,170],{"label":165,"value":166},"Registrations","10,000+",{"label":168,"value":169},"Organizations","5+",{"label":171,"value":172},"Fee types","3",true,"\u002Fcase-studies\u002Fpears-events","Senior Software Engineer, Canopy",{"title":5,"description":149},"case-studies\u002Fpears-events","The public event-registration flow for PEARS, a production platform real organizations depend on: a compliance-heavy, multi-fee, proxy-friendly process designed to feel effortless.",[180,181,182,183,184],"Vue","TypeScript","Vueform","Bootstrap","Design systems","2024–26","wmIdP8bI_mMIc_OO4twjhb-hkyuJ5SeWKjx3I_VDduE",1792537541224]