Hello Marius L.J.
1) Re
“Windows file system” approach
Though Windows Explorer uses this type of layout, this is not the aim to replicate that.
The aim is to use a menu system that is similar to those used by text editors, and graphics design systems, so that users will be able to “discover” functions in locations that they would otherwise “by familiarity – expect” to find them.
2) Re
group things
Yes. That is the fundamental concept. Group tasks/functions of similar use of applicability, so this reduces the expanse of screen space that needs to be looked over to find what the user is looking for.
3) Re
it would also hide them much more than they are today.
Bearing in mind that one of the significant adaptions of the Gutenburg editor is the use of “blocks”, and that all these blocks are selected from a drop down menu (that is quite lengthy).
Taking the same line of thought and applying it to the “block selector menu”, then these are being hidden. Does this mean that the blocks may be better presented across the top bar/side-bar/area of screen so they are readily apparent and not hidden at all?
4) Re
Discoverability is something we are still working on improving and I fear that moving things into menus and sub-menus like this would make them harder, not easier, to find.
Yes – please do some more work on improving “discoverability”.
It is also helpful to avoid causing the user to “feel lost”.
The main thing is, users are used to finding things in certain places. This is only a convention. But it does mean that those places are where they will probably try first. If “those places” are not even present, then that means that the UI is very unfamiliar – and it becomes yet another learning curve (i.e. impediment to walk in and start using straight away).
At present the UI is not very populated, so anything that pertains to functions, is probably going to become evident with only small exploration (and need for “exploration” is another indicator that the UI is neither familiar nor intuitive).
But the future additional functions of this editor are going to increase the complexity of the UI at least threefold (two more main uses), not including any extras (nor third party additions), so it is important to set the framework now, so as to make the incremental improvements to functionality, without needing to do a UI redesign partway(s) along the way.
5) Re
This is a website after all, not a desktop application, so the expected user flows differ a fair bit
Whether the application is based on a website (server based) or on a desktop (local machine), it is still an application that the “user uses functions to complete a workflow”. Notwithstanding limitations of hardware, the User Interface appearance is designed for the user, and good UI design is helpful no matter what the equipment is.
As an example of complex editors, video editing can be done on desktops or servers. But all the other applications that are now becoming available on the cloud, do not radically change the appearance of their user interface, just because they are based on a server. In fact many are designed to be as similar as possible in appearance to their original local machine based version.
To be clear – I am not suggesting “copy”, and there is no desktop version of WordPress (though it can be set up on a local PC server), but the concept of top menu generally following task processes left to right (or RTL in some countries?), should be a concept that is born in mind when placing functions in the UI layout. So “grouping” is part of that – whether grouped in a sub-menu, or placed next to each other in a main menu, or just placed in a similar area of the page, is going to be helpful for the user to quickly become accustomed to the UI.
6) Re
(also, how do you distinguish between File in the editor and File in your browser, that kind of confusion is what we would like to avoid).
You may have noticed that at no point in the suggestion have I mentioned “file” in connection with the website design, but it was used to “draw a similarity”.
The similarity being based on the task flow process.
7) Re
They’re interesting thoughts though, and I’m glad to see that more areas of the editor are being evaluated! If you’ve got some input on my understanding (hey, perhaps i misunderstood you, it happens, please feel free to follow up!
Thank you – I think we can talk, and I hope you look forward to discussion.
8) Here’s an additional thought – side-by-side UI testing.
Similar in concept to the use of “swap in/out” plugin for Gutenburg and Classic editors, which allows users to try something new, compare, and restore to original if needed;
It is good during development of environments that involve UI, that there are facilities for trialing and comparing options (e.g. layout, styling, sub-layering of interface, etc). This can be done in two main ways;
The developers set the UI and maybe have more than one option (e.g. as is the case with Gutenburg or Classic), or the developers allow for an adjustable UI that any user can customize to their liking (possibly gathering data of feedback, so as to be able to have the software suggest suitable default settings for a beginner to start using it with).
It would be handy for users to be able to choose their preferred layout, independently of what the developers anticipate the user may (or may not) want.
“Layouts” are about placement/locations. The functions that get activated by items embedded in the layout, depend pure on the item and not on where it is placed. So given the functions that are available, the layout can be relatively easily altered.
So themes/templates could be possible.
But …
since Gutenburg is aimed at making customizable page layouts, and the Gutenburg editor is actually just a webpage (but its purpose is for editing), then perhaps Gutenburg could be used to design the layout for its editor interface (UI) page.
And that function for designing the editor page layout, could be entirely made available to a user, if a user wanted to.
But this all depends on the developers being willing to have this happen.
Thanks
