Consistent, matching icons

[michael]

Not critical, but we have nice matching tool icons everywhere except for these fellas. They could need some polish at some point.

[johannesmutter]

Will work on a more consistent icon set!

[johannesmutter]

Is there a reason why you have two buttons for "cycle type" and "cycle layout"? like would an object ever have both a layout and type you can change independent of each other? Or are these just different labels and it could be consolidated (shortcuts can stay different, but question also arises why a different shortcut). In my projects it's always just one tool for looping through options.

[michael]

Each node can only have layouts in that dimension. The type switcher is there to turn the current node into another type. That's now only available when a node is "empty" (= all fields have the default values), because as soon as you entered some content you'd loose data with a type switch.

there's an exception: you can switch types

the visual picture i have this is kind of a matrix:

+----------------------+----------------------+
| Paragraph            | Paragraph            |
| normal               | muted                |
+----------------------+----------------------+
| Heading 1            | Heading 1            |
| normal               | muted                |
+----------------------+----------------------+
| Heading 2            | Heading 2            |
| normal               | muted                |
+----------------------+----------------------+----------------------+
| Story                | Story                | Story                |
| image-left           | image-right          | image-top            |
+----------------------+----------------------+----------------------+----------------------+
| List                 | List                 | List                 | List                 |
| list-style 1         | list-style 2         | list-style 3         | list-style 4         |
+----------------------+----------------------+----------------------+----------------------+

with the up/down (type switch) and left/right (layout switch) you select one of the boxes. type switch always resets to layout 1 because layouts between are typically not compatible. (maybe we could keep the layout number if the type properties match 1:1).

anyways that's the visual methaphor, that's why i had this radial button with all 4 directions in mind once.

[michael]

sometimes it's a bit blurry what is a different type and what is different layout, but that's only relevant to the developer to make choices.

regarding your question, we could potentially reduce to just one button if the algorithm is, try next layout, if there is no more switch to the next type, so you could use one button to cycle through all types x layouts (each) combinations. i thought that exposing these two directions will help you be faster, and create this mental image of of a type (e.g. descriptive gallery with image+title+description) and then layouts (sometimes big images, sometimes compact etc)

[michael]

Will also port the inline code mark from editable website to here, so that would be another icon.

[michael]

I'm switching to a classic explicit variant selector, that flattens type+variant combinations, so no icons needed for change type / change layout.

I wonder if the select parent button should be placed closely to the variant selector, as often what you want is to select and change the parent node's variants? Just curious what you'd think.

[michael]

Also: Selector is currently a native select with explicit names. In an app where you have a fixed set of types+variants preview thumbnails may work better, but for Editable extensibility is crucial, and i don't worry about it looking a bit less technical / polished. at least for now.

PS: Changed the layout property from numbers to explicit ids, which are the ones rendered in the dropdown.

[johannesmutter]

I wonder if the select parent button should be placed closely to the variant selector, as often what you want is to select and change the parent node's variants? Just curious what you'd think.

Get rid of the button in the toolbar. Render as overlay near the selected node. For multiple nodes near the last node in selection direction. So if I select the first node, then expand selection downwards render near the last node. Applies to both desktop and mobile. But especially useful on mobile, since there's no ESC key ¹

See this issue here: #336 (comment)

Footnotes

1. Side insight: In an experiment I'm using the iPhone volume control buttons as custom toolbar actions buttons on mobile. ↩

[johannesmutter]

PS: Changed the layout property from numbers to explicit ids, which are the ones rendered in the dropdown.

In svedit? Is that a breaking change?

[johannesmutter]

First ideas for the group / section annotation (nodes range) icon

[michael]

Get rid of the button in the toolbar. Render as overlay near the selected node. For multiple nodes near the last node in selection direction. So if I select the first node, then expand selection downwards render near the last node. Applies to both desktop and mobile. But especially useful on mobile, since there's no ESC key

Yeah "select parent - ESC" might be a good exception for no overlays at the canvas. Need to try/experiment.

In svedit? Is that a breaking change?

Only in Editable atm. But might carry that over to Svedit in next release. This stuff is not part of the Svedit API, so it's not a breaking change.

I might add some additional schema capabilites like values for string properties, and min/max for integer properties. This way we can get rid of the extra node_layouts config, and have it all in one place. See: #334 (comment)

[michael]

First ideas for the group / section annotation (nodes range) icon

I think for group the "brackets enclosing content" visualization fits quite well. It's mostly about the execution of the icon so it matches with the rest.

Something along those lines:

I also like the "tie together" angle, because for Editable that's whats happening with respect to spacing.

[johannesmutter]

New icon set incoming (WIP). All crafted from scratch. I'll use this chance to also improve the toolbar designs.

[johannesmutter]

Toolbars are now rendering on desktop where they belong: contextual at the selection

A couple advantages of this approach:

• less long distances for the cursor to travel to the tool from the selection and back again
• no need for perceptual re orientation, the spot where you make a selection is already in focus by your eyes
• Toolbars show only the tools relevant to the actions
• Therefore toolbars become more compact, and scanning/ discovery is easier: the brain doesn't have to decipher 10 icons and labels, but a smaller subset, less cognitive effort

Currently the toolbar uses the node as anchor reference point for positioning, but it would be better to render relative to the text selection. So this issue becomes a prerequisite: #299

the "main" toolbar is now much more compact, and depending on your app, it becomes actually obsolete:
Like in my app the Save button is gone, due to optimistic updates, and undo/ redo are shortcut only/ hidden in ellipsis menu. So with no selection the app renders no toolbar at all anymore.

Also on mobile I fixed a couple long standing issues: with the toolbar disappearing below the keyboard etc.
related to this issue: #12

[michael]

New icon set incoming (WIP). All crafted from scratch.

Sleek icons!

I'll use this chance to also improve the toolbar designs.

Sure.

Thanks for that!

---

Regarding ESC (select parent node tool rendered on canvas). I think that only works well when there's an active node selection, not so much for when you have a text selection or a collapsed node selection, because there's no selecting rectangle to anchor this and having some floating button always around (that possibly is far away from the text cursor position) seems.

In the spirit of "clean canvas" maybe having an an "Escape icon" for that tool button would be good. Since we already have the "backspace tool (⌫)" we could add the "escape tool (⎋, ESC)" as well?

---

For completeness, since modifier keys (Shift+Enter are not available on mobile, we'd need a "soft break" tool), we can only have it active on desktop, then people can discover it, and not need to know the shortcut to make soft breaks.