Smarkerapp — How readers capture, tag and retrieve

Smarkerapp — How readers capture, tag and retrieve | smarkerapp.com

Highlights go missing for three reasons: the tag list grows past what working memory can hold, the export never happens, and the anchor breaks when the file changes. This page lays out a six-step routine — about twenty minutes a month — that fixes all three, with the measured numbers behind each step.

smarkerapp.comThree-letter rule: if autocomplete offers no label after three letters, the highlight probably does not need a new tag.Named failure: the near-duplicate tag — two words, one meaning, search results split between them.

Storage, export and search in real numbers

Measured sizes, quotas and speeds behind the routine
What you are storing or doing	Measured size or limit	What it means in practice
Browser localStorage, per origin	5-10 MB	About 5,000 plain-text highlights before writes start failing
IndexedDB in Chrome	up to ~60% of free disk	Room for years of highlights and page images, but still per-origin
3,000 highlights as Markdown or PDF	0.5-2 MB	Per-line markup roughly triples the byte count
3,000 highlights as plain text	150-400 KB	The smallest durable export; keep one per session
A4 scan at 300 dpi, uncompressed RGB	~25 MB per page	A handful of pages can exhaust a small storage quota
Same page as JPEG, 1,500 px long edge	300-500 KB	A 50-80× reduction with no visible loss on a screen
Indexed search over 10,000 notes	20-80 ms	Feels instant; this is what your exports buy you
Unindexed scan of the same 10,000 notes	50-200 ms	Tolerable once, painful as a habit on a mid-range laptop

Measured sizes, quotas and speeds behind the routine

The routine: six steps, twenty minutes a month

Tagging works when the vocabulary is fixed before the reading starts and audited after it ends.

Highlights rarely vanish because an app loses them. They vanish because the tag list grows past what working memory can hold — Miller's 1956 result puts that at roughly 7 ± 2 items — and past 10-12 flat labels a tagging session slows down and starts minting near-duplicates.

Volume makes it worse. At 200-300 words per minute a 250-page book is about ten hours of reading, and a single long session can produce 300 or more highlights; without a fixed label list, each one gets a freshly invented word.

The loop below has six steps. Each step names the failure it prevents, so when something breaks a month later you can tell which step was skipped.

Once, before tagging: fix a label list of 10-12 words (about 15 minutes, one time). Skipped step → the near-duplicate tag, 'memory' and 'memorisation' splitting your search results.

While reading: highlight the single sentence that carries the claim (no extra time). Skipped step → the paragraph-long highlight that matches everything in search.

Per highlight: pick an existing label from autocomplete (5-10 seconds). Skipped step → the invented synonym you will never search for.

For the few you must remember: add a one-line question note in your own words (20-30 seconds). Skipped step → the bare highlight; re-highlighting alone gave about 36% delayed recall in Karpicke and Blunt (2011).

After each session: export to Markdown or plain text (about a minute). Skipped step → the orphaned library when the app closes or the origin's 5-10 MB localStorage fills.

Monthly: search the export, merge duplicate labels, re-anchor what broke (15-20 minutes). Skipped step → the silent offset break after a document is re-downloaded.

The dossier: capture, keep, retrieve

Choose labels you can hold in your head

A tag list is a working-memory object, so it obeys working-memory limits.

Keep 10-12 labels. That is not tidiness for its own sake: beyond a dozen flat labels, choosing one takes longer than the highlight is worth, and the session starts producing pairs like 'memory' and 'memorisation' that split your search results between them.

Write labels as single lowercase words, one idea each. When a highlight seems to need a new label, type the first three letters into the tag field and read what autocomplete offers; if an existing label covers the highlight, use it and move on.

Reserve new-label creation for the monthly audit, when you can see the whole list at once. Merging two near-duplicates then is a one-minute job; discovering them across six months of exports is an afternoon.

One word, lowercase, no punctuation
No two labels with the same meaning or stem
New labels are created only at the monthly audit, never mid-session
When in doubt, reuse: a slightly wrong existing label beats a perfect new duplicate

Tag, note, or nothing: the three-way decision

Every highlight earns one of three fates, and 'nothing' is a legitimate one.

A tag answers 'will I search for this by theme?' A note answers 'must I remember this without the text?' If neither answer is yes, the highlight itself is the problem — delete it or never make it.

The reason to be strict is the memory data. In Karpicke and Blunt's 2011 experiment, students who read once and re-highlighted recalled about 36% of the passage on a delayed test; students who practised retrieval reached about 80%. A highlight is exposure; a question note is retrieval.

So convert sparingly. Of the 300 or more highlights a long session can produce, the handful you genuinely need to remember should become one-line questions in your own words — the rest just need to be findable.

Searchable by theme later? Tag it with an existing label.
Must be remembered without the text? Rewrite it as a question note.
Neither? Delete the highlight — it will only dilute search results.

Export so the library outlives the app

A highlight that lives only inside one app's storage is one shutdown away from gone.

Browser storage is per-origin and unforgiving: localStorage holds about 5-10 MB — roughly 5,000 plain-text highlights — and IndexedDB, while granted tens of megabytes to gigabytes (Chrome allows about 60% of free disk), still dies with the profile or the app.

The durable copy is an export. Three thousand highlights come out as roughly 0.5-2 MB of Markdown or PDF against 150-400 KB of plain text, because per-line markup roughly triples the byte count; either way the file is small enough to keep anywhere.

Export after every session, not when the library feels big. The export is also what makes the monthly audit possible: a full-text index over 10,000 notes answers a search in 20-80 ms, so searching your exports is always faster than opening the app.

Objections readers actually raise

I already have hundreds of untagged highlights — do I have to fix them all?

No. Export once, then let search do the work: an indexed search over 10,000 notes returns in 20-80 ms, so untagged highlights are still findable by their own words. Tag only the ones you actually revisit, and merge near-duplicate labels as they surface during the monthly audit.

Why do my highlights point at the wrong paragraph after I re-downloaded the PDF?

Because character-offset anchors count characters, and any layout change moves them. Check whether your app stored offsets or quad points, re-anchor by page number first, then redo the highlight — and keep an exported copy so at least the quoted text survives the next re-download.

Isn't careful highlighting enough on its own?

The evidence says no. In Karpicke and Blunt's 2011 experiment, re-highlighting produced about 36% delayed recall against about 80% for retrieval practice. Keep highlights for finding; convert the few you must remember into one-line question notes.

The app says storage is full — where did the space go?

Probably scans, not highlights. localStorage is only 5-10 MB per origin, and one uncompressed 300 dpi A4 page is about 25 MB. Re-save scans as JPEG at 1,500 px on the long edge (300-500 KB each) and move the highlights themselves into an exported text file.