Visual clues (or lack thereof) in the editor

[feragnoli]

Hello and thank you to all the ones involved in this project.
I wanted to share my two cents of feedback regarding a few visual aspects of the editor (since it is, uhm, a visual editor indeed).

This is by no means intended to be a critique; I am well aware of the size of such a project and just wanted to chime in on some aspects that - in development - might be lost or lag somewhat behind. I am somewhat sure some of these points have been addressed elsewhere - here and there. Apologies if double-posting.

As-is the editor is somewhat of a mixed bag, seems to me. It does not fit all needs of either theme developers or end users.
But if the aim is that of building a usable visual editor… then I'd say that visual language aspects of it should be close to core principles in its development.
So, here follows a list of points I'd consider eligible for attention, some general, other specifically related to the Site editor

General points

1. Clearer separation of Site editor and Post editor
   the two are virtually not distinguishable now and that carries a lack of clarity regarding the environment one is working in

2. Possible integration of the editor (both Site and Post) inside the wordpress dashboard
   This might sound in contradiction with what I said at the previous point. It isn't.
   The editor right now opens a splash-page kind of editing UI which is too far removed from the admin dashboard UI.
   That results in useless clicking-through in order to go back to a previous page (in Site editor, for instance, when navigating between template, pattern, template parts, styles pages).
   Furthermore, the editor provides a 'distraction-free' editing mode that can be activated

Site editor points

1. main menu inconsistencies
   Patterns and template parts are merged in the same page, right now. This might reflect the somewhat hybrid lack of clarity that both elements share, right now. Clearer separation wouldn't hurt.
   note: in itself, the presence of Pages could be debatable … (since they're editable some place else and … they are just custom page templates after all)

2. main menu inconsistencies (2)
   Styles and Pages UIs now trigger a second left sub-sidebar (unlike Patterns, Navigation and Templates)
   That's somewhat of a waste of real estate, especially for UIs Styles' one

3. main menu navigation
   the current breadcrumb/chinese boxes behavior of the Editor's navigation menu is not overseeable enough (this ties in with a possible inclusion of the editor's interface into the dashboard).
   e.g.: editing a template one has to click its way back/up in the menu. granted, one can command-K to - say - Pages but a direct access to the a clear menu would make for a lot more clarity.

4. Save/discard changes
   The Editor is very eager to let users know that there are unsaved changes. Too bad one can't discard them. The only way out is - save them or … revert them to a prior version before saving.

5. Styles variations labels
   Style variation icons are anonymous. They might - or not - display relevant differences between them but that's entirely dependent on the circumstance (say… I canged the background color of one). In development, that's rather messy.
   It is possible to save style variations by name but not displaying their name under the preview icon is problematic (consider a scenario of incremental versioning: my-theme-1, my-theme-1.0.1, etc…)

6. Lack of visual clues in the block editor
   I guess it'd be desirable for a visual editor to discourage hidden customization as much as possible. Yet, there still seems to be the need for it. That said, at the moment, any non-default customization of a block can turn out to be virtually invisible.
   Specifically:

• the block inspector controls (right hand of the editor) should probably report, at the top, non-standard properties (assigned) now buried (at the bottom) under 'advanced'. that would be in line with the behavior of the neighboring tab (template) where at the top informations about the current template are displayed
• similarly, when a custom class is assigned to a block, that should (could..?) be reflected by a visual clue (some {} icon..?) in the left-hand template structure treeview (that already happens if a block is assigned an id, for instance)

7. naming inconsistencies in blocks and the generated markup
   several blocks implement markup in a rather not-transparent way. their names make it even more confusing.
   one example for many: the Post template in the Query Loop block which behaves as - indeed - template for the individual post and control element for the wrapper of all posts displayed (in this case the
   wrapper that defines the structure of the list displayed: list, grid and so on)

thanks