Content
View differences
Updated by Marc Alcobé 13 days ago
* The mobile app provides a dedicated “Meetings” module entry point that is discoverable from global navigation (and/or within a project context where applicable).
* A user can see a list of meetings they are allowed to access, with at least: title, date/time (or “no date”), project, location (if present), and meeting status/state (if applicable).
* The meeting list supports filtering (at minimum by project and time range: upcoming/past) and sorting (at minimum by date/time).
* The meeting list supports pagination or infinite scrolling and remains responsive for large datasets.
* A user can open a meeting and view meeting details equivalent to the web app baseline, including at minimum:
* Title
* Project association (when meetings are project-scoped)
* Date/time and time zone display
* Location / conferencing link (if present)
* Agenda items (including ordering)
* Notes/protocol content (including rich text where supported)
* Participants/attendees (where supported by the web app)
* Related work packages (if supported on web)
* Attachments (if supported on web)
* A user can create a new meeting from mobile (subject to permissions) and save it successfully.
* A user can edit an existing meeting from mobile (subject to permissions) and save changes successfully.
* A user can delete a meeting from mobile only if they have the same permission level required on web; otherwise the action is hidden or disabled with an explanation.
* The UI clearly indicates read-only mode when the user lacks edit permissions; editing controls are hidden/disabled accordingly.
* Offline/poor connectivity scenarios are handled gracefully:
* If the device is offline, the user is informed and prevented from saving changes.
* If saving fails due to network errors, the user sees a clear error state and can retry without losing their entered data.
* Conflict handling is defined and implemented:
* If a meeting was updated since the user loaded it, the user is prompted with a safe resolution path (at minimum: reload and re-apply changes, or discard).
* Cross-platform parity is targeted:
* Core meeting flows (list → view → create/edit) work on iOS and Android with consistent behavior.
* Cross-platform behavior is considered:
* Where meeting content is also accessible via API (and possibly integrations), the mobile updates are reflected immediately in the web app and vice versa.
* Accessibility requirements are met:
* Primary actions are reachable by screen readers, labels are present, and touch targets meet minimum size guidelines.
* A user can see a list of meetings they are allowed to access, with at least: title, date/time (or “no date”), project, location (if present), and meeting status/state (if applicable).
* The meeting list supports filtering (at minimum by project and time range: upcoming/past) and sorting (at minimum by date/time).
* The meeting list supports pagination or infinite scrolling and remains responsive for large datasets.
* A user can open a meeting and view meeting details equivalent to the web app baseline, including at minimum:
* Title
* Project association (when meetings are project-scoped)
* Date/time and time zone display
* Location / conferencing link (if present)
* Agenda items (including ordering)
* Notes/protocol content (including rich text where supported)
* Participants/attendees (where supported by the web app)
* Related work packages (if supported on web)
* Attachments (if supported on web)
* A user can create a new meeting from mobile (subject to permissions) and save it successfully.
* A user can edit an existing meeting from mobile (subject to permissions) and save changes successfully.
* A user can delete a meeting from mobile only if they have the same permission level required on web; otherwise the action is hidden or disabled with an explanation.
* The UI clearly indicates read-only mode when the user lacks edit permissions; editing controls are hidden/disabled accordingly.
* Offline/poor connectivity scenarios are handled gracefully:
* If the device is offline, the user is informed and prevented from saving changes.
* If saving fails due to network errors, the user sees a clear error state and can retry without losing their entered data.
* Conflict handling is defined and implemented:
* If a meeting was updated since the user loaded it, the user is prompted with a safe resolution path (at minimum: reload and re-apply changes, or discard).
* Cross-platform parity is targeted:
* Core meeting flows (list → view → create/edit) work on iOS and Android with consistent behavior.
* Cross-platform behavior is considered:
* Where meeting content is also accessible via API (and possibly integrations), the mobile updates are reflected immediately in the web app and vice versa.
* Accessibility requirements are met:
* Primary actions are reachable by screen readers, labels are present, and touch targets meet minimum size guidelines.