I’m starting to think project context belongs above the file system

Cool Workflows
1

Hi everyone,

I’ve been thinking more about the replies to my earlier thread on files that don’t really belong in one place, and one idea in particular has stayed with me.

I’m starting to wonder whether I’ve been expecting too much from the file system itself.

More specifically: maybe the file system shouldn’t be carrying project context at all.

Maybe that job belongs to the project layer.

What I mean is this:

Perhaps a file only really needs one stable home in Finder.
And then the part that answers why it matters right now belongs somewhere else — in project notes, task managers, planning documents, or whatever layer I’m actually working from.

That feels much closer to how I seem to think in practice.

When I’m in the middle of a project, I’m usually not asking myself:
“Which exact folder contains the authoritative copy of this PDF?”

I’m more often asking:
“What do I need for this project right now?”
or
“Where was that note / document / reference that mattered in this conversation?”

That’s what has me wondering whether I’ve been looking for working context in the wrong place.

Maybe files are just resources with one sensible home.
And maybe the real working surface is the set of things that point to them:

  • project notes
  • task lists
  • planning docs
  • reference pages
  • links back to the relevant materials

I like this framing because it seems to reduce the pressure on the file system itself. A file can live in one sane location without needing that location to also explain every current relationship around it.

I’m not sure yet how much overhead this removes versus creates in real life, and I suspect that depends a lot on the tools involved. But conceptually, this feels closer to how my brain already experiences project work on the Mac.

So I’m curious:

Do any of you handle things this way?

In other words, do your notes / task manager / project pages effectively become the real front-end for your files, while Finder remains more of a stable storage layer underneath?

Would love to hear how that works (or fails) in practice.

1 Like
2

I have a working file in one location in the Finder. I refer to the context of the file through other means. Generally, I manage projects in a Kanban board + project work board using Curio. I manage tasks for a project using OmniFocus. Specific to your list …

  • project notes → in Curio, in the same folder as the working file
  • task lists → in my task (OmniFocus) or project manager (Curio), referencing to the file(s) of interest as needed
  • planning docs → e.g. my Kanban board or project oversight page (in Curio), again referencing to the file(s) of interest as needed
  • reference pages → e.g. in Curio, …
  • links back to the relevant materials → not sure what this should be in my case

I have no major failures with my developed habits.

–
JJW

2 Likes
3

I arrived at a similar conclusion for my own workflow, and I’ve found that the architecture feels clearer and more scalable with this approach. For me, PKM and project management are very intertwined. Projects usually have their own specific files, but I am also frequently pulling and referencing lots of other materials that are relevant across multiple projects.

My core apps include:

  • OmniFocus
  • Obsidian
  • Tap Forms Pro
  • DEVONthink
  • Finder/Hookmark

Tap Forms is the hub of my setup. Pretty much every project and resource has a record that contains metadata, relationships to other records, and links to corresponding resources in DT/Finder/Obsidian.

My files are split between DEVONthink and Finder, but I view DT as an extension of the Finder. DT is for PDFs and information-dense materials, and Finder is for larger files and anything that requires direct file system access.

Obsidian handles all of my notes—projects and otherwise. Most Tap Forms records have a corresponding Obsidian note. So that way my project notes can easily access everything in the system via wiki links or I could link directly to DT or Finder if necessary.

So essentially, I have Tap Forms records that store links to parallel data stored in OmniFocus, Obsidian, DT, and Finder. These four downstream apps have links that point back to Tap Forms. This way I don’t have to link everything to everything else, which would be insane.

I made a post here with more details. I was using Collections Database for a while. It’s a great app; however, I found it too mobile-oriented, so I’ve made the switch to Tap Forms.

2 Likes
4

I agree very much with this philosophy. Operating systems need to do a better job of allowing objects to live in more than one place. It is a frustrating source of friction for me to simply gather together all the emails, websites, markdown documents and Microsoft Office documents, Microsoft Teams discussions and other resources pertaining to any individual project.

1 Like
5

Hookmark is a tool designed to address this problem.

I’ve tried it a few times; it’s never stuck for me.

2 Likes
6

For things that don’t need to be “files” this why I like Scrappy. There is no home for things if you want.

For things that need to remain files (or logically should) then finding a “stable home” can be a problem because our brains will want that to be meaningful in some way too.

I am reminded of the great email storage issue. For years I watched colleagues create enormous hierarchies of folders into which they filed each and every email. Sometimes automatically, sometimes by hand. Then I’d stand over their shoulder while they hunted for the email we needed in half a dozen or more different folders.

In contrast, everything in my account just stayed in my inbox, unless it was automated stuff like weekly reports or alerts, which got a folder each. If I needed to find an email, I just searched. Location was simply not a factor as I just searched the inbox. The only organisational tool I used was the read/unread status. If it was unread it still needed me to do something. With a filter to show only unread, it works great. I still use this process over a decade later.

2 Likes
7

That makes a lot of sense.

It sounds like Finder is mostly acting as a stable storage layer, while Curio and OmniFocus become the actual working surface.

Have you ever run into issues keeping those references in sync over time?

8

It feels like you’ve separated storage from context very deliberately, and then rebuilt the connections at a higher layer.

I keep coming back to the idea that the hard part isn’t where the file lives, but how easily you can reconnect it to what you’re working on.

Your setup seems to solve that, just with a lot of explicit linking.

9

I’ve had a similar experience with that. The idea of linking everything makes a lot of sense, especially when context is spread across so many different tools.

But in practice, I’ve found it hard to keep those connections maintained over time without it turning into extra work.

Curious what didn’t stick for you when you tried Hookmark?

10

This is a really useful comparison. The email example makes a lot of sense. At some point, the folder hierarchy becomes another thing you have to remember, instead of something that helps.

I like the distinction between location and state here. Maybe the stable home matters less than having a few reliable signals that tell you what something is for and whether it still needs attention.

1 Like
11

My setup admittedly is built around resources I’m referencing long-term, so it justified the overhead of the linking. Tap Forms, DEVONthink, and Obsidian are all UID links, so they’re quite robust. Hookmark is a little more fragile (installing on a new machine for example), so I try to minimize my use of them.

I’m not going through the all of that tedious linking for project-specific data (contracts, etc.)—that stuff usually just lives in a DEVONthink group with the project name, which is fine since DEVONthink allows you to link to anything or create replicants.

So I’m using DEVONthink more flexibly for project/admin data and more rigidly for my personal library, and that’s been a good balance.

1 Like
12

@MitchWagner

Operating systems need to do a better job of allowing objects to live in more than one place.

Mostly they do allow objects to live in more than one place through the mechanism of “hard” links. The big problems, which you may well know, are that you can’t hard link a directory (it would be too easy to create circular graphs); you can’t hard link across file system volumes; and there’s no way short of a full tree scan of finding out what pathnames a particular file has. The file itself has a ref count and won’t be deleted until every reference to it is deleted, but it’s a slow job finding those references.

Microsoft’s WinFS tried to fix this by imposing a relational model over the top of NTFS, but they failed miserably.

The other problem is that decades of application design founded on slow disk I/O has led to applications that embed their data in files rather than using files. That sounds odd, but consider the difference between a contact manager that has a database of contacts and one that puts each contact into a separate vCard in a directory. The former is faster and more compact; the latter more generic. That’s exactly the problem tools like Obsidian seek to address.

The ultimate solution is a long way off, a file system that connects objects as a graph, not a tree structure, and that supports highly fragmented information. Your document isn’t a monolithic file, it’s a list of atomic fragments (think Ulysses or Scrivener). Your contact isn’t a database entry or vCard, there’s an object for the person, for his address, for his mobile phone, for the notes you kept all linked together and accessible by any app.

13

Yes. This summary nicely captures my approach. Curio is for project management and idea development, OmniFocus is for task management, and Finder is for document repository. Project context is however also set by a higher-level organization of folders in the root Documents folder. For example, you might guess the context of documents in this organization of folders.

  • Document:Finances:taxes:2025 taxes
  • Documents:Surroundings:cars:car titles
  • Documents:Coding:python:examples:Python Plot
  • Documents:Hobbies:Genealogy:GEDs
  • Documents:Well-Being:health:2025 medical

Curio has a flexible, robust, intuitive set of mechanisms to link content internally and externally. It allows any one object on its layout canvas (Idea Space) to have multiple internal reference links and one external link. I’ve built an AppleScript to create a two-way link between a project object on a Kanban board in Curio to its project task list in OmniFocus.

Once I make a link in Curio (internally, externally, and between Curio<->OmniFocus), I do not ever (if rarely) need to return to update, edit, or remake the link.

Hope this provides some insights.

–
JJW

14

Actually, a folder makes sense for state (over time). E.g. having a “working folder” for stuff that is “live” and then moves off to another when it’s not. But… no more meaning than that would be assigned to the physical location. Then again… if you’re managing other metadata in some other way, its live state can be managed there, too.

15

There are database products that, I think, seek to solve these problems. “NoSQL” databases like MongoDB. But that’s a whole extra layer that’s not a ubiquitous presence on most computing devices.

16

Yes, there are plenty of user space applications that will build a graph of documents, every document management system I can think of has ways of structuring, tagging and linking documents. Similarly there are graph database that will store anything you want, some of them bring “schema less”.

But if you want robustness and portability between applications you need the implementation to be at the file system level. That, to the best of my knowledge, has never been done.

That’s not entirely true, see for example here Graph File Systems – A Filesystem Geek. I love the fact the paper references Multics, which I’m pretty certain pre-dates Unix.

1 Like