This was originally written on The Productivist’s forum (and cross-posted to the Anytype alpha testing forum), but I’d like to collect a majority of my ideas here, so I’m reproducing the majority of it.
I’ve been thinking lately about an idea that I hope could address some frustrations I have felt with many block-based apps, including Anytype, Notion, Roam, and others. I am curious how others feel about this, whether my concerns and frustrations are shared, and especially interested to hear alternate solutions or issues with my own.
Problem/Frustration
In short: block-based writing and editing is less “smooth” and distraction-free than I would like. Block functions are useful, but they can get in the way either functionally or cognitively when I want to “just write”. As a result I often use other non-block apps for more in-depth writing, or quick notes, etc. I would prefer to be able to use an app like Notion or Anytype for all writing, if possible, but the experience is not yet “frictionless” enough, and other apps demonstrate this is possible to achieve.
Now of course I have wondered what could possibly be creating this difference. Why do some apps simply “feel” better to write in? Notion has an extremely capable document creation and editing system. But why does it sometimes feel clunky or seemingly slow down some of the more basic aspects of writing? I am not confident I have a full picture of the potential factors contributing to these feelings, but I do note that many of the apps I am less likely to “just start writing” in are also more sophisticated and powerful, often with block-based editing or other more advanced editing and layout features. And these are great to have. But I think they get in the way of really efficient, smooth writing sometimes, and in a subtle but viscerally uncomfortable way.
Proposed Solution: Block vs. Text Editing Mode
With that in mind, I suggest that the default interaction mode should be oriented toward text editing, not showing block handles or even, perhaps, block Add buttons below the existing block. This includes essentially ignoring blocks for selection of text (treat it like a PDF viewer, for example), not displaying drag handles and the like on mouseover, etc. The “text edit” mode/status should probably be clearly displayed somewhere so people are aware (see discussion of a toggle below).
Then, to enter block edit mode, it would be as simple as holding down Alt or Ctrl (or Mac equivalent), or some other simple hotkey. With the key held down, all the normal block manipulation controls come up and you can drag and modify to your heart’s content. Not only that but you wouldn’t go to select/move a block and accidentally select text, the opposite problem as the one I mentioned above, but which also occurs for me. In fact selecting and moving blocks would be much faster and easier because the entire block could become the handle.
This additionally solves the need for a “lock” option for block editing, which I’ve seen some people request for Notion (although an overall page “lock” would still be desired).
This could also allow for even greater orientation of each mode to the needs of that type of interaction. For example more “hinting” or other UI indication of e.g. block positioning, columns, etc. that would otherwise be distracting to the writer. I would say a full outline of blocks in block edit mode would be a great addition, for example, as currently there is almost too little clarity as to where one block starts and another ends. This may be a compromise to avoid cluttering the UI too much, but if block editing were more of a “mode” then arguably you would need to worry less about such a compromise. In other words each mode could be more strongly tailored to its specific needs, rather than trying to blend between them effectively.
That might even have development process advantages as you wouldn’t need to deal with sometimes tricky implementation issues or feature decisions that run into issues of trying to determine the user’s intent between block edits and text edits. Making this more explicit should allow for greater focus and simplicity in implementing features for either mode.
For those people who might be annoyed by having to hold the modifier key to stay in block edit mode, there are a couple methods to address this, which are mutually compatible but don’t have to be implemented together.
First, you could simply have a toggle in a prominent place, e.g. in the top nav bar, between “text edit” and “block edit” modes. When you held the modifier key you’d see it temporarily toggle, too. If necessary you could even have a default “middle” position that acts as the hybrid we currently have (that tries to interpret user intent and allows both block and text edits).
Second, you could have a hotkey that toggled between the modes quickly. I would suggest just a double-tap of the normal hotkey, e.g. alt-alt in quick succession, or alternatively a single hotkey that would toggle, e.g. alt-e (for “edit mode”?). Pressing that repeatedly would just toggle between the modes without having to hold the key down. But the ability to hold the key down and be immediately in block edit mode, and then switch back to text edit mode quickly and seamlessly by simply releasing it, would I think greatly increase speed of workflow for this proposed mode distinction, while allowing for the benefits I’m outlining.
Some Specific Examples of Block-based Frustrations
I find all the block editing UI elements - handles, highlights, etc. - to be unnecessarily distracting when I am just free-flow writing. It’s great that I have quick, easy access to e.g. block move or transform or add functions, but I find I need to access those things far less than their presence in the UI supports. I do appreciate that in Anytype and Notion the handles only appear on mouse-over, but I still find them unnecessary much of the time.
I also think that the “gutter” space that some of the block editing UI elements occupy might be useful for some other things, such as toggle handles (I’ve elsewhere suggested that “toggle” should be a function/state of a block rather than a type of block), or time stamps (I have similarly suggested per-block timestamps that are visible on mouseover like Quip). Having them always occupied by block functions might be unreasonably prioritizing those things vs. other possible uses. I think it’s important to really consider what does the typical user most often want to know or do that we can utilize the gutter space for by default?
Additionally I often accidentally move or otherwise manipulate blocks or select the entire block when I am just trying to select some part of its text contents. Anytype is actually already better about this than many other systems, e.g. it can switch back to text selection if I move my mouse back into the originating block area (Notion doesn’t). But it still becomes problematic when trying to select text from parts of multiple blocks, e.g. starting in the middle of one block and continuing into another below it, but not selecting the entirety of either. In these situations most block-based apps select entire blocks only (Roam is especially bad about this). It may seem minor, but over time and repetition I find it’s still quite limiting as compared to e.g. Google Docs or any other text-only editor.
As an example of when/why I might be trying to copy e.g. a sentence or several from one block and into another, I often find myself deciding whether a sentence belongs in one paragraph or the next one when writing something like an “essay” (or block post). This happens often enough in my writing that I run into annoyances with select, cut/copy, and paste in block-based systems fairly frequently. I’m sure there are other examples for regular writers that I don’t even run into, and I know the “feel” of writing in apps like Notion is often criticized by more serious writers.
Inspiration and Existing Examples
I drew a lot of inspiration on this idea from working with 3D tools for many years. In most 3D content creation apps like Maya, Blender, etc. you have a 3D viewport in which you want to do two majorly divergent things, and often need to switch between them quickly
- You want to select and manipulate or otherwise edit the contents of your scene
- You want to change your camera position i.e. your view of the scene
Both functions require interaction with the mouse. It would be slow and cumbersome to have to go up to a toolbar and toggle between modes. So what most of these tools do is use the Alt key to temporarily enter “camera movement” mode. As long as Alt is held down, your mouse clicks and movements affect the camera. As soon as you release it, you’re back in object selection and manipulation mode. I’ve found it to be a very intuitive, quick, and valuable solution to the dual requirements of viewport interaction, and I think it could work really well for similar situations in text editors where you want to balance multiple different types of interaction effectively. Rather than try to guess your user’s goal, let them be explicit with a simple, quick key press.
Additional Notes
I recognize that this is a bit of a drastic move, and none of the major block-based apps seem to take this approach. But that’s also the point, really. I think they’re all missing out on a potentially valuable, low friction way to distinguish between what are essentially different functions that are currently often kind of jumbled together.
Most of those other apps also have lots of users complaining about how they are not as “quick and easy” for text editing and general writing. Many people who use Notion also still use e.g. Google Keep or Scrivener, etc. And there are other reasons for this too (slow app launch, lack of an “inbox”, etc.), but I do think that part of it is that block-type editing is extraneous for many writing tasks, or at least for many stages of the writing process, and it can get in the way or just feel a bit clunky vs. our general experience of text-focused apps in the past. Block manipulation often just slows things down in these cases, to varying degrees, whether actually limiting what you can easily do (e.g. text selection), or simply being a distraction (manipulation handles, etc.).
Even if you don’t like my proposed solution or the distinction between writing and block edit modes, I hope you’ll consider and suggest ways to streamline the writing process so that block editing does not get in the way. In the end blocks should be a tool that provides value and enhanced functionality, not a defining feature that imposes a certain way of working. I am curious to hear your alternate ideas!
Photo by elnaz asadi on Unsplash