First Look: The Projects Plugin

Managing projects through a set of complementary views over a folder of notes is powerful.

This title of this post is misleading, because I did take a look at the Projects plugin (Github, Obsidian) in 2023, and decided at that time to continue on without it. This month I decided to take another look. Why?

In recent months, I had invested considerable effort in a task-oriented approach to project management, called Folio, quite similar to what I had adopted prior to using Obsidian, when I was using Typora. I won’t detail that system here, but I’ll just say that I sort of hit a conceptual ceiling. I’ll direct you to Rethinking Folio: Without Kanbans, which goes in some detail.

The ceiling I mentioned? I found I lacked a higher level of abstraction for work activities. In particular, I found myself wanting to unite a family of related projects against a shared set of aspirations or goals.

I wanted to be able to align key information about related projects, and keep them in synch. I also thought that seeing time period goals of related projects would be good, because I was also thinking about seasonality, or sprints: how we push of a set of problems that are interrelated.

That reminded me of the calendar view of Projects. So here we are, taking another look at Projects.

---

---

What Does Projects Do?

I am approaching this review as I experienced my return to Projects, probing and trying to see if I could implement what I needed: a way to visualize and manage interrelated activities, and across different levels of detail. This is not a review based on a cursory examination of top-level features: it’s more of a travelogue.

Let’s start with views.

Projects allows an Obsidian user to collate a group of notes in a folder or notes sharing a tag, and pull it together into a rendering of the notes as any or four views: table, board, calendar, and gallery. I did not test out the use of tags.

Here’s an example board view:

This is a board view of a project called Workings, this newsletter. You can see along the top that I have also created a table and a board view. I’ve set this up to have columns ranging from 0 work to 3 worked. I named them that way, with numerals, so they sort correctly in the table view, about which more later.

There’s some good features in the board view. First of all text fields will wrap, which is not the case in table view. Also, you can pick what fields to display:

(Note: I don’t need to have name selected since that shows at the top anyway.)

You can drag the columns around, but I set them ordinally. I added another note to the project — foo — to demonstrate the sort feature, which in board view sorts the cards in the columns. I chose the target date field, and I confess I don’t understand newest → oldest, but I wanted earliest target date first, and there you go:

The calendar view has less going on, but here it’s using target date, and I selected ‘2 weeks display’, because all the target dates are in a two-week window. But there is no way to select the specific two weeks I want:

When I click on the back arrow next to the Today, I see the previous two weeks: there is no way to get the previous week and the week of 29 January. I can switch to a Month view, but that’s not optimal since I only have three notes and they’re all within a two week period. And unlike the board view I can’t select what fields are shown: all that is shown is the name of the note.

A more complex project and a look at Projects notes.

The workings project was tiny, how about something more complex?

One of my motivations leading to this exploration of Projects was wanting a better way to handle editorial calendars for my newsletters, like workfutures.io. Sadly, the calendar view — as currently implemented — falls short of my needs.

First, the board view for workfutures.io editorial project:

As before, this view works very well. I’ve included the description and target date fields, and have the same four column kanban-like layout. This project has eight notes. I didn’t mention before but the cards can be dragged from one column to another, and clicking on the cards opens a form like interface that allows the values of the fielde to be edited. The fields for each note correspond to the Obsidian properties of each note. Here’s one of the notes with properties shown:

I can edit the various fields when the note is open, and add content, like the checked task. This note is 0 worked, meaning completed, since I have already written the post. I realized I should have an additional field for published date, so I will add one to that note. One way to do that is to open the note and simply add a date-time fields called published:

There a second way to add that field to the project, but I can’t seem to get it work. If I use the add field button, I get an pop-up that allows me to create the field, an select the date-time type, but it forces me to create a default value, which I can’t make empty. (I’ll update this paragraph If I ever figure it out.) Note that I can create other types through that affordance, but not date-time fields, again, for reasons I don’t understand.

I can then use the published field as the date field for the calendar:

Note that dragging the card from one day to another resets the date field, in this case the published date.

However, as I said, I can’t pull any other field information onto the date card, like the target date or description. And that makes the calendar less than optimal. I’d like the same card options as in the board view.

---

---

Going Higher and Deeper

I haven’t really explained the folder/notes arrangement for Projects. Here’s the file explorer for the workfutures.io editorial project that lines up with the example above:

Each of the notes is at the same ‘tier’ of the file system. But the two seasonality notes are more closely related to each other than to the others: they are, in effect, a subproject. The nature of Projects is that I can actually implement that subproject, by taking advantage of an Include Subfolders toggle in the project settings (at the lower right):

If I create a subfolder called ‘seasonality series’ and move the two corresponding notes to the subfolder, I have this file structure:

Note that the workfutures.io editorial project will find and display those nested notes just as before. But I can also create a subproject, seasonality project, associated just with that subfolder, and I can manage that independently. Here’s the board view:

Note that edits to notes via this view percolate up to the parent project.

Takeaway and Lookahead

Projects looks to be at least a partial answer to my desire for a way to visualize and manage interrelated activities, and across different levels of detail. I’ve only taken a first look, but I am pushing ahead to see where Projects can take me. Expect a second look in a few weeks, or so, where I may integrate Projects more deeply into the Folio system.

---