Prototype 6 — Create a New Event, the staff “front door” that stands up a new meeting (clone or blank) and hands off into the event workspace.
- Added
new-event.html(staff admin chrome) — a single full-page form: Basics (name, type, year, dates, venue, time zone, lifecycle), Start from (equal clone-or-blank radio-cards), and Customize (self-service managed lookups + custom fields) - Clone a prior event reveals a source picker and a live “what carries over” checklist (sessions, roles, lookups, fields, forms with toggleable counts) — FR-EV-2; blank hides the preview and empties the customize step
- Customize step pre-seeds from the clone source and demonstrates the self-service config that needs an IT request today (FR-CF-1/2)
- Validation blocks missing name/dates with a toast and focus; guards end-before-start, case-insensitive duplicate names, and private-mode storage failure
- Wired the dashboard’s “+ New Event” and “⧉ Clone Prior Event” buttons to the new flow (replacing the stub toast)
- Create stashes the new event to a one-shot
sessionStorageflag and lands onevent.html, which shows a success banner and reflects the new event’s header (e.g. a 2029 Congress cloned from 2028), then clears the flag so later normal visits show the unchanged 2028 workspace - Added Section 22 to
mds-events.css; extendeddata.jsadditively (MDS_CLONE_SOURCES,MDS_TIMEZONES,MDS_getCloneSource)
Prototype 5 — Member Directory + cross-year Speaker History, the synced member pool the rest of the system draws people from.
- Added
members.html(staff admin chrome) — a searchable, filterable directory list of the bulk-synced member pool (22 people, including committee-only members who aren’t 2028 faculty), with filters for country, committee, has-spoken, booked-2028, and over-booking risk (FR-FR-1, §6.1) - Member profile — read-only iMIS identity snapshot, committee/role memberships, and the cross-year Speaker History centerpiece: years-spoken, frequency, over-booking-risk flag, past topics, and current 2028 involvement (FR-HX, pain point #4)
- Makes the bulk-sync-vs-SSO point explicit: staff can assign someone who has never logged in — the directory is the synced pool, not just event faculty
- 0 mismatches against the v0.5 Speaker History report across all 22 members (both read the same
MDS_SPEAKER_HISTORY), with an identical over-booking threshold
- Replaced the “Member Directory” sidebar stub with a real link on all staff pages
- Added Section 21 to
mds-events.css; extendeddata.jsadditively (member directory, committees, helpers) — no breaking changes to Prototypes 1–4
Prototype 4 — Reporting + self-service Report Builder, the replacement for being locked into IT-built SSRS reports.
- Added
reports.html(staff admin chrome) — three views: a library of 8 pre-canned reports MDS runs every Congress, a self-service builder (data source → columns → typed filters → sort) with a live preview, and a results view (FR-RP-1…4) - Pre-canned and custom reports share one declarative engine (
MDS_runReportover report subjects), so any standard report is editable in the builder and outputs stay consistent - Cross-year Speaker History / Frequency report (years-spoken, frequency, over-booking risk) — the scattered-Excel tracker, now one click (pain point #4)
- Save / edit custom reports; simulated Excel / CSV / PDF export; no IT request, no SSRS ticket (pain point #6)
- Added a Reports item to the staff sidebar across all staff pages
- Added Section 20 to
mds-events.css; extendeddata.jsadditively (report subjects, standard reports, filter operators,MDS_SPEAKER_HISTORY) — no breaking changes to Prototypes 1–3
Prototype 3 — the Visual Schedule Builder, the staff-facing replacement for MDS’s manual Excel scheduling and collision-checking.
- Added
schedule-builder.html(staff admin chrome) — a days × time × rooms grid with parallel room columns and a distinct committee lane - Drag-and-drop placement from an “unscheduled sessions” tray onto the grid, with a reliable click/keyboard “arm-then-place” fallback
- Live conflict detection surfaced three ways: a marker on each clashing block, a live count in the toolbar, and a conflicts panel that names each clash and jumps to the offending block
- Opens with one pre-existing conflict already on the board (Dr. Lindqvist: PL-01 × Education Committee, 10:15–10:30) — the same clash modeled in the Faculty Hub — so the demo starts with something to solve; moving the session clears it live
- Session/committee detail drawer and highlight-by-person filter to see a faculty member’s full day at a glance
- Reuses the exact conflict rules from the faculty schedule so staff and faculty views always agree (overlap = clash; same-session chair + speaker is not a clash; declined/withdrawn/backup hold no slot)
- Extended
data.jsadditively (grid axes, derivedMDS_SCHEDULEplacements, committee rosters, cross-facultyMDS_detectConflicts()) — no breaking changes to Prototypes 1 & 2 - Added Section 19 (schedule-builder components) to
mds-events.css - Wired the
event.htmlSchedule tab to launch the builder - Fixed a rendering bug where sessions starting off the 30-minute grid boundary were not drawn (detection was always correct; only the visual block was missing)
Prototype 2 — the Faculty / Attendee Hub, the speaker-facing experience.
- Four member-facing pages using the lighter MyMDS-style chrome (utility bar → white brand header → member sub-nav → footer), deliberately not the dark admin sidebar
invite.html— invitation landing with Accept / Decline as the first decisionhub.html— the centerpiece: sessions & roles, an action-item checklist (open vs. complete), registration code / housing / stipend snapshot, a staff-editable alert block, and Orchestrate / certificate link-outsforms.html— role-based forms (disclosures, type-to-sign agreement, housing, travel, bio/headshot) demonstrating the chair-gets-no-housing ruleschedule.html— agenda-ordered personal schedule combining sessions and committee meetings, with conflict detection
- Logged in as Dr. Marcus Lindqvist — the same multi-role person (Chair + Speaker) from the staff workspace, so both prototypes describe one Congress and one set of people
- His request-to-withdraw in the hub is the exact origin of the action-queue item the staff confirm in Prototype 1 — demonstrating the full round-trip: speaker requests withdrawal → routes to staff → staff confirm → backup auto-promotes
- Deliberately reverses the legacy system’s #1 pain point: faculty can edit/update after accepting (with staff notified)
- Added Section 18 (member-facing chrome & hub/forms/schedule components) to
mds-events.css - Added
hub-state.js(cross-page demo continuity viasessionStorage); extendeddata.jswith hub data, no breaking changes
Shared component library and Prototype 1 — the staff Event / Session Management Workspace.
- Built the shared MDS component library
assets/css/mds-events.cssfrom the MDS Brand & Design System Reference — the single styling source of truth for all prototypes - Tokenized brand (Lato; red
#AF2626/ hover#7D0D0D; blue#136294; warm-gray neutrals), an events-domain status palette, plus app shell, buttons, forms, tables, cards, stat tiles, status pills, tabs, modals/drawers, toasts, and utilities
- Five linked pages in the dark admin app-shell:
index.html(events dashboard),event.html(overview + staff action queue + tabs),sessions.html,session.html(presentations, chairs, backups), andfaculty.html(status dashboard) - Faculty status dashboard with status/role filters and search — the replacement for SSRS report cross-checking
- Confirm-decline → auto-invite next backup, preserving the presentation title; reassign speaker keeps the presentation and swaps only the person
- All six status states represented (invited, accepted, declined, withdraw-requested, Speaker TBA, backup); multi-role people surfaced; stipend and housing shown on assignments
- Shared
data.js(mock data) andapp.js(toast/modal/nav utilities); no native browser dialogs anywhere
Specification and development plan — the foundation derived from the RFP, the MDS demo, and the internal debriefs.
- Authored
SPEC.md— full functional/non-functional specification synthesized from six source documents (RFP, clarifying questions, database outline, demo transcript, two internal debriefs) - ~70 numbered requirements across 19 modules, personas & role model, relational data model, integration architecture (iMIS today, Nimble-ready), workflows, phasing, and a resolved open-questions register
- Key scope decisions locked: phased delivery; iMIS→Nimble (no Salesforce); moderate in-app comms (mass email stays in ActiveCampaign); global-core + per-event-custom roles; preloaded backups with auto-invite; committee module separate-but-linked; self-service config & report builder in Phase 1; request-to-withdraw routing; visual schedule builder
- Authored
DEV_PLAN.md— a 35-step incremental Phase 1 plan across 10 stages and 6 milestones, each step mapped to spec requirements with a clear “done when” state - Prototype sequencing defined; bulk member-sync flagged as the critical-path dependency to confirm early