Dropbox Spaces and Dropbox Paper: Not Totally Integrated, Yet
Things That Are in the Works and Things That Should Be
The new Dropbox Spaces is — in my estimation — a revolutionary breakthrough in work management. As I recently wrote, the fundamental step forward is this:
taking the skeletal notions of a shared folder and fleshing it out into a shared space, enriched by an overview description at the top of the folder and other capabilities.
However, Spaces and Paper have a way to go to work together well. So let me start out by apologizing for a wonkish post that delves into details that many may not wish to get under their fingernails. And some of these recommendations may be resolved in just the next few weeks, at which point I will update this post. Forgive me.
Paper Features Reused In Spaces, But Not All
Many of Dropbox Spaces’ description capabilities are derived from similar features in Dropbox Paper, the company’s cloud document tool. This includes the styling of text, links, ‘@’-mentions, and tasks in the Spaces description area, as shown below:
That’s good as far as it goes, but it falls short in practice.
Although tasks can be created in the description area of a Space, they aren’t part of the same task infrastructure within Paper. So, although I can be assigned a task in a Space like that shown above, it is not accessible when I search for all tasks assigned to me in Paper. That should be fixed quickly, or it will cause all sorts of problems.
Similarly missing are due dates on tasks defined in a Space. Fixing the task issue above will solve this too, I guess.
A number of Paper component types are not provided in Space descriptions, such as tables, code blocks, ‘+’-references to Paper docs (which create highlighted links to the referenced docs), and perhaps most painfully, there are no comments in descriptions. Comment threads are essential for cooperative work, so this is a serious omission. (I will return to comments in my wishlist for Paper and Spaces, below.)
Paper has support for headings (H1, H2, H3), but these are no supported in Spaces. In particular, Paper H1 and H2 headings come with the added benefit of being toggleable, so that sections of a Paper doc can be toggled out of view, as shown below:
This toggling allows suppression of detail in Paper docs, which can be helpful. Note in the first of the two images above that there is a link icon next to the H2 heading, which — when elected — provides a link to that heading. This helps if you want to link to a specific section of a document, perhaps in some other document.
Also note that the creation of headings leads to the markers on the extreme left, which are clickable navigation elements, allowing a reader to jump to the indicated section of the doc with a single click. This can be helpful in large documents. (I often timestamp commentary in the initial sections of project plan documents, and toggle the older ones to hide them.) Although Spaces are relatively new, there is no reason to imagine they won’t grow to be relatively large, and toggling on and off sections will help with that. Note that the current design has a ‘Hide’ option for descriptions, so the designers had that issue in mind.
My sense is that until these issues are resolved, aside from the most minimal of uses of descriptions (as in the first screenshot of a Space), I would likely create a Paper called ‘About’, and create a link to the About doc in the description, so that I could sidestep these issues, particularly the problem with the two disconnected task worlds.
A Wishlist: Some Easy, Some Harder
Here’s a shortlist of features that would make Paper and Space an even better experience. They are ordered from straightforward to more complex.
Formerly, Paper docs were managed in a separate folder hierarchy, unrelated to the mainstream Dropbox file system, and there was no way to create a Paper doc except in that separate Paper world. New Paper users can no longer create old Paper docs in that isolated folder hierarchy, only new ones in Spaces. Paper users who joined prior to 9/25 are using the previous release.
When Dropbox does make the Paper integration available to previous users, they should also provide a solution for transitioning old Paper docs — pre Spaces — into the new Spaces and Paper model. The simple solution is to create an export capability from old Paper format to new Paper format, and to support it for individual Paper docs, lists of Paper docs, and Paper folders. These exports could then be imported into Dropbox Spaces like any other file or folder. This would also provide a much-needed back-up facility, or a means to migrate from Dropbox Paper to some other alternative (just saying).
Just as it is occasionally useful to be able to get the link to a specific section of a document, it would frequently be useful to be able to get a link to a specific task, or a task list. It would be great to have a link icon next to every task. (I know they have unique URLs, because I discovered a way to find them, but one that’s too geeky to be generally useful, or even described.)
Elaborating on that idea, let me describe something more usable than just getting an explicit link to a task (or a Paper doc section). Imagine that I would like to copy a reference to a task that was creating in one Paper doc — for example, a task in my daily journal Paper doc — and paste that reference into a second Paper doc — for example the planning document associated with an on-going project. However, I don’t want that second task to be a copy: I want the two tasks to be identical references to the same underlying task, so that when I make a modification in one it is reflected in the other, and vice versa. Let’s call these reference tasks. The could be set off by being shadowed, or some other visual clue.
A typical use case would be creating a task initially in my journal, and pasting the reference task in the project Paper doc. Weeks later, perhaps I might assign the task to someone else, or mark it done in the project Paper doc. This would update it in all contexts it may have been referenced in.
This notion of reference is also applicable for Paper doc sections, too. I could write a document section in Paper XYZ, reference that section in Paper ABC, and later when the section in ABC is modified any changes would be reflected in both. I think you see the utility.
Finally, consider deleting an instance of a referenced task (or section). In that situation, it might be prudent to ask the user making the deletion whether the deletion is just for the local context, or for all references if the user has the privileges to delete all instances. In any case, they’d only be able to delete instances they’d created.
A last recommendation: Paper’s tasks have only two states, at present. They are created or completed (or opened and closed). However, in reality, the way we think about work actually relies on three states: tasks are created (opened), and at some point, we actually start the work that the task references (in progress). And later on, the task is marked completed (closed).
Perhaps the in progress state could be represented by a checkbox with a dash in it, like ‘[-]’.
I recommend that Dropbox consider these three states, since supporting this richer task state model provides a great deal of information within teams about work status without having to ask. With a glance, you’d know that Bette started work on writing the XYZ proposal last Tuesday (if Paper is extended to surface that time information) without reading comments, or asking her. And of course, open tasks would represent that while the task may have been assigned, no one is working on it yet.
This post is necessarily wonkish, as I warned. Also, it may seem a bit presumptuous for me to wave my hands so vigorously about such significant changes. But as is likely clear to the readers of this post, I am deeply involved in using Paper as the medium for my work management and I have thought long and hard about how to improve the product for maniacal users like me, and for the less obsessed users that will likely follow behind.