Following up to this, I have been brainstorming with myself about the most efficient options/UI elements shown to the user at each of the 4 states:

When the user is actively editing the block (writing flow)
When highlighting text (contextual toolbar)
When hovering a block
When clicking on a block

Can we contextually isolate the options for each of the interaction levels above, so that we only show a minimal but useful amount of tools and options to the user?

Each of the decisions taken for every of the above states will define the weight of the block. If a block gets too heavy, and the page is composed of many blocks, we have a heavy page. The weight metaphor here might not only refer to visual information, or in regards to performance. It might depend on the editing levels that is provided for each interaction stage with the block.

UI elements for Block Hover

There is a text block. What might someone want to do to a text block apart from editing the content? Can we provide the options the user needs at this very first level of interaction? Should this UI accommodate only for the hover state, or it should remain when the block is in focus as well? Should these apply to all blocks globally? Should we find a consistent hover vocabulary for all blocks?

Possible actions on hover would be:

Change the block type (convert to a quote instead of paragraph)
Move/reorder the block (either with arrows or with dragging. Maybe both)
Delete it (perhaps with a click-and-backspace pattern as has been suggested, or a trash bin?)
Perhaps duplicate a block

If the above assumptions are correct (they are assumptions for now), then we evaluate how and where to show these elements/buttons.

(important: in the hover case, we should not forget that the borders of the block would(or would not) appear. I am referring to the block element’s box that currently appear on the prototype.

This prototype: https://iseulde.github.io/editor-blocks/ does not give any hover options on hover. This is interesting and helps with the problem of an indeed busy editor screen with som many hovers. This approach though has the cost of not-direct manipulation of the block.

UI elements for Block Click

Now, what happens when you click on a block. What is the UI? Is it progressive and adds up to the already existing hover UI?

Apart from the case of writing, one would click block either to edit the content as a cohesive entity (text alignment or image floats in the case of image block) OR manipulate individual elements by highlighting them and using the contextual toolbar (Bold, Italics, etc). SO for the case of a text block, one possible UI set for the clicked blocked state could be:

Alignment tools (applies to all block content)
Clicking on the block and hitting backspace could easily in
Consider keeping elements from the previous UI state (hover) such as block type switcher
The block border/outline could exist or not

UI elements in writing flow

I am all in for the optimal writing flow approach. When the user starts to type I would hide everything except for the circled + icon which adds a new block.

UI elements on Highlight

Highlighting text brings up the contextual toolbar. Would like to explore flows and ideas that do not show both control types (block and contextual). Or at least display them in a consistent, non-obtrusive way.

To summarize, I believe it's a matter of first evaluating the options/needs of the user at each of the 4 interaction states (hover/click/write). We could user-test several scenarios and adapt accordingly.

Sorry for the long post, I would love to hear your input on any of these.

Allow sorting blocks through Drag & Drop #38

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions