Swipe the calendar sideways to step a day or a month

The calendar had next and previous as toolbar buttons and n/p, and nothing
for a thumb. Every other surface in the app that a finger drives already
answers to a swipe.

Day and month only. Those are the two views where a period is a page;
week and agenda scroll through a range rather than turning to the next
one, so there is nothing a sideways flick would obviously mean. Dragging
left pulls the next period in from the right, the way paper and every
phone do it.

Three things it deliberately does not do.

It draws nothing while the finger moves. The row swipe slides the row open
because the strip underneath has to name which of six actions is about to
happen; stepping a calendar has two outcomes and the direction of the
finger already says which. Translating the grid would also break the
sticky day header, since a transform makes a containing block. The
threshold is reported by the vibration motor instead, which is what the
haptics are for.

It does not start on an event. Which gesture was meant is decidable at the
moment the finger lands and only then, so dragging an event stays
available to be built later without having to be untangled from this
first.

And it asks for a longer drag than a row swipe -- not because the
consequence is bigger, since stepping back undoes it while a swiped row
has already been archived, but because this gesture has no way to change
its mind. A row reveals what it will do and can be let go early, and
offers Undo after. This shows nothing and offers nothing, so the distance
is the only chance to not mean it.

The axis lock is the shared one, keeping its bias towards the vertical:
the day grid scrolls through the hours, and a scroll misread as a swipe
throws the reader into another day. The toolbar buttons and n/p stay,
because a gesture with no visible control is one only the people who
already know about it can use.
This commit is contained in:
2026-09-01 22:13:32 -07:00
parent 34578ba426
commit 7d9a01cb93
4 changed files with 231 additions and 2 deletions
+15
View File
@@ -110,6 +110,21 @@ every drag.
- **Hold a folder** in the drawer for the menu its ⋮ button opens.
- **Pull the message list** down to refresh it.
- **Drag in from the left edge** of a conversation to go back to the list.
- **Swipe the calendar sideways** in day or month view to step to the next
period or back — dragging left pulls the next one in from the right, the way
paper and every phone do it. Week and agenda scroll through a range rather
than turning to the next one, so a sideways flick would not obviously mean
anything there and does nothing. A drag that begins on an event is left
alone, which keeps dragging an event to move it available to be built later
without having to be untangled from this first.
It asks for a longer drag than a row swipe does, and not because the
consequence is bigger — stepping back undoes it, while a swiped row has
already been archived. It is because this gesture has no way to change its
mind: a row slides open as it goes, so the strip underneath names what will
happen and letting go early calls it off, and a toast offers Undo afterwards.
Stepping the calendar shows nothing on the way and offers nothing after, so
the distance is the only chance to not mean it.
The toolbar's refresh button and the thread's back arrow both stay. A gesture
with no visible control is one only the people who already know about it can