Falling Down The Rabbit Hole
How a Dropbox Paper bug led me back to using Markdown for my Zettelkasten notes system
I have been using Dropbox Paper for a few years as an alternative to Google Docs. Principally I was motivated by the integration of tasks into documents, allowing a content-centric work management approach. For example, up until quite recently, I would create and maintain a project plan document for every active project, looking something like this example:
I’ve written a bunch about Dropbox Paper and the announcements about repositioning Dropbox as a ‘smart workspace’ with a cascade of new features (see Departing the File Platform, Dropbox Spaces and Dropbox Paper: Not Totally Integrated, Yet, and Dropbox Launches ‘Smart Workspaces’). But I recently encountered a fundamental design issue.
Dropbox Paper, in principle, supports tags. That is, when I add a string like ‘#string’ into a Paper doc, Dropbox will treat it as a link. You can see one in the screenshot above: the ‘#video’ tag at the bottom. The blue coloration indicates it is a link.
This is where things go sideways.
I was using tags in my daily journal files, which until quite recently I had been managing as Paper docs, one for each day. For a long time, my principal mode of using these journal docs was driven by writing the Work Futures Daily newsletter. So on a Thursday, for example, I would look back over the past few days of journal files, select the stories I would stick into the newsletter for that day, stories that I had pasted into the journal docs in the past few days. All good.
But recently I was trying to find a few journal entries from last year. I recalled that I had tagged them ‘#platform-capitalism’, so I searched for that tag using the Dropbox Paper search. This is what I saw: over sixty hits when I knew it was only a few tagged instances.
Here is a search within a Paper doc, showing the tag ‘#platform-capitalism’:
I will jump to the chase: what I saw was a long list of files — Paper, PDFs, and even audio files — that contained either ‘platform’ or ‘capitalism’ in their title or contents. Which is not at all what I expected, or actually what anyone would expect, I think. More importantly, it makes tagging useless.
I did some fuddling around, testing the hypothesis that Dropbox seemed to ignore the special characters in the tags. So the search for ‘#platform-capitalism’ is basically converted to a combined search for either ‘platform’ or ‘capitalism’. And that is indeed the case.
I sent this situation into the customer support folks at Dropbox, and suggested that this state of affairs makes tags useless for their purpose, which is to find only the documents in which the tags have been placed. After some give and take, a diligent customer support person (name withheld because I didn’t ask to use it) stated that, yes, Paper tags just don’t work [emphasis mine]:
I checked with our engineering team about the expected behavior of the #hashtag searches. At first I thought the issue was due to the hyphenated hashtag, however, it look like the single word hashtag search also works the same way. According to our engineering team, this is the expected behavior. Applying a # to a search term makes it easy to click on the link to initiate the search, but it does not make the search exclusive to the ‘#word’, but it will find any document that includes the ‘word’.
I can see how this is not what you expected for this search, because I expected it to work like a #hashtag like on social media (like Facebook, Twitter, Instagram, etc…). So, the only way to make this truly work in the way we are expecting is create a non-word search term. For this reason, I will be flagging this for feedback for our developers. When building features within Dropbox, we value customer input when we are looking for ways to improve.
The support person is just reporting the facts. What is perplexing is that someone in engineering — or everyone in engineering — thought that this was a sensible implementation of tags. And that they are apparently not treating it as a bug.
What I think happened is that the engineering folks building Paper simply opted for a cheap solution: use the existing general-purpose search of Dropbox for tag search. However, the general-purpose search does not index for tags, so it’s a kludge not a solution.
This state of affairs came to light while I was involved in another project, creating a ‘knowledge system’ based on tagging a repository of documents as I wrote about in Building A Zettelkasten In Typora. Zettelkasten means ‘note box’ (more or less) and was originally a manual note-taking method using index cards. I was exploring using Dropbox Paper for a digital version when I found this tag design flaw. Typora is a markdown editor that I have had a lot of experience with, and its tagging system is excellent. For example, a search for ‘#platform-capitalism’ — now that I have exported various documents from Paper into Typora — shows this:
The nice thing about the result — after the obvious fact that it only finds results that have the tag — is that it highlights the lines in the documents where the tag occurs, and when you click on the highlighted lines the document opens on that line.
A Cautionary Tale
So, an odd story, in a way. Yes, I am a power user, fiddling to a degree that the average user might not. But to have a foundational feature implemented in a way that simply does not work is odd. Oddest of all is to not fix it, and to state that the flawed results are ‘the expected behavior’ is ludicrous.
Also, it’s hard to believe that no one else has ever encountered this problem, in all the years that Dropbox Paper has been deployed. Maybe no one uses tags? Maybe no one searches for them? Another oddity.
I’d hasten to add that I have discovered some bugs in Typora during this investigation, so they aren’t perfect, either. But their bugs are not fundamental design flaws: just coding errors. And when I pointed them out, the Typora folks acknowledged the bugs and fixed them, mostly, which is ‘the expected behavior’, at least in my book.