Skip to main content

Notes And Timer Follow-Through Audit

Purpose​

Turn a short real-world agency test into a clearer record of:

  • what friction was actually felt
  • what that friction implies across the app
  • what has already been confirmed in conversation
  • what still needs explicit product confirmation before implementation prompts

This document is intentionally not a recommendation memo. It should stay close to the observed friction and the decisions you explicitly confirm.

What This Doc Is​

  • a normalized record of the original trial notes
  • a cross-feature interpretation of those notes
  • a place to capture confirmed product decisions from conversation
  • a place to capture open decisions that still need confirmation

What This Doc Is Not​

  • not a place for assistant design recommendations
  • not a final implementation spec
  • not a route-by-route change list
  • not a place to silently convert open questions into assumed decisions

Original Trial Notes​

These are the source frictions this document must stay anchored to.

Save vs Save and link to timer is confusing.

The friction is:

  • the difference between the two actions is not obvious
  • the current wording makes the user infer too much

2. New record follow-through is inconsistent​

Creating a project from the new-project dialog does not offer a clear Go to project next move in the success toast.

The friction is:

  • the app does not yet have one obvious pattern for what happens after creating a new thing
  • redirect vs stay-put-with-open-action vs another handoff pattern is not settled consistently

3. Suggested timer-note wording is misleading​

Add to timer notes is still confusing.

The friction is:

  • it should read more like Suggested notes
  • it should be obvious that the note is not actually linked yet

4. Linked notes are not visible enough​

The timer flow should show the notes that are already linked.

The friction is:

  • the user cannot easily tell what is already linked versus what is only being suggested

5. Save-and-stop does not refresh into a truthful idle state​

After saving and stopping a timer, connected notes and surrounding timer context do not refresh cleanly.

The friction is:

  • the previous client's context still appears present
  • it is too easy to feel like the old work is still active when trying to switch to something else

6. Continue timer is a possible follow-up idea​

After saving and stopping a timer, reopening that time entry raises the idea of continuing from that entry.

The friction is not yet a confirmed product demand. It is an idea worth deciding deliberately.

7. Notes and timer should default to shell-first utility behavior​

Opening Notes from the topbar and opening a note from there could feel more like opening a tab or shell state than being pushed into a full route immediately.

The friction is:

  • utilities currently feel more route-heavy than they need to

Overall Intent​

This is the broader moral behind the original notes.

The app should reduce context reconstruction during interruption-heavy agency work.

The goal is not just to polish Notes or Timer locally. The goal is to make the app feel like one operating layer where an agency user can:

  • pause one thread
  • jump to another thread
  • keep a few live work targets close
  • return without rebuilding context from scratch

Cross-Feature Meaning​

Although the original notes were specific, the pattern is not local.

The same underlying questions affect:

  • notes
  • timer
  • projects
  • clients
  • time entries
  • topbar utilities
  • create flows
  • any feature that links into another owning record

This means future prompts should treat these as shared system behaviors, not page-specific polish.

App Facts That Support The Original Friction​

These are implementation facts in the current app that line up with the original test notes.

  • project creation currently ends in a success toast without a strong open handoff
  • timer stop currently clears the active timer but leaves prior context feeling too present
  • the topbar already acts as a utility layer with Notes, quick note, active timer, spotlight, and calendar
  • the quick-action dock already exists as a separate quick-action surface
  • the shell already preserves note and timer-related working context in multiple ways

These facts support the idea that the friction is systemic, not imaginary.

Confirmed Decisions From Conversation​

These are the points already confirmed in this conversation.

Shell structure​

  • the floating quick-action dock is its own thing
  • it should stay dedicated to quick actions
  • it should not become the pinned-work layer

Topbar and pinned work in v1​

  • pinned work should stay in the topbar for v1
  • a mixed topbar is acceptable in v1
  • horizontal scrolling in the topbar is acceptable in v1
  • a separate pinned footer bar is not the v1 default
  • the topbar can behave as both a utility layer and a tab-like work area in v1
  • notes opened from the topbar should open in that same topbar layer rather than immediately forcing a full page route

Note action model​

  • the current note action model should be simplified rather than expanded
  • the core distinction should be whether a note is linked or not linked
  • reducing action branching is preferred over preserving multiple similar actions with subtle differences

Timer stop behavior​

  • when a timer is stopped, the timer surface should clear cleanly
  • lingering client, note, or surrounding timer context after stop reduces confidence that the entry was actually saved correctly

Continue timer​

  • keep Continue timer as a later idea, not a current implementation requirement

Create-flow handoff current leaning​

  • current leaning is to stay in place and show a clear Open action in the toast
  • when a toast includes an action, it should likely stay visible longer
  • whether this becomes the universal rule or still varies by record type is not fully settled yet

Document rule​

  • this document should not contain assistant recommendations
  • recommendations can still be discussed outside the document and explicitly confirmed or denied

Open Decisions Still Requiring Confirmation​

These are still unresolved and should be explicitly answered before turning this into implementation prompts.

1. Note action wording after simplification​

Need to decide:

  • the exact wording for the simplified linked vs not-linked model
  • whether timer-note reuse needs a separate explicit action at all once the branching is reduced

2. Create-flow handoff pattern​

Need to decide:

  • whether stay put + clear Open action in toast should become the default pattern
  • whether some record types should still behave differently
  • how much longer a toast with an action should stay visible

3. Suggested vs linked note display​

Need to decide:

  • the exact language for suggested notes
  • how linked notes should be shown
  • the display order of linked notes, suggested notes, and note actions

4. Continue timer​

Status:

  • explicitly deferred for later
  • do not treat this as in-scope for the first implementation prompts

5. Shell-first opening behavior​

Need to decide:

  • whether Timer should follow the same shell-first opening model as Notes
  • what exact interaction model the topbar tab-like state should use beyond Notes

6. Pinned-work scope in v1​

Need to decide:

  • what can be pinned first
  • how many pinned items should be practical in the topbar
  • what overflow behavior should look like once the topbar scrolls
  • how long pins should persist before the user clears them

7. Multi-timer vs one live timer​

Need to decide:

  • whether the app should ever support more than one active timer at once
  • or whether it should support one live timer with multiple parked contexts only

This is still open unless explicitly confirmed.

Prompt Guardrails​

Any future implementation prompt for this area should preserve these constraints.

1. Do not localize a systemic issue​

If a prompt touches one of these patterns, it should inspect sibling surfaces that use the same pattern:

  • topbar utilities
  • timer route and timer popover
  • note linking and suggestion language
  • create-flow handoff behavior
  • pinned-work rendering and persistence
  • client and project surfaces that share note or timer context

2. Keep the shell split intact​

Prompts should preserve:

  • topbar as the v1 home for utilities, live context, and pinned work
  • quick-action dock as a separate action-only surface

3. Do not hide state meaning behind vague labels​

Prompts should not blur:

  • linked
  • suggested
  • saved
  • active
  • preserved draft

4. Treat pinned work as current working state​

Prompts should not implement pinned work as:

  • a permanent favorites system
  • a second sidebar
  • a second quick-action surface

5. Validate against the original friction​

At minimum, prompts should check whether the resulting changes make these original frictions better:

  • unclear note action meaning
  • inconsistent post-create handoff
  • confusing suggested-note language
  • invisible linked notes
  • stale timer context after stop
  • route-heavy utility behavior

6. Respect confirmed decisions​

Prompts should not reopen already confirmed conversation decisions unless explicitly asked.

That includes:

  • v1 pinned work stays in the topbar
  • quick-action dock stays separate
  • timer stop should clear cleanly
  • Continue timer is deferred
  • note opening from the topbar should behave like a topbar tab or shell state first

Prompt Checklist​

Before using this document as the basis for an implementation prompt, the prompt should clearly state:

  • which of the open decisions are already confirmed
  • which shell surfaces are in scope
  • which sibling surfaces must also be checked for consistency
  • what success looks like in terms of the original user friction, not only code changes

Current Working Summary​

At this point, the document is anchored to these truths:

  • the main friction is interruption-heavy agency work forcing too much context rebuilding
  • the problem is cross-feature, not local to Notes or Timer only
  • the first pass should simplify note actions, not add more branching
  • stop should mean stop, and the timer surface should clear accordingly
  • Notes from the topbar should open back into that same topbar working layer first
  • pinned work remains a v1 topbar concern, not a second shell bar yet

Bottom Line​

The idea has not drifted as long as the work stays anchored to this:

  • the app should feel easier to switch around inside during real agency work
  • utilities should feel shell-first when the task is small
  • topbar context should reduce unnecessary navigation
  • state should read truthfully after meaningful actions
  • the same cross-feature pattern should not be fixed in only one place