Proposal: block edit vs. text edit "mode" with hotkey or modifier

Hi all, I’ve had an idea for a while 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 you all feel about this, and especially if you can point out any problems with my proposed solution.

Problem/Frustration

In short: block-based writing and editing is less “smooth” and distraction-free than I would like. As a result I often use other non-block apps for e.g. more in-depth writing, or quick notes. I would prefer to be able to use Anytype for all of this type of thing, if possible.

Some specific examples:

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 ([see here for that suggestion](Add author, timestamp, and history per-block)). 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), so kudos on that. 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 (including Anytype). Anytype has some functions that modify this behavior, like holding Alt disallows selection of the entirety of current block, which is at least some improvement. But it’s still quite limiting IMO as compared to e.g. Microsoft Word 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.

Proposed Solution

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.

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/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 make Alt the 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 no other major apps of this type seem to take this approach. But at the same time 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.).

I also think that while Notion is one of the best existing examples of how tools like this may work, differentiating itself with better workflow and more well-thought-out design is one clear way to gain market share vs. the dominant player(s). I personally find a lot of things feel more poorly handled in Notion than I would expect for an app with $1b valuation. :smile:

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.

28 Likes

I like this idea. Users never care about blocks, it’s just how some apps work. What a user wants is to click and start writing, styling, selecting text and copying/deleting it. How the app operates is never a user’s problem. I would love to have both the ease of use of a text based editor and the functionality of a blcok based editor.

Though, such a modification would surely increase the learning curve, so I am not sure how it can be implemented. Changing editing modes upon keypress is very vim-like, which many users do not understand.

2 Likes

@BGray Thanks! I have some ideas for how it could be implemented in an intuitive and fairly discoverable way.

Would love some more feedback from other Anytype testers on this! Anyone have any thoughts?

2 Likes

This is a really elaborate thread; it has taken me a while to read through all of it and process it! Not in a bad way, though: I think the elaborations really helped with allowing other users in the forum to understand your suggestion better.

I second this suggestion. Moving from a text-only app like Notes (the native app in macOS) Joplin, and TextEdit (it’s useful, I swear!), I think there should be an opportunity for users to toggle between plain text editing and block moving. My opinion is similar to @Oshyan’s in a way. While the current hybrid method doesn’t impact much (in the end user’s experience), it’s subtly more complicated as compared to plain text-editing apps. It may sound close to an illogical statement, but the block handles (especially when mousing over the blocks) can be fairly distracting to me if all I want to do is to type things down.

I think having a toggle is an excellent idea; given the minimalistic UI of Anytype, the possibilities of this toggle’s location is plenty! I’d like to see it somewhere at the bottom; perhaps the bottom-left would be better, given that the help/support button is already at the bottom-right. I think it should be separated from the main buttons at the top since this toggle is relating only to the current page; does that make sense? If I could explain it better, I would! :laughing:

The quick toggle by tapping the modifier in quick succession is also a +1 from me. On the Mac, perhaps it’ll be logical to have the command (⌘) key as the modifier; it’s the main modifier key that exists system-wide, and for an important feature like toggling between text and block editing mode, it should be easy to access!

Thanks for suggesting this again, @Oshyan!

3 Likes

@arashnrim Thanks, very good thoughts and feedback!

@Oshyan Wow that’s a long one. I might need to reread it to grasp it all.

A few initial thoughts:

I agree 100% the user should be able to write/edit with as little friction as possible. Some of the annoyances you describe are exactly the ones I have with current block editors.

However, I think blocks, if properly implemented, can actually help making that process even better than in a traditional text editor. I agree that Anytype’s editor isn’t ideal (no block editor is, at the moment). But I personally don’t think it’s because of the UI/Blocks - it’s just because the implementation needs a bit of work/tuning.

I was actually writing about this today btw (I’m doing a short post describing my first few hours using Anytype, in case the devs might find it useful).

2 Likes

Have you considered that the fact that “no block editor is ideal” is because they’re all trying to balance the ability to be able do everything at any time with no mode switches, and basically trying (and failing, because it’s impossible) to “intuit” the user’s intent through perfectly tuned UI, UX, etc? Hopefully you would agree, at least, that there is a theoretical limit to how many functions you can cram into a GUI before it starts to unavoidably become harder to use? If so, then where is that point with block editors, and what better solution is there than an easy, quick, well-implemented “mode switch”? Why haven’t any of the many other block editing tools nailed this yet? Why do even people who love notion clamor for a “quick entry mode” or “distraction free”? :thinking:

Cool, are you going to post that here?

1 Like

Agree, definitely!

Yeah! As soon as I find the time… But it’s very basic. I haven’t had much time to play around with AT yet.

1 Like

I’d love to see this implemented. I often write first and then organize later. Having 2 separate modes for it would be really nice.

2 Likes

A year and a half later and I have been thinking lately about what my suite of note-taking tools looks like and why I still use 4… no wait, make that 7 different ones. :joy:

TLDR: I still really think the “feel” of an application for writing has a big impact on how much I end up using it. And I think that’s true for at least a decent-sized subset of people (the people that make Ulysses and Scrivener popular). What follows may seem a bit off-topic for this feature request, at least at first, but ultimately my belief is that this request would really help me adopt Anytype much more comfortably and fully.

My current app suite

Application Time in Use How it Feels What I Use It For
Obsidian 1.5yrs Mostly good Primary personal daily note-taking, journaling, some project documentation and planning
Quip (by Salesforce) 5yrs Very good Older archive of personal notes, project docs and planning, some transferred to Notion, but still used for some newer projects and other notes, depending on convenience and “feel”.
Anytype 1.5yrs A little clunky Mostly just testing still. I need database parity with Notion before I can adopt more fully, but I also have the same issue with “feel” as Notion (see below).
Notion 3yrs A little clunky Databases, easy and free collaboration. Would use it a lot more if it “felt” better to use.
Fibery 2.5yrs Good Primary work management tool, projects and tasks, increasingly used for notes and tracking of some more personal projects as well
Google Keep many years A little clunky, but fast Simple checklists, quickest sharing to multiple devices, things to copy/paste across platforms
Notepad++ many years Fast and powerful Quick text notes and manipulations

Basically I was using Quip for most of my note-taking (after migrating from Redmine) and then Notion came along. I thought it was the answer to all my note-taking needs, it added a lot of things I wished Quip had (and in many cases Quip still doesn’t). But… I never fell in love with how it felt to write in it and use it overall. It always felt… well, somehow a bit clunky or high friction, for lack of a better way to explain it. I migrated some content from Quip over to Notion initially. Yet 3 years later, while I still use Notion for some things, I haven’t moved any more content over, and I feel resistant to fully migrating. It does not feel like I want to “live” in it every day and have it as my primary app, i.e. the one tool I use exclusively, or almost exclusively. But I want such a tool, I do not want to be using 7 apps for all this! And I also do believe it is possible for one app to serve most - if not all - of these needs (with the possible exception of work management). Anytype has the promise of being that tool…

Why not consolidate already?

So why haven’t I moved more of my note-taking to Anytype, or at least Notion? Well, set aside Anytype as it’s still alpha and missing some features. But it’s worth having in the same discussion as Notion because the two are very similar, and even when all the features I need are there, I fear it will still have the same problems that keep me from fully adopting Notion. And the problem with Notion is…

Well the tricky thing about where I’m at is it feels really hard to articulate exactly what my reasons for not migrating are. And there are no doubt multiple reasons, some of which may not have so much to do with intrinsic aspects of a specific tool so much as with the burden of the very migration process itself (time/effort). But even putting that aside, when I think about which tool to do any particular thing in, at any given moment, just about the only time I actively want to use Notion instead of Quip is when databases are involved (increasingly also looking to Fibery for that), or when I need to collaborate (for which there is generally no better free solution if you need something more capable than GDocs). And even when I do use Notion for collaboration, I don’t like how it “feels” to use it. I mainly use it because it is free and easy to get other people to jump into.

So Notion doesn’t feel as good to use as some other tools, primarily Quip, and to some degree Fibery. Anytype suffers from the same issue because it works very similarly to Notion. I can’t be sure what exactly it is about these two apps that seems to feel similarly clunky, but one of the most clear commonalities is that they’re both “blocks first”. And what do the options that I prefer over Notion also have in common? They are not “blocks first”! Quip and Fibery both feel better to me, and Obsidian mostly as well. Quip and Fibery both have a pseudo-concept of “blocks”, but it is very secondary to the fundamental text, the document-like approach. And while it may not be the blocks themselves, but rather the way in which they’re handled that matters, I do think this issue is at least worth looking closely at. Because even when Notion introduced supposedly “really hard to implement and big improvements to text vs. block handling”, I still found it to be hardly better for my concerns and experience vs. before.

Which brings me back around, at last, to the point of this topic. I really do feel like the block-based focus negatively impacts my experience of using tools like Anytype. And I fear that even if it gains all the features I want and more, I may still ultimately not enjoy using it if this problem is not solved.

Is “modes” the solution though?

I think the reality is that it’s really hard to have full block capabilities and then essentially “guess” when the user wants to do block vs. text things and make it super smooth automatically in both. So it feels to me like developers can spend tons of time and energy trying to get this magic balance to work right, which again is incredibly hard. Or… they could just let the user decide when they want to do one vs. the other. And as I pointed out in my original post above, for me at least the block-type operations are generally less frequently needed vs. the more text-oriented ones, so a “modal” approach seems quite sensible.

I honestly don’t know if my proposed approach would actually make things much better. I just have that feeling. And I don’t know how difficult it would be to implement, either. But my assumption/hope is that it would be reasonably easy (by which I mean maybe a week or two of work at most), in which case it’s worth testing or just adding as an option! And until some block-based tool does add this I don’t think I’ll really be able to fairly evaluate whether it is a block-based issue, or some other difference of “feel” between these apps. But I’m confident of one thing: getting the “feel” of your app right is absolutely critical. I’m less sure that one “feel” can work for most people, as I’ve seen quite a divide between those who love e.g. Notion (or Anytype, or Roam) and those who can’t do without some cleaner, more text-focused approach, like Scrivener, etc. But I’m hopeful that with an approach like I’ve proposed, perhaps one really can have the best of both worlds.

4 Likes

This is quite a topic to read and grasp it all, but it’s an important one and I love all the suggestions! +1 one for everything :stuck_out_tongue:.

These two topics are great examples of user’s confusion between block level and text level editing and styling.

Based on the suggestions for the implementation or location of the toggle I think that is not going to be any problem. What I do miss though (and it might be there and just me missing it! :stuck_out_tongue:) in this thread is thoughts on practical implementations of text vs block mode. Just some thoughts and questions to get my thinking brain going:

  • What features would be available in each of these modes? Some might be obvious like the background color in block vs text mode, but others might be less obvious, like editing Relations.
  • Would there be any overlap between the two modes? Initially it feels like the two modes should be completely separate worlds, but this might not be technically feasible or functionally desirable. Would you need to switch to text mode to be able to type any content at all? Or should that be possible in both modes?
  • To think about future feature parity: do we foresee any difficulties implementing a toggleable mode on mobile? An upside is that touch-only (“mouseless”) platforms always require a lot more visible UI to accomplish the same, so two separate modes could be a great way to simplify the UI on these platform. On the other hand, it might add overhead/require more interaction increasing friction.

Love to hear your/more thoughts!

2 Likes

Oh man, this is going to be another long one. :joy:

No, you are more or less correct, at least in what I have said so far. And this was somewhat intentional. I was curious to see if the core concept resonated with people, without defining too specifically what might belong in one mode or another. I thought that getting too specific from the start might devolve more into a debate of what functions belong in one mode or another, and miss the greater discussion of whether this is a valuable overall UI+UX concept in the first place. I can understand however that some might find it difficult to even evaluate the idea without specific examples of how it might be applied. I did try to provide some examples in my first post though.

The core proposal I was making is that block-oriented UI/UX elements are useful and powerful but can be distracting and even disorienting when they are not useful to your immediate purpose, which primarily (though not exclusively) occurs in writing. Another example of where block manipulation functions are not useful is in viewing/presenting/printing. This is a far more obvious example, but it might be instructive in getting at the more subtle potential need for a “text editor-only” mode.

First I have to assume we agree on my core tenet, which is that writing and “layout” (blocks) are somewhat separate “modes” and ways of working (although they can certainly be used in rapid succession), and perhaps more importantly that block functions (and limitations) can distract from writing. Given that understanding, from my perspective the key to figuring out what should belong in one mode vs. the other is to really define exactly what is distracting or otherwise unnecessary in what contexts (we don’t necessarily have to figure out why, the “what” will at least help us figure out what to try hiding first). And simultaneously define what is “necessary” or valuable to a given mode of interaction.

Again I hesitate to make this my definition of what these things are, I really am interested in how others see this. But here are some initial UI and interaction elements that stand out to me as being distracting while in “writing mode”:

  • UI
    • Block drag handle (on-hover)
    • Block add button
    • Column resize widget
  • UX/Interaction
    • Text selection “jumps” to full blocks when you drag across more than 1 block
    • Which leads to not being able to highlight and manipulate text across multiple blocks, from formatting to copy/paste, etc.

Once you have a good idea of some major ways in which the UI/UX elements specific to one “mode” distract (or detract) from interactions in the other mode, you can conceptualize what each mode might do, but only in part. You are in the “eliminate distraction” phase.

Next, assuming the separation you have initially sketched out, you can now ask the next important question: what changes could we make to each mode which would empower that mode to be better than it otherwise can be when we are trying to service both interaction methods at the same time? Here’s one really obvious example to get the ball rolling:

If text selection were not part of block edit mode (as I think it should not be), then each time you clicked or dragged anywhere on a block it would begin to move or select it (depending on the interaction, e.g. as part of a multi-select). This would make it far easier and faster to rearrange blocks because you don’t need to hit a relatively small drag handle to target the right block.

The same goes for any block-level formatting, really. Having modes could facilitate a powerful and quick formatting of many blocks on a page. Even some kind of “block format sync” or “block format painting” that might not interact well with the needs of text editing and selection functions. I mentioned some other ideas (e.g. more persistent visualization of block structure) in my first post above.

The other important point to make is that implementing this does not necessitate removing the “hybrid” mode we have now. I believe the developers have made their best effort to balance the needs of text vs. block editing tasks in a single “mode”, and they can continue to do this as the default development target. However they can also now implement functions that they might otherwise have avoided, delayed, or even decided against since they might negatively impact other modes of interaction too much. The idea above of the entire block being a drag handle is a clear example of something potentially useful that would not be implemented because it would destroy some normal text interactions if it were the only way things worked. But as a mode for how things worked it might be very appropriate and even very useful to have.

I do initially think there should be some overlap, though again we may simply have to have these modes to test out before we really know what will feel right. But my general approach would be to not remove or limit anything that we cannot identify as actively interfering with the needs of the current mode. “Interference” includes non-functional distraction (i.e. UI elements that show up when we don’t care about them, but that do not actually interfere with something functional we’re trying to do), as well as functional aspects that do prevent or hamper us from efficiently doing something we want to/should be able to do…

For example, as mentioned above, perhaps we want to highlight text across two partial paragraphs, the end of one, and beginning of another. Typically, by default, they would be in two separate blocks. We’d have to move them into one and use Ctrl+Enter for a new line in order to highlight them right now as drag-selecting between two blocks highlights the entire blocks in the current UI. With a text-edit-only mode we could highlight whatever we wanted and not worry about blocks; block selection just wouldn’t occur.

This is a really excellent point in favor of the concept and I hadn’t even considered it. However… if you think about it mobile is already sort of an example of this “modes” approach! You have to click and hold or hit a button to go into block move mode! The blocks otherwise don’t really distract you or get in the way because there is no “mouse over” concept. Imagine if they did though, it’d be like desktop! :smile:

But now also imagine if there was a more “permanent” (i.e. “sticky”) block mode on mobile, and in situations where you wanted to move multiple blocks, for example, it would be a lot easier and faster. Right now I think you’d need to go repeatedly in and out of block move mode, since it drops you back to “normal” (text-focused) mode after each operation. It’s not that hard to get back into it, e.g. just long-press, but still it might be faster/easier.

And I don’t think it would actually be problematic to implement the switch function on mobile. I see it as a little toggle, which could either be a small 3-position switch at the top in-between “synced” and the 3-dots menu, or it could just be a different color and/or mode title in that status bar and swiping left and right on the bar area would change the mode. Something like that. Or another button in the bottom toolbar, there’s room (for now, at least)… Anyway, doesn’t seem at all a hard problem to solve.

I hope that helps give some more ideas and context. I feel like I keep spending a lot of time trying to explain my thinking process here and I’m not sure if it’s ever as clear as I want it to be. :smile: My real hope is that this is easy enough to implement that it just gets put in as a test and we can try it and see if my analysis and intuition is correct on this.

:memo::thinking: One thing I do know for certain, though: I viscerally prefer writing in other tools besides Anytype and Notion, even though I otherwise find great utility in both. I’m really curious if others feel the same way. If so, that I think does point to a real problem worth solving somehow, even if it’s not in the way I suggest. :bulb::zap:

2 Likes

Just now I stumbled on this again and read this comment. Really nice write up. I agree/identify with most of it.

Haven’t read your other huge comment yet… Maybe 5 months from now :stuck_out_tongue:

2 Likes