Scope follow-up capstone: client-tested launch UX and access model

[yagaC64]

Outcome

Produce a decision-ready capstone scope for validating the product with target clients and defining a defensible public, member, or subscriber access model.

Status

[DECISION BLOCKED: PRODUCT OWNER, CLIENT VALIDATION, AND LICENSE/COMMERCIALIZATION MODEL]

This issue separates product discovery from engineering. Do not build a paywall, membership system, or production entitlement service before the target users, value proposition, and legal model are accepted.

Discovery scope

• Name the target client segments and their highest-value decisions or jobs.
• Define interview and usability-test participants, consent, scripts, and evidence capture.
• Map the critical user journeys and failure states.
• Test wireframes or a non-production prototype with representative users.
• Define which information remains public and which capabilities, if any, require controlled access.
• Identify deployment, support, privacy, data ownership, and accessibility expectations.
• Reconcile the current open-source license with any proposed paid, member-only, hosted, or proprietary components.
• Define measurable validation thresholds and a no-go condition.

Required deliverables

• Target-client and problem statement
• Interview and usability plan
• Tested user journeys and findings
• UX/UI recommendations tied to evidence
• Public-versus-controlled-access boundary
• Authentication/entitlement architecture options, if justified
• License and commercialization decision record
• Semester plan with measurable acceptance criteria

Exit criteria

• Product owner and acceptance authority named
• Representative client participants available
• Research and privacy method accepted
• Tested workflow findings documented
• Access model and license boundary decided
• Semester-sized implementation slice accepted

Relationships

Child of #29. Sibling alternative to the field connectivity and API-driven data-operations lane; neither sibling depends on the other.

[yagaC64]

Progress update: the repository, issue relationships, current main, public dashboard, implementation, tests, and license have been rechecked. This lane is suitable for a follow-up capstone only as a product-discovery-led, tested launch experience—not as a paywall or production-service project.

Verified baseline

• The README records the Spring 2026 handoff as notebook-first analytics, a public GitHub Pages dashboard, and a local DuckDB + Streamlit workbench. It also keeps native apps and 24/7 production operations out of scope.
• The live public page redirects to the same static Plotly artifact currently tracked on main. It shows six NOAA CO-OPS stations and a displayed data run time of 2026-02-16 02:59:06 UTC—over five months old at this check; it is not a live operational service or a municipio decision-support workflow.
• A current visual check found that the desktop chart loads, but at a 390 px mobile viewport the page clips headings, compresses the time-series plot into an unusably narrow region, and overlaps labels. The page snapshot also exposed no semantic headings or accessible form controls for the visible chart filter. The existing “mobile-friendly” and accessibility goals therefore remain unverified acceptance work, not current product facts.
• app/streamlit_app.py is explicitly local/internal. It opens DuckDB read-only and supports phase/band/municipio filtering, summary metrics, tables, charts, a map preview, station/alert snapshots, and source/factor review. It is not deployed and contains no authentication or entitlement layer.
• The current main test suite passed locally (4 passed) at commit 3024d2c. Those tests cover the DuckDB baseline, local Streamlit startup, and social-adjustment logic; they do not establish client usability, accessibility, production readiness, or emergency-use fitness.
• The five-tab V2 dashboard described in closed PR #14 was not merged. Its focused extraction paths, PR #24 and PR #25, were also closed unmerged at course closeout. Their functionality must not be presented as the current implementation.
• The theme review in PR #20 and split/municipio notes in PR #21 are useful internal review evidence, but they do not record representative-user recruitment, consent, task measures, accessibility testing, or client acceptance.
• The repository is licensed under Apache License 2.0, and the planning documents state that semester deliverables are expected to remain Apache-2.0 compatible. Apache 2.0 permits commercial use and fee-based support, subject to its terms; it does not create a membership model, data rights, trademark rights, exclusivity, or an operating/support obligation. This is a scope boundary, not legal advice.

Recommended semester-sized slice

Outcome: validate and, only if the evidence gate passes, implement one responsive, accessible, read-only launch journey for a clearly named user segment. Preserve the local workbench as the analyst/QA surface. Do not turn this semester into an identity, billing, or production-operations program.

Primary target-user hypothesis: Puerto Rico municipal emergency-management planners/operators who need to assess conditions and prioritize attention before or during a flood event. Secondary hypothesis: community or partner coordinators who need a simpler public situation-awareness view. These are hypotheses for owner approval and recruitment, not validated personas.

Core jobs to validate:

1. Launch the correct surface on phone or laptop and immediately understand its purpose, data period, freshness, coverage, and limitations.
2. Find a municipio or station and identify what currently requires attention.
3. Understand why it is prioritized, inspect supporting sources/confidence, and distinguish observed data from modeled indicators.
4. Identify an appropriate next step without treating the prototype as an official warning or source of record.
5. Recover safely when data is stale, missing, unavailable, or offline.

Method:

• After product-owner approval and a GMU/IRB or other applicable human-subjects determination, recruit 6–8 representative participants, including at least five primary-segment users and participation from at least three municipios or organizations. Classmates, project authors, and instructors may provide expert review but do not substitute for representative users.
• Run 30–45 minute semi-structured interviews first, then 30–45 minute scenario-based usability sessions using the current public page and a wireframe or non-production prototype.
• Use an approved script and consent notice. Record only with separate opt-in consent; otherwise use structured notes. Assign participant IDs, store raw notes/recordings privately, publish aggregate findings only, and set a deletion date consistent with GMU policy (proposed default: 90 days after final acceptance).
• Test the launch, find/interpret, evidence, action, and degraded-data journeys on desktop and phone. Include at least one stale-data and one missing-data scenario.

Evidence thresholds:

• Each critical task is attempted by at least five primary-segment users.
• At least 4 of the first 5 primary-segment attempters complete each critical task without moderator rescue; for larger task samples, the threshold remains at least 80%.
• Zero unresolved critical errors: wrong municipio/station, stale data interpreted as current, modeled risk interpreted as an official warning, or inability to recover from missing data.
• Median Single Ease Question (SEQ, 1–7 where 7 is easiest) score is at least 5/7 for each critical task.
• The controlled-access hypothesis advances only if participants from at least two of the three participating organizations independently identify the same concrete non-public capability or data need and an accountable owner accepts the resulting privacy, support, and security obligations.
• Accessibility target is WCAG 2.2 AA for the critical journeys, verified with semantic/keyboard/focus checks, non-color cues, chart text/table alternatives, contrast checks, screen-reader checks, touch-target review, 320–390 px reflow, and 200%/400% zoom. Acceptance requires zero open task-blocking accessibility defects after keyboard and screen-reader re-test. Screenshots or automated scans alone are insufficient.

Conditional implementation slice after validation:

• Public read-only launch and municipio/station detail journey.
• Visible data period, last-updated/freshness state, coverage, provenance, confidence, and limitations.
• One evidence-backed prioritization/explanation pattern plus a safe degraded-data state.
• Responsive and accessible behavior for the tested journeys.
• Versioned snapshot deployment with a documented update cadence; no claim of real-time or 24/7 operations.
• Existing local workbench retained for QA/analysis; no public SQL explorer, raw uploads, configurable operational weights, chatbot, or unpublished partner data in this slice.

Public versus controlled boundary

Public by default: public-source data and aggregated outputs, methodology, source/provenance, timestamps and freshness, coverage/limitations, read-only maps/charts/tables, and accessible explanations.

Controlled only if evidence justifies it: partner-approved non-public data, operational annotations, private scenarios, raw exports/uploads, administrative controls, or organization-specific configuration. The present public evidence does not yet justify authentication.

If a controlled pilot becomes justified, prefer an organization-managed identity provider or allowlisted SSO with the minimum roles needed (for example, viewer and operator). Do not build local password storage. Subscription billing and entitlement services remain a later product/operations program, not this capstone slice.

Deployment, support, privacy, and commercialization decisions

• Name the deployment owner, update cadence, support hours, incident/contact path, backup/rollback expectation, cost owner, and end-of-semester handoff. A prototype must not imply emergency monitoring or guaranteed availability.
• Keep public data and partner-approved data separate. Define retention/deletion, access removal, logging, export, and breach/incident handling before any controlled pilot.
• The commercialization decision record must state what a customer would pay for: hosted availability, support, training, organization-specific data/configuration, membership services, or something else. “Access to the existing public code” is not a defensible exclusive value proposition.
• The record must also identify code, data, content, and trademark owners; confirm each data source’s reuse terms; state what remains Apache-2.0 licensed; and obtain the required GMU/rights-holder/legal review before any subscriber, proprietary, or dual-license claim. Existing Apache-licensed releases remain available under that license.

Owner decisions required

1. Is Scope follow-up capstone: client-tested launch UX and access model #31 the selected direction under Decide the 2026-27 follow-up capstone direction #29, and for which semester?
2. Who is the product owner, who has academic/client acceptance authority, and who owns research/privacy approval?
3. Which primary user segment and three or more organizations/municipios can commit representative participants?
4. Is the intended use informational awareness, planning, or active response, and what remains the official source of record?
5. Which concrete capability or data must be controlled, why, and who will operate and support it?
6. Is the model public/open, grant-supported, paid hosting/support, membership, or subscription—and what exactly is being sold?
7. Who has authority over code/data/content/trademarks and will approve the Apache/commercial boundary?

Recommended no-go conditions

• No feature PR, authentication, paywall, billing, or production entitlement work while the owner, representative users, method, access boundary, and license/commercialization decision remain unresolved.
• No implementation acceptance based only on classmates, project authors, screenshots, or presentation feedback.
• No launch if a critical task misses the threshold or a safety-relevant misinterpretation remains.
• No controlled data without documented authority, privacy handling, access removal, and support ownership.
• No “real-time,” official-warning, production-ready, or 24/7 claim without evidence and funded operational ownership.
• No combined Scope follow-up capstone: field connectivity and API-driven data operations #30 + Scope follow-up capstone: client-tested launch UX and access model #31 semester scope unless each lane has separate owners, deliverables, validation, and explicit capacity evidence.

Issue/PR Relationship Tree

• #29 — follow-up capstone direction [OPEN; DECISION BLOCKED BY OWNER, SEMESTER, AND DIRECTION]
  • #30 — field connectivity and API-driven data operations [SIBLING OPTION; DECISION BLOCKED BY INSTALLATION, DATA, AND COMMUNICATIONS CONTRACT]
  • #31 — client-tested launch UX and access model [SCOPED HERE; DECISION BLOCKED BY PRODUCT OWNER, CLIENT VALIDATION, AND LICENSE MODEL]

The children remain alternatives; neither depends on the other.

Exact remaining gate

To satisfy the existing #31 exit criteria, engineering should begin only when a named product owner and acceptance authority approve and link in #31 a single Scope Decision Record that: names the primary user and committed representative participants; records the applicable GMU/IRB or other human-subjects determination; approves the research/privacy method; records workflow results meeting the thresholds above; chooses the public-versus-controlled boundary; resolves the Apache-2.0/commercialization and operating-owner decisions; and accepts one semester-sized implementation slice. Until that record exists, the issue's current [DECISION BLOCKED] status remains accurate and discovery should use only existing surfaces, wireframes, or non-production prototypes.