guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

Which features to add? #259

New Issue
Open
opened 2026-05-25 18:45:12 +00:00 by guettli · 2 comments
guettli commented 2026-05-25 18:45:12 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Look at the current app.

Which features could be added?

Look from an end user perspectives.

Look at the current app. Which features could be added? Look from an end user perspectives.
guettlibot commented 2026-05-25 18:50:51 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Feature Analysis: SharedInbox — End-User Perspective

After exploring the full codebase, here is a structured breakdown of features that would meaningfully improve the end-user experience, ordered roughly by impact vs. effort.

1. Forward Email (High impact, low effort)

What's missing: Reply and Reply-All exist (ComposeScreen accepts a replyToEmailId), but there is no Forward action.

User impact: Forwarding is a core email primitive. Its absence is likely the most glaring gap.

Approach:

  • Add a ForwardAction enum alongside the existing reply modes in lib/core/models/
  • In EmailDetailScreen (lib/ui/screens/email_detail_screen.dart), add a Forward button next to Reply/Reply-All
  • Pre-fill compose with Fwd: <subject>, quoted body, and any attachments carried over
  • No new DB schema needed; reuse ComposeScreen with a forwardEmailId parameter
  • Risk: Forwarding with attachments requires re-fetching the full MIME tree; body must be loaded first

2. BCC Field in Compose (High impact, trivial effort)

What's missing: ComposeScreen has To and Cc fields (tracked in SavedDraft) but no Bcc.

User impact: Privacy-sensitive broadcasts (newsletters, invitations) require BCC.

Approach:

  • Add bccText to SavedDraft model (lib/core/models/saved_draft.dart) and DB Drafts table (lib/data/db/database.dart)
  • Add a toggleable Bcc row in ComposeScreen (same pattern as the existing Cc toggle)
  • Pass Bcc addresses to the SMTP send path in data/repositories/
  • Run task codegen after DB change
  • Low risk overall; straightforward field addition

3. Swipe Gestures on Email List (High impact, moderate effort)

What's missing: No swipe-to-archive / swipe-to-delete / swipe-to-snooze on email rows.

User impact: The dominant interaction pattern in mobile email clients (Gmail, Outlook, Fastmail). Without it, all actions require long-press or opening the email.

Approach:

  • Wrap email list items in Dismissible (Flutter built-in) or use a flutter_slidable package
  • Left swipe → Delete (already implemented); Right swipe → Archive or Snooze
  • Make the action configurable (setting stored per-account or globally)
  • File: lib/ui/screens/email_list_screen.dart, email row widget
  • Risk: Need to handle undo integration (already exists via UndoService)

4. Unified Inbox (High impact, significant effort)

What's missing: The current UX requires navigating per-account (/accounts/:id/mailboxes) with no cross-account view.

User impact: Multi-account users (personal + work email) would greatly benefit from seeing all unread mail in one place.

Approach:

  • Add a /unified-inbox route in lib/ui/router.dart
  • New screen queries EmailRepository across all accounts, filtered to inbox mailboxes, sorted by receivedAt
  • Display account color-coded badge on each row to indicate origin
  • Pagination is already implemented per-mailbox; needs adaptation for merged cursors
  • Risk: Cross-account queries are harder to paginate and sort correctly; unread counts need aggregation

5. Contact Autocomplete in Compose (Medium impact, moderate effort)

What's missing: Typing an address in To/Cc fields shows no suggestions.

User impact: Friction when emailing frequent contacts; every address must be typed manually.

Approach:

  • New Contacts table in the DB: harvest addresses from sent/received emails during sync
  • SearchHistoryRepository already exists — a similar ContactRepository would fit the pattern
  • ComposeScreen To/Cc fields become Autocomplete<EmailAddress> widgets
  • Rank suggestions by frequency of contact
  • Risk: Privacy consideration — some users may not want sent addresses persisted; consider opt-in

6. Batch Select and Act on Emails (Medium impact, moderate effort)

What's missing: No multi-select in EmailListScreen. Every action targets one email at a time.

User impact: Bulk operations (delete 20 newsletters, mark all read) are a common need.

Approach:

  • Long-press on an email enters selection mode (checkbox appears per row)
  • Floating action bar appears at the bottom with Delete / Move / Mark Read / Snooze actions
  • Backend already supports batch operations via PendingChanges table
  • File: lib/ui/screens/email_list_screen.dart — add selection state to the screen's Riverpod notifier
  • Risk: UI complexity; need to handle conflict between selection mode and normal tap/swipe

7. Calendar Invite Handling (Medium impact, significant effort)

What's missing: ICS attachments are detected but not parsed or rendered.

User impact: Accept/Decline/Tentative buttons directly in an email (the same as Gmail/Outlook) reduce context-switching.

Approach:

  • Detect text/calendar MIME part in EmailDetailScreen
  • Parse ICS using ical_parser package (or a minimal manual parser)
  • Render a card with event title, time, organizer, and RSVP buttons
  • RSVP sends an email reply with the updated ICS (method: REPLY)
  • Risk: ICS has many edge cases (recurring events, timezone handling, multiple attendees); scope carefully

8. Vacation Autoresponder UI (Medium impact, low effort)

What's missing: Sieve editing exists (SieveScriptEditScreen), but creating a vacation reply requires writing raw Sieve.

User impact: Out-of-office replies are a common need; a dedicated UI removes the need to know Sieve syntax.

Approach:

  • Add a Vacation Responder sub-screen under account settings
  • UI: subject, body, start/end date, active toggle
  • Generate a standard Sieve vacation action script and POST it via the existing SieveRepository
  • Files: new VacationResponderScreen, additions to lib/ui/router.dart and SieveRepository
  • Risk: vacation extension support varies by server; probe for capability at account setup

9. Rich Text Compose (Lower priority, high effort)

What's missing: ComposeScreen body is a plain TextField; no formatting.

User impact: Many users expect bold, italic, and inline links. Particularly relevant for business use.

Approach:

  • Integrate flutter_quill or super_editor for a rich text compose field
  • Generate text/html MIME part on send alongside a text/plain fallback
  • Risk: Large dependency, significant UI change, complex MIME generation; consider this a later milestone

10. Keyboard Shortcuts (Desktop — Linux/macOS/Windows)

What's missing: No keyboard navigation. Flutter desktop targets are already scaffolded.

User impact: Power users on desktop expect j/k for next/prev email, r for reply, e for archive, etc.

Approach:

  • Wrap main screens in Focus + KeyboardListener or use Shortcuts + Actions widgets
  • Define a KeyboardShortcutsConfig class (configurable bindings)
  • Risk: Mostly additive; low regression risk on mobile since key events don't fire on touch

Open Questions

  1. Forward with attachments — Should forwarding include attachments by default? Re-fetching large attachments on forward adds latency.
  2. Unified inbox pagination — Cross-account merged cursors are non-trivial; need a design for efficient merged pagination.
  3. Contact harvesting opt-in — Should contact autocomplete be opt-in for privacy reasons?
  4. Platform targeting — Some features (keyboard shortcuts) only make sense on desktop; should they be behind Platform.isDesktop guards or always compiled in?
  5. ICS scope — Calendar invite handling is high-value but risky. Should it be limited to a read-only display of event details first, with RSVP as a follow-up?

Suggested Priority Order

Priority Feature Effort Impact
1 Forward email S High
2 BCC in compose XS High
3 Swipe gestures M High
4 Vacation responder UI S Medium
5 Batch select M Medium
6 Unified inbox L High
7 Contact autocomplete M Medium
8 Calendar invite display L Medium
9 Keyboard shortcuts M Medium
10 Rich text compose XL Medium
## Feature Analysis: SharedInbox — End-User Perspective After exploring the full codebase, here is a structured breakdown of features that would meaningfully improve the end-user experience, ordered roughly by impact vs. effort. --- ### 1. Forward Email (High impact, low effort) **What's missing:** Reply and Reply-All exist (`ComposeScreen` accepts a `replyToEmailId`), but there is no Forward action. **User impact:** Forwarding is a core email primitive. Its absence is likely the most glaring gap. **Approach:** - Add a `ForwardAction` enum alongside the existing reply modes in `lib/core/models/` - In `EmailDetailScreen` (`lib/ui/screens/email_detail_screen.dart`), add a Forward button next to Reply/Reply-All - Pre-fill compose with `Fwd: <subject>`, quoted body, and any attachments carried over - No new DB schema needed; reuse `ComposeScreen` with a `forwardEmailId` parameter - Risk: Forwarding with attachments requires re-fetching the full MIME tree; body must be loaded first --- ### 2. BCC Field in Compose (High impact, trivial effort) **What's missing:** `ComposeScreen` has To and Cc fields (tracked in `SavedDraft`) but no Bcc. **User impact:** Privacy-sensitive broadcasts (newsletters, invitations) require BCC. **Approach:** - Add `bccText` to `SavedDraft` model (`lib/core/models/saved_draft.dart`) and DB `Drafts` table (`lib/data/db/database.dart`) - Add a toggleable Bcc row in `ComposeScreen` (same pattern as the existing Cc toggle) - Pass Bcc addresses to the SMTP send path in `data/repositories/` - Run `task codegen` after DB change - Low risk overall; straightforward field addition --- ### 3. Swipe Gestures on Email List (High impact, moderate effort) **What's missing:** No swipe-to-archive / swipe-to-delete / swipe-to-snooze on email rows. **User impact:** The dominant interaction pattern in mobile email clients (Gmail, Outlook, Fastmail). Without it, all actions require long-press or opening the email. **Approach:** - Wrap email list items in `Dismissible` (Flutter built-in) or use a `flutter_slidable` package - Left swipe → Delete (already implemented); Right swipe → Archive or Snooze - Make the action configurable (setting stored per-account or globally) - File: `lib/ui/screens/email_list_screen.dart`, email row widget - Risk: Need to handle undo integration (already exists via `UndoService`) --- ### 4. Unified Inbox (High impact, significant effort) **What's missing:** The current UX requires navigating per-account (`/accounts/:id/mailboxes`) with no cross-account view. **User impact:** Multi-account users (personal + work email) would greatly benefit from seeing all unread mail in one place. **Approach:** - Add a `/unified-inbox` route in `lib/ui/router.dart` - New screen queries `EmailRepository` across all accounts, filtered to inbox mailboxes, sorted by `receivedAt` - Display account color-coded badge on each row to indicate origin - Pagination is already implemented per-mailbox; needs adaptation for merged cursors - Risk: Cross-account queries are harder to paginate and sort correctly; unread counts need aggregation --- ### 5. Contact Autocomplete in Compose (Medium impact, moderate effort) **What's missing:** Typing an address in To/Cc fields shows no suggestions. **User impact:** Friction when emailing frequent contacts; every address must be typed manually. **Approach:** - New `Contacts` table in the DB: harvest addresses from sent/received emails during sync - `SearchHistoryRepository` already exists — a similar `ContactRepository` would fit the pattern - `ComposeScreen` To/Cc fields become `Autocomplete<EmailAddress>` widgets - Rank suggestions by frequency of contact - Risk: Privacy consideration — some users may not want sent addresses persisted; consider opt-in --- ### 6. Batch Select and Act on Emails (Medium impact, moderate effort) **What's missing:** No multi-select in `EmailListScreen`. Every action targets one email at a time. **User impact:** Bulk operations (delete 20 newsletters, mark all read) are a common need. **Approach:** - Long-press on an email enters selection mode (checkbox appears per row) - Floating action bar appears at the bottom with Delete / Move / Mark Read / Snooze actions - Backend already supports batch operations via `PendingChanges` table - File: `lib/ui/screens/email_list_screen.dart` — add selection state to the screen's Riverpod notifier - Risk: UI complexity; need to handle conflict between selection mode and normal tap/swipe --- ### 7. Calendar Invite Handling (Medium impact, significant effort) **What's missing:** ICS attachments are detected but not parsed or rendered. **User impact:** Accept/Decline/Tentative buttons directly in an email (the same as Gmail/Outlook) reduce context-switching. **Approach:** - Detect `text/calendar` MIME part in `EmailDetailScreen` - Parse ICS using `ical_parser` package (or a minimal manual parser) - Render a card with event title, time, organizer, and RSVP buttons - RSVP sends an email reply with the updated ICS (method: REPLY) - Risk: ICS has many edge cases (recurring events, timezone handling, multiple attendees); scope carefully --- ### 8. Vacation Autoresponder UI (Medium impact, low effort) **What's missing:** Sieve editing exists (`SieveScriptEditScreen`), but creating a vacation reply requires writing raw Sieve. **User impact:** Out-of-office replies are a common need; a dedicated UI removes the need to know Sieve syntax. **Approach:** - Add a Vacation Responder sub-screen under account settings - UI: subject, body, start/end date, active toggle - Generate a standard Sieve `vacation` action script and POST it via the existing `SieveRepository` - Files: new `VacationResponderScreen`, additions to `lib/ui/router.dart` and `SieveRepository` - Risk: `vacation` extension support varies by server; probe for capability at account setup --- ### 9. Rich Text Compose (Lower priority, high effort) **What's missing:** `ComposeScreen` body is a plain `TextField`; no formatting. **User impact:** Many users expect bold, italic, and inline links. Particularly relevant for business use. **Approach:** - Integrate `flutter_quill` or `super_editor` for a rich text compose field - Generate `text/html` MIME part on send alongside a `text/plain` fallback - Risk: Large dependency, significant UI change, complex MIME generation; consider this a later milestone --- ### 10. Keyboard Shortcuts (Desktop — Linux/macOS/Windows) **What's missing:** No keyboard navigation. Flutter desktop targets are already scaffolded. **User impact:** Power users on desktop expect `j/k` for next/prev email, `r` for reply, `e` for archive, etc. **Approach:** - Wrap main screens in `Focus` + `KeyboardListener` or use `Shortcuts` + `Actions` widgets - Define a `KeyboardShortcutsConfig` class (configurable bindings) - Risk: Mostly additive; low regression risk on mobile since key events don't fire on touch --- ## Open Questions 1. **Forward with attachments** — Should forwarding include attachments by default? Re-fetching large attachments on forward adds latency. 2. **Unified inbox pagination** — Cross-account merged cursors are non-trivial; need a design for efficient merged pagination. 3. **Contact harvesting opt-in** — Should contact autocomplete be opt-in for privacy reasons? 4. **Platform targeting** — Some features (keyboard shortcuts) only make sense on desktop; should they be behind `Platform.isDesktop` guards or always compiled in? 5. **ICS scope** — Calendar invite handling is high-value but risky. Should it be limited to a read-only display of event details first, with RSVP as a follow-up? --- ## Suggested Priority Order | Priority | Feature | Effort | Impact | |----------|---------|--------|--------| | 1 | Forward email | S | High | | 2 | BCC in compose | XS | High | | 3 | Swipe gestures | M | High | | 4 | Vacation responder UI | S | Medium | | 5 | Batch select | M | Medium | | 6 | Unified inbox | L | High | | 7 | Contact autocomplete | M | Medium | | 8 | Calendar invite display | L | Medium | | 9 | Keyboard shortcuts | M | Medium | | 10 | Rich text compose | XL | Medium |
guettlibot commented 2026-05-25 18:51:02 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Planning complete. To resume this session:

claude --resume 04815155-aa6b-497c-95df-274042aad934
Planning complete. To resume this session: ``` claude --resume 04815155-aa6b-497c-95df-274042aad934 ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels State/Planned
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#259