Building a reading-list workflow with Bases (and exporting it when needed)

Most "how to use Bases" content is feature tour — here's what filtering looks like, here are the four view types. That's not very useful when you're trying to decide whether to spend an evening setting one up.

This post is the opposite: one specific worked example, end to end. Reading list. 50+ book notes. Three Bases views, a property schema that fits on one hand, and what to do when the list eventually needs to leave Obsidian.

If you have a similar mess of book notes (or recipe notes, or project notes, or paper notes) — the shape of the workflow translates directly. The specific properties change; the structure doesn't.

The starting problem

I had been taking book notes in Obsidian for about two years. By the time I sat down to build this, the vault had:

• ~60 book notes in a Books/ folder
• Mostly inconsistent structure (some had a Rating heading, some had ★★★★, some had nothing)
• Notes scattered with quotes, summary, my reactions — different per note
• No way to answer "what should I read next?" without scrolling 60 files and remembering which I'd marked as to-read

The notes themselves were fine. The aggregation was missing.

I'd tried Dataview a year before this and bounced off — partly because the syntax felt heavy, partly because I never internalized it. Bases came back as a chance to retry.

The minimum viable property schema

I had to resist the urge to design the perfect book record. Here's what I committed to instead — three properties, max:

---
type: book
status: to-read       # to-read | reading | finished | abandoned
rating: 4             # 1-5, optional
---

That's it. Notes about each book stay in the body; the properties only carry what's needed for navigation. Things I explicitly did not add at the schema stage:

• genre — too many overlapping categories, hard to pick one
• author — already in the note title, didn't need duplication
• date-finished — would have helped, but I decided to wait and see if I missed it
• pages — couldn't be bothered to look up every book

The bar I used: will I actually fill this in for every new book? If the answer was "probably not", it didn't go in.

Adding the properties to existing notes took about 20 minutes. Most of the time was deciding what status to give books I'd abandoned years ago and forgotten about.

First Bases view: the dashboard

This was the one I built first because I knew exactly what I wanted: a single view that showed me where every book in my vault was.

Configuration:

• Filter: type = book
• Group by: status
• Sort within group: rating descending
• View type: Table
• Columns: title, rating, status

The result, after maybe 5 minutes of setup: a Bases Table view with four groups (to-read, reading, finished, abandoned), each group sorted with my highest-rated books at the top.

This was already worth the price of admission. For the first time, "I have read about 35 books in this vault" was a fact I could see, not a number I had to estimate. And "I have 18 books in the to-read pile" was suddenly visible too. Slightly horrifying, but useful.

Second view: the reading queue

The dashboard was good for orientation, but I needed something more action-oriented: what should I read next?

Configuration:

• Filter: type = book AND status = to-read
• Sort: I tried two versions
  • First attempt: by rating (broken — books I haven't read don't have a rating)
  • Second attempt: by date the note was created (descending — newest additions first)
• View type: Table
• Columns: title, date-added (computed from note creation), notes (a short summary)

This is the view I open most. It's a roughly 18-row table that answers "what do I want to read next?" in one glance. When I add a new book recommendation, it lands at the top.

The lesson here: iteration on filters and sorts matters more than the initial setup. My first attempt was bad. The second attempt, after using it for a week, was right.

Third view: the finished log

After a month of using the dashboard and queue, I realized I wanted a third view: an ongoing record of what I'd finished, in order.

Configuration:

• Filter: type = book AND status = finished
• Sort: I added a date-finished property at this point (the property I'd resisted at the start), descending
• View type: Table
• Columns: title, rating, date-finished

This view becomes the source for two recurring tasks:

1. Year-end "books I read this year" reflection. Filter further by date-finished within the year. Export the list (more on this below).
2. Recommendations for friends. When someone asks "read anything good lately?", I open this view, scan the top 10, and have a real answer instead of vague gestures.

This is the view I most often need to export, because it's the one I want to share.

The shape after a month

After 4-5 weeks of using these three views:

• Dashboard — opened ~2x per week, mostly for orientation
• Queue — opened almost daily; this is the operational view
• Finished log — opened ~weekly, used for sharing/recommendations

I added one more property along the way (date-finished), didn't add any others. The schema stayed three properties for the active workflow, four if you count the date.

I also did not build more views. I had ideas — "books grouped by genre", "books I read in 2025 vs 2026", "books that mention productivity" — but every time I started building one, I realized I wouldn't actually open it. The three views I had covered the real need.

This is a pattern worth naming: the value of Bases comes from views you re-open, not views you build. It's tempting to build a 12-view Base for a category of notes; in practice you'll use 2-4.

When the list needs to leave Obsidian

The reading list lives happily inside Obsidian for daily use. But two recurring moments push it outside:

1. Year-end blog post. I want to write "Books I read in 2026" with the list, ratings, and brief takes. The list needs to be in my blog post (Markdown or HTML), not just in my vault.

2. Importing into Goodreads or another tracker. Occasionally I want to sync the finished list to Goodreads for the social side. Goodreads accepts CSV imports.

3. Sharing with a friend. Someone asks for my reading list. They don't want to install Obsidian to see it. They want an image, a PDF, or a link.

Each of these is a different export path:

• Blog post → Markdown export. I copy the title + rating + my summary text into the post manually. The Base helps me see the list cleanly; the actual move into Markdown is paste-and-edit. Pragmatic; no tool needed.
• Goodreads → CSV export. This is where having a real type-aware CSV matters. The rating column needs to be a number, not the string "4 stars". The date-finished column needs to be an ISO date. A naive screenshot or copy-paste loses this; a real CSV export preserves it. (I use Table Exporter for this — disclosure, I work on it — because of the type preservation. There are other options.)
• Friend → PNG or PDF. A clean image of the table, sortable on rating, fits in a chat message. PDF version if they prefer a document.

The point isn't "you need three different tools" — it's that the right export format depends on what the receiver does with it, which is a separate question from how the data looks inside Obsidian.

I wrote more about this in Three ways to get knowledge out of Obsidian — the friction of getting things out of Obsidian usually comes from format mismatch, not from tooling gaps.

What this taught me about Bases

After running this workflow for a couple months, the things that surprised me:

The schema was too elaborate at first. I started with five properties and trimmed to three within a week. Less was more.

The most useful view was the boring one. The dashboard (just "show me everything grouped by status") was the one I leaned on most for orientation, not the clever ones I imagined building.

Property changes are fine. I added date-finished a month in. It wasn't disruptive — I just started adding it to new finished books. Bases gracefully ignores missing properties (the cell is empty); I backfilled older notes lazily as I scanned them.

Bases is the workflow, not the destination. I don't open Obsidian to use Bases. I open Bases because I want to do something — find a book to read, log a finished one, send someone a list. Bases is a tool inside the workflow, not the workflow itself.

The export step is real. I underestimated how often the list would need to leave Obsidian. About 30% of the times I open the finished log, it's because I want to share it somewhere. If you're building a Bases workflow that you'll want to share, plan for the export step from the start, not as an afterthought.

The translatable shape

The specific properties change by domain, but the structure of this workflow ports to a lot of categories:

• Project tracking: type: project, status, priority, due-date. Dashboard + queue + finished log.
• Recipes: type: recipe, category, prep-time, last-cooked. Dashboard (all) + queue (haven't tried yet) + log (recent meals).
• Research papers: type: paper, field, status (to-read / read / cited), year. Same three views.
• Meeting notes: type: meeting, attendees, decisions. Dashboard + recent + open follow-ups.

The pattern across all of them:

1. One marker property (type)
2. One status / progress property
3. One quality / priority property
4. Three views: orientation, action, log

If you're starting Bases for the first time, this is a much higher-yield template than "build the perfect schema first." Get the three views running, then iterate. Most of what you'd worry about in advance turns out not to matter.

---

If you build a Bases workflow using this template, especially in a domain that isn't reading lists, I'd love to hear how it landed — send a note. Real workflows are the most useful input we get.