Try drastic reduced interface #38928
Conversation
draganescu
added
[Type] Enhancement
|
Size Change: +900 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
|
Just wanted to note that this helps resolve many of the pain points I raised in this previous issue: #34664 Neat to see it explored and I could see myself using it. I personally would love to have it be easier to get the toolbar back though when I need it rather than fully exiting the mode. |
|
Thanks for exploring this! I have a few thoughts:
|
|
Thanks everyone for playing with this, I am going to approach it step by step and apply each suggestion so far. I am happy that it seems to be worth pursuing 🙌🏻 |
|
I think the animation is getting there — we'd probably need to ensure interactions within the toolbar keep it open even if focus is transferred (inserter, block inspector, block list, etc). Or maybe there's another more elegant solution. |
draganescu
force-pushed
the
try/hide-block-toolbar-before-selection
branch
from
6bef879
to
989cee9
Compare
|
Lovely animations! I would still want a way in which the text flows under the browser chrome without that white stripe. I tried - before simply removing the component - with some CSS but the layout of the editor is very, very finicky 😁 |
|
Made the toolbar show on hover over some "top area". If this has a quick toggle entering and exiting this "zen mode" is a breeze on the desktop with a mouse. It would also make good use of some KBD shortcut. hover-header.mp4With animations and show on hover, the problems we need to figure out are about the layout of the editor:
Update:
|
|
Yeah the panels definitely need some thought. I'll ponder that one as time allows. Another issue I noticed is that if the auto-save banner appears, you can't dismiss it because the top bar appears above it. I don't know if it would be easy to try, but I think the fadeout behaviour would benefit from a short timeout. IE fade the top bar out 1 second (or so) after the cursor leaves the top area rather than immediately. |
|
Also a slight delay to trigger it might be useful in case you are just moving the cursor around while thinking. I'll look into it. |
| margin-top: -60px; | ||
|
|
||
| .interface-interface-skeleton__content { | ||
| padding-top: 60px; |
There was a problem hiding this comment.
It would be nice to do something the awkward gap this creates when the document background isn't white:
gap.mp4
There was a problem hiding this comment.
I assumed this wasn't going to work as easily :D Maybe we can copy the bg color, or extend the actual content, at least in the post-editor.
There was a problem hiding this comment.
Yeah applying the background to .edit-post-layout or something could work for now.
It's probably important to keep the gap, to account for selecting the very first block when there's no internal padding on the document.
There was a problem hiding this comment.
I wonder If the toolbar should reposition below the block instead of needing this gap
There was a problem hiding this comment.
A similar issue exists with the sidebars as well :D
There was a problem hiding this comment.
It'd be nice to try and make them float like popovers in this mode
There was a problem hiding this comment.
@mtias @jameskoster This gap thing is easily solved by positioning the header as absolute and giving it 100vw width. See b9ecd05 (also cc @shaunandrews as this commit shows persistent sidebars as well).
There was a problem hiding this comment.
persistent-sidebars.mp4
@shaunandrews here is the compromise: a somewhat ugly margin on floating chrome. Otherwise there is a z-index war between the top chrome and the side chrome which wither makes the sidebars impossible to close or the top bar's buttons inaccessible.
Hmm there would be an option to fiddle with z-index on hover/focus?
|
I wanted to try a delay on hiding the top bar as well. Feel free to revert or fix my code. Essentially I wanted to change:
into:
I think trackpad users with widescreens will appreciate this. |
|
I wonder if we should be a little wary of throwing the baby out with the bathwater here... is hiding block toolbars outright too blunt an instrument? Similarly, does the visual persistence of the Inspector break the 'distraction free' promise, or could that element feel more 'on demand'? It would be interesting to contemplate ways we might 'intelligently focus' areas of the UI based on the last current action. As a rough example, perhaps when I select text within a block the Inspector is temporarily hidden, and a streamlined block toolbar exposed? Likewise keypresses (typing) could toggle all visible UI, and cursor movement could reveal it again. focus.mp4Totally appreciate it might be hard to account for all different behaviour combinations and subsequent reactive UI display :) |
In this exploration, while in the distraction free mode the block toolbar is available when pressing
In #40094 having a sidebar open exists the distraction free mode until the sidebar is closed. Some sidebars are auto closing on lost focus some have to be closed from their close button. |
Thanks that's good to know, but it's not all that discoverable for the average user. To further distill my thoughts; 'distraction free writing' shouldn't simply translate to 'hide everything' :D It's probably a good place to start, but we need to ensure that common writing tasks still feel fluid. Thanks for putting that PR together, I'll take a look. But to clarify, my comment above was more conversational than instructional. It might be good to outline some defining principles for this mode? |
Absolutely! I am excited to see investment in this 👏🏻 Thank you! Coming back to the conversation here and here, in general, distraction free does hide everything. Figma's Distraction free, in this approach, is intentionally more drastic than a "light UI" mode - which can very well be better IF the achieved "lightness" is light enough to not be distracting. Also, in the mentioned apps and others, wanting specific results for which keyboard shortcuts don't exist or are not known, will bring the UI back, either by an on purpose exit from distraction free (in Figma one needs to exit with In the #40094 alternative we have a combination where via hover you can bring some distraction back. That works great with keyboard, for example using
Sure thing. We can also find them by doing small attempts, iteratively, right? |
Totally, and apologies if I'm digging up bones, I'm coming to this totally fresh. So what is the ambition here?
They feel like distinct things to me. |
|
I wouldn't call this a writing mode per se because for some people the best writing environment would be the default one, or top toolbar; for others it might be spotlight, etc. The "reduced interface" (which I hope to rename "distraction free") is more about removing UI from the canvas and working more with keyboard and shortcuts. |
|
Got it, thanks. In that case I think we should continue to pursue the idea of 'detaching' panels from the top bar so that they float on the canvas. This would be less ambiguous than something like #40094 which leaves me unsure which mode I'm in when I begin to interact with things like the Inspector. |
Yes, I like this too 👍🏻 We should detach interface elements from each other in this mode and from the canvas. Ideally (no idea if possible) they'd all appear on hover and hover on top of the content. I'll try an exploration, with hopes it does not require some huge refactoring of the interface package's CSS 🙏🏻 Also bringing things on hover into visibility always produces weird interactions with the things they hover over.
I think somewhere between these would be ideal. Once the cross block text selection solves cut/copy as well, the writing mode is built in. This is more about offering options to hide UI which cannot be hidden now, in hopes of lowering items appearing and disappearing while writing. I would also not call it writing mode because the block editor is not a text editor and I think distraction free is useful for page building as well, seeing all the canvas without any chrome cluttering it, and working with keyboard without relying on visual helpers.
What if there is something that tells you that "distraction free" mode is on so you'd expect the UI to disappear when closing panels? Maybe a toggle in the top bar or a floating "exit distraction free mode" button? This would be easier to achieve than the floating panels, potentially. |
- site icon and W menu slide from left - toolbar items slide from top
They feel unnecessary with the floating elevation
Partially fade panels rather than hiding them entirely.
…t for wp button, tools and publish, moves the distraction free css to post editor header css, introduces disabled as a prop for preference menu item TBD
draganescu
force-pushed
the
try/hide-block-toolbar-before-selection
branch
from
d76ae06
to
04ab5b3
Compare
|
In the interest of keeping this actionable I will close this PR and make a new one to continue work on. |
🚫 Do not do code review, work in progress
Why?
Description
This PR explores more drastic effects of the "Reduce the interface" setting. Currently this setting only affects bits and pieces:
In this exploration the settings does the following:
Video
drastic-reduced.mp4
What do you think?
Please take this PR for a spin and let me know of your impressions.
I would also improve the following: