There is a particular kind of note that never has anywhere sensible to go. Not a task, not a comment on a ticket, not something a client should ever read — the half-thought you need on paper before it is worth saying out loud. Most of us keep those somewhere else entirely: a second app, a physical pad, a text file with a name we will not recognise in three weeks.
Every TimerOS workspace now has a notebook for them instead. Some of that thinking happens on an e-ink tablet rather than a backlit screen — and on one of those, until this month, the app’s text read perfectly well and every line around it disappeared.
A canvas, not a page
A notebook in TimerOS is not a document. It is a canvas — the same drawing surface as the board your client draws on, pointed at something private instead of at a project. You draw on it, type on it, stick notes to it, drop pictures onto it, and drag things around because thinking is spatial and a list is not. There are nine tools on the bar — select, freehand, rectangle, ellipse, line, arrow, text, sticky note, eraser — plus pictures, which you paste, drop or pick rather than draw.
It is infinite by default. If you would rather it behaved like paper, turn on page outlines and it draws A4 guides underneath everything — 794×1123 canvas units at 96dpi, so what you see is what would print. The outlines are chrome, not containers: nothing belongs to a page, nothing is stored per page, and turning them off hides the lines without moving a single stroke.
A list makes you decide what a thought is before you have finished having it.
You get a hundred of them. They live in the sidebar under Tasks, in the desktop app and in the web app at app.timeros.ai — which is also the answer to how any of this reaches a tablet: an e-ink Android tablet has a perfectly ordinary browser, and the web app is a web app. The files that draw a notebook are byte-identical between desktop and web, so this is not a port that will drift; it is one codebase rendered twice.
Why a warm-paper palette collapses on e-paper
Now the display half, which started as a complaint — and which lives in the web app and the Android app only. The Windows desktop app never meets an e-paper panel, so it never got the mode. TimerOS’s light theme is warm paper: a cream ground at #F1EEE5, dark ink at #2A2620, and borders at #BCB294. On a phone or a laptop it reads well. On an e-ink tablet it looked, in the words of the person who first put it on one, washed out.
The obvious guess is that the text was too light. The text was fine. What vanished was every line — which, on a notebook page, is most of what is on it. The dot grid went, then the A4 page outlines, then the toolbar’s edge; the same thing was happening to card edges, table rules and input outlines everywhere else in the app.
A backlit screen has the dynamic range to carry a 1.8:1 edge anyway. A reflective panel does not: its whole budget is the light already in the room, and the mid-tones that were doing the structural work on a phone land within a hair of each other. The palette was not too pale. It was carrying structure in a register that e-paper cannot print.
What e-ink mode changes, and what it leaves alone
So the mode is not a filter and not a greyscale switch. It is a second palette: a white ground rather than cream — on a reflective panel, cream is light you have thrown away — black text, and borders taken from #BCB294 to #2B2B2B, and to pure black once the device reports 2.2dppx or less. That puts a card edge at 14.2:1 against the page, up from 1.8:1. Semantic colours are replaced token by token with a darker member of the same hue rather than flattened to grey: the amber that marks a warning was #C9A765, which is about 70% grey once the colour is gone and therefore invisible on paper, and becomes #6B5410. Darkened rather than desaturated, the semantic colours stay distinguishable from one another: different hues on a colour e-ink panel, and different densities on a monochrome one.
Two smaller decisions did more work than the palette. CSS motion is clamped to a millisecond — not slowed, stopped — because every intermediate frame of a tween is a panel refresh, so animation on e-paper arrives as flicker and leaves ghosting behind. And when the device reports a low pixel density, font smoothing is switched off entirely, which is the exact opposite of what the app does everywhere else. Greyscale antialiasing is what turns a one-pixel stem grey; turning it off leaves the stem solid black. It is one declaration, and it moves no layout.
That second rule keys on the density the device reports — @media (max-resolution: 2.2dppx) — rather than on the panel’s physical resolution, and the difference matters because these tablets let you change the first one. A Boox exposes a per-app DPI control; lowering it lowers the density Android reports, which the browser turns straight into devicePixelRatio. The page gets a wider viewport, the interface renders smaller, and hairlines end up about one physical pixel each. Because the rule is a plain media query rather than anything measured in JavaScript, it re-evaluates on its own the moment that setting changes.
What the mode does not touch is the more interesting half.
The canvas picks its default ink from the brightness of the paper it is on. White paper picks the same dark pen that cream paper already did, so a light-theme user switching into e-ink mode is holding the same pen afterwards. What changes is the paper under it, which takes that default stroke from 15.4:1 on cream to 17.9:1 on white. A small change, and the pen was never the problem either.
Why it does not detect your screen for you
It is one checkbox in Settings → Appearance, off by default, remembered per device. We tried to remove it and could not. An e-ink Android tablet runs an ordinary browser engine on an ordinary RGB framebuffer and reports itself as a perfectly normal fast colour screen; the media queries that sound right — (update: slow), (monochrome) — are the ones it answers no to. Sniffing the user agent for vendor names would misfire in both directions, and guessing wrong repaints somebody’s phone in stark monochrome, which is a far worse failure than one tick box.
It is also stored beside your theme rather than in it, because it is not a taste. Light and dark belong to the person; this belongs to the hardware in front of them. It overrides both, for the same reason: dark mode on a reflective panel gives you a grey field rather than a black one, and a full-screen dark forces heavier refreshes. On e-paper, paper wins.
Notes that point at the work
A notebook that only holds drawings is a drawing app. This one can be attached to the projects and tasks it is about — up to fifty of them — and found from either end.
The link only ever runs one way. Your notebook points at the task; the task is never told, stores nothing, and cannot answer the question “who has notes on this?”. The panel on the task side shows you your own notebooks and nobody else’s, and renders nothing at all if you have none. You can only link to something you can already see, and the label is a snapshot taken once and never re-resolved — so losing access to a project later cannot quietly read its current name back to you through your own notes.
Search runs across the notebooks you can open, yours and shared alike — the three hundred most recently updated, if you have somehow accumulated more than that, where renaming, linking or sharing moves a notebook up that list and drawing in it does not — and looks inside the canvases: it matches the text in text boxes and sticky notes, and hands back the notebook, the element, and where on the canvas it sits, so a hit scrolls you to the spot rather than to the page. It does not read handwriting. Nothing here converts ink to text, and a drawn word is a drawing.
None of this tells anyone what you were working on. The notebook is a place to write things down, not a signal; it is not read by the matcher that decides which task your tracked time was booked to.
Yours, until you hand somebody a pen
A notebook has no permission setting and no plan behind it. There is no notebooks entry in the permission registry and none in the plan registry either — ownership is the whole access rule, and it resolves from your session rather than from a role somebody could edit. There is no administrative decision to be made about whether an employee may keep their own notes.
When you do want somebody in, you share the notebook with a colleague as one of two things: they can look, or they can draw. A shared notebook is live — you see their cursor with their name under it and their strokes as they make them, on the same engine the project board runs on. It stays yours throughout: a collaborator with the pen cannot rename it, re-share it, change its pages or delete it.
That last row is structural rather than a setting. A notebook can only be shared with people who exist in your workspace’s own employee list, which no client account can appear in; there is no notebook route in the portal at all, and a portal session asking for one is refused before any comparison runs. This is the deliberate difference from the project whiteboard, which exists precisely so a client can draw on it. Both are canvases; only one of them has an outside.
Deleting is two acts, not one. A deleted notebook goes to a trash you can restore it from for thirty days, and only something already in the trash can be destroyed for good. Pictures are filed privately, never on a public address, and served only through a route that re-checks who you are on every single request — so a picture is exactly as private as the page it sits on, which is the same rule the rest of our private-by-default plumbing follows.
The limits, plainly
- No handwriting recognition. None. Search finds typed text and sticky notes; a word you drew with the pen is a drawing and will stay one until we build something that is not in this release.
- No pressure, tilt or palm rejection. The canvas takes a stylus, a finger and a mouse down one identical path, at whatever line weight the toolbar is set to. Two-finger pinch and pan work, and the browser’s own gestures are suppressed inside the board. But it does not feel like a drawing tablet, and it will not.
- E-ink mode is web and Android only. Said above and worth repeating: not the Windows app, not the client portal. A deliberate scope call rather than an oversight.
- Drawing needs a connection. There is no offline queue. A dropped socket is survivable — the board says so, and on reconnect it refetches itself whole, so nothing saved is lost — but a stroke drawn with no connection at all is dropped rather than held.
- Bounded, and not all in the same way. A hundred notebooks each, five thousand elements and a hundred pictures on any one of them, ten megabytes a picture, fifty links, thirty people you can share one with. The canvas ceilings — element count and board size — are enforced on every write. The counted ones — notebooks, pictures, links and people — are checked just before each write, so two racing at once can leave you a single item over the line. Deliberate: a unique index is not worth one extra notebook.
- No SVG pictures. PNG, JPEG, GIF and WebP. SVG can carry script and would be served from our own origin, so it is excluded on purpose rather than pending.
Where this leaves the week
The case for the notebook is not that drawing is nice, though it is. It is that the thinking was already happening somewhere — and wherever that somewhere was, it had no idea which project it belonged to, could not be searched next to the rest of your work, and lived on exactly one laptop. Putting it beside the projects it is about means it is searched with them, linked to them, and lives wherever they live.
And the e-ink work leaves a lesson that is smaller and travels further than the notebook: if you build anything somebody might open on e-paper, check your borders before you check your text.