Two parent tabs, one for Academic and one for Strength and Conditioning, though only Academic is currently used.
Child tabs:
Sessions
Users can create sessions and view sessions. Sessions have a title, week, day, time, teacher, cost, enrollment count and status (active/inactive). On the edit screen, admin can also see the category, max enrollment count, description, and notes.
Sessions can be deleted, deactivated, edited, and duplicated.
There is no sense of identity between camp topic and session. Multiple camps might be identical (Web Design, Intro to Coding, etc.), but there is no way to view all the sessions belonging to a single topic, or force all sessions of one topic to have the same detail ^nv31s.
When creating a session, teacher and assistant teacher are text fields, without a tie to the data model (existing users, teachers, etc. ^m26q).
Calendar
One of the All Calendars.
Using day/month/week views, users can see all camps sessions and filter by primary teachers. The user can also overlay training blocks (see a color-coded block showing when students are doing Tennis or S&C for their group (Next Gen, Elite, Farm Rising, etc.)).
Training blocks only have a time slot when viewing the day or week, not the month.
Groups
Allows an admin to edit the date and time of schedule blocks for the various training groups. This exists because the camps calendar does not integrate with the other calendar ^4zris.
Registrations
This list shows what students attending camps. The list shows the parent, how many sessions the student is attending, how much revenue they have generated, when their registration was submitted, registration confirmation status, and an edit code/edit link. This is a GUID and URL that allows a parent to edit a registration (this is done since parents cannot sign in to the application to register). The edit page for a registration lets the user view what sessions the child is signed up for.
The camp attendee is a plaintext field not tied to the data model (no connection to either the CRM leads or the students currently enrolled in the school ^xvcf).
Waitlist
Shows pending registrations for camps that are fully booked. An admin can either release a spot to add the student, or expire to remove them from the waitlist.
Analytics
Shows aggregate and individualized stats for camp registrations.
Stats:
Total sessions, Overall fill rate, total revenue collected, total number of unique families (unclear if this means unique students; if two siblings have separate registrations would they be counted as two “unique families”?)
Monthly stats: total sessions, total enrolled students, total revenue
Teacher stats: total sessions, enrollment counts, fill rate
Category stats: sessions, enrollment, fill rate
By week: session, load (light, typical, heavy) capacity, enrolled, fill rate, revenue
Issues
The more I see analytics across the application, the more I think analytics should be stripped from version 1, and if the business use case justifies it, the next version should include true business intelligence/data analysis.
Why do camps get their own page? How is booking a camp different than booking an individual lesson (like how families can book a session with a tennis coach)? Can that experience be unified with a scheduler?