-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more writing flow options: Reduced UI, theme styles, spotlight #22494
Conversation
Size Change: -187 B (0%) Total Size: 1.18 MB
ℹ️ View Unchanged
|
@jasmussen @mapk Any thoughts on this? |
From the ping I expected to see spotlight mode expanded to template part editing :) I've mixed feelings on this one. I share your desire for a leaner experience — a "writing mode", so to speak. Iceberg is a good example of how that can work in a plugin sense, it takes over entirely and removes any editor styles the theme might have and inserts its own. This PR hides the tool indication, undo/redo, document outline, block navigation, and preview. As you know, I'd love to merge the document outline with the block navigation tool, that's one button down. Undo/redo are helpful to surface, both to remind people they exist, and they are the only way to undo on mobile. The tool indicator is a good way to indicate that you're in navigation mode, and per some explorations Shaun is exploring, that tool might even contain more effects on the block building side of things. In that vein, I don't think you could enable focus mode and "forget about it" — you'd have to jump in and out of it depending on what you're doing. That suggests a different question: is there a place for a dedicated "writing mode" in the block editor, and is the focus mode what should be leveraged for that? If we did decide that yes, there's a place for a writing mode, we could consider going way further — like full-screen, no editor style, supply an opinionated font and layout. Something more like "Reading mode" in Safari, but for writing. I could see myself jumping in and out of this with a toggle. But I'm very on the fence about whether this is something for the core product, or plugin territory. |
I've been discussing with @mtias a bit here too and I think the original idea behind the "spotlight mode" was to be that "writing mode" you're talking about which means in these situations, you may not need block navigation, edit/select tool, undo redo... as there are keyboard shortcuts for all of these. Iceberg is actually an inspiration for this PR too and I do believe proposing to get rid of editor styles is a good option to have too. Before opening the PR, I was wondering whether we'd need granular options (hide undo, hide navigation, disable editor styles) and the realization is that we probably need both. An opinionated mode (like Spotlight) that enables everything needed for a writing mode and more granular options on the modal to fine-tune. |
That reminds me of #13688 by @enriquesanchez, wherein you hold down the modifier key for a short while to visually surface the keyboard shortcuts. In an opinionated writing mode (we should call it that, if it's what it becomes) like this, you could surface both the button and the keyboard shortcut when holding the modifier key. If we were to move forward with this, I'd think that unloading editor styles in this mode, and providing a nice alternative, would be crucial to figure out whether it works. Additionally, I'd personally be fine with postponing any option toggles. |
A writing mode sounds really interesting and useful. This could maybe even be a tool next to 'Select' and 'Edit'. I'm also having mixed feelings, but probably for different reasons. I think this is because if such mode were to exist, I'd prefer if blocks and their related UI just went away. I'd love it if there were no block toolbars, no inserter buttons, etc. Just me and my text. |
Good step toward a better spotlight mode. ❤️ I like the elimination of several tools that can be restricted to keyboard shortcuts. But if we go toward a WRITING MODE, I've got a couple other opinions. 😉
Ultimately, you'd end with something like this: |
I know @mtias cares about this a lot and argued against it. I think this effect is useful especially when you strip out theme styles, otherwise, it might not give the expected result. |
I can be onboard with this personally. |
I'm coming around to this one. If we really do want to go the route of "focus mode is writing mode", then we should actually offer a range of options just for the writing experience. |
I think there's a wide range of opinions about what we should consider for this mode, I'd like us to find the MVP here that is both useful and not hard to implement to get the ball rolling. That's the intent of the proposal here. |
Right at this moment (I'm very tired) I feel like maybe removing the editor style is part of that mvp. It would visually very clearly indicate: this is intended for writing, not building your page. |
I like this.
I hear ya, but this feels more like a writing mode now in which case the spotlight treatment doesn't seem useful. I'd argue that it's not necessary in this mode. It's the UI that needs reduction, not the content. Pushing for an MVP is great! If that means sticking with your original prototype, let's do that. BUT I agree we should drop all theme styles here, and I'd still push for removal of spotlight treatment. |
Thanks for the feedback, I'll be back at this shortly and I'll try to remove the editor styles. |
Thanks for exploring this. I believe there's a lot of potential for this mode, but it would be hard to make assumptions over everyone's preferences for what "focus" or "zen" is. I was contemplating having a section in "settings" that would let you configure the focus mode a bit. I think Ulysses and other writing apps do this very well, where things are encapsulated in a single toggle but there are also some settings to control behaviour once you switch to the mode. For example, this is sentence highlight from the "typewriter" mode: Which is controlled as a sub-setting of what they call "typewriter mode": We have typewriter-scroll built in, but it'd make sense to decompress "focus" mode into a few relevant settings:
In the future, we might be able to also use the inter-block partial selection as the default behaviour in this mode (cc @ellatrix) The model of a settings group for "focus" is something I think we'd also need for some accessibility characteristics (like always showing block outlines, disabling writing flow, etc). |
I think we should be opinionated with this one :) Dropping the + is interesting, I think we should try it. I'd still probably encapsulate that in a "reduced interface" checkbox. |
f0a1141
to
f71fd50
Compare
I pushed some updates here and I used separate options on the "Options" modal to get a better feel for every one of these options:
Known issues
|
One thing I'd add to the discussion is that for a lot of people "writing mode" would be enough, compared to a full on "focus mode". This is mostly due to the over-bearing UI that blocks bring in to the writing experience. I want to clarify this point just to highlight that there are three modes (block, writing, focus) not two (block, focus).
This is a note that transcends a bit the specific details on how we achieve it, and the detailed settings for each of the options. |
@folletto not sure I'd classify it as three modes like that as a few things traverse the experience horizontally. For example:
I think perhaps a way to simplify things would be to have a toggle "Writing Mode" that can have configurations for things that are currently spread between top toolbar, highlight settings, etc. |
I agree, these aren't necessarily modes per se. I think these are more "User attitudes", that can be satisfied with different approaches. The example you make is solid: "Top Toolbar" fulfils in part one of the modes without being explicitly "that" mode. :) In short: if we keep in mind these three user attitudes when approaching these configuration variables, I think it sets us up to do a good job :) |
Right, agreed :) @youknowriad I think we should try dropping the bottom border on |
I guess also using a "transparent" background for the header too. |
Transparent would get messy when you scroll. Can try a semi transparent background, but even just removing the border can work. |
The options need to be better organized than the current state but we need a better design of that modal first. It's being tracked here #24965 So what do you think about shipping the first iteration of this PR? |
I'm not super keen on the name |
@mtias what should it be instead. It can be "Light UI" as well, we can also add a help text explaining what it does. |
"Compact UI" might be better. This is what I see: I'm trying this branch fresh on a new install, and I was surprised to see my theme font missing. It seems like loading theme styles should be on by default, right? Also, if spotlight mode moves to options (I'm a fan!) it can be removed from the top of the more menu, right? I'd also sort "Theme styles" at the top, and upon landing the ability to turn them off, I would super bump the priority of redesigning the base styles. Noto Serif has not aged well at all, and I'd love for us to find an alternative, even if it means system fonts throughout :D ( |
yes, probably but the same could be said for "top toolbar" or "full screen mode". I wanted to avoid doing that until we have a good design for #24965 |
I enabled the theme styles by default and renamed Reduced UI to "Compact UI". |
f4c96be
to
385e3dc
Compare
I believe some of these focused affordances could live under "Spotlight", with distinct configurations (spotlight on the block, spotlight on the action). This requires some work with the taxonomy. For the short term, "Focused Mode" works better semantically. |
I definitely think the 3 "View" options should all be moved into the "Options" modal. They're all "set it and forget it" preferences. Once you set them, you're unlikely to change them, so after their initial use, they're just wasting space in the ellipsis menu. I'm not convinced "compact" is the right term to use here. I would think that such an option would shrink the toolbar size or something like that. I wouldn't expect it to hide controls. Why not just call the option "Show fewer controls" or something like that to tell users exactly what the option does without them having to guess? |
I am testing the PR using Twenty Twenty and http://localhost:8888/ (Nb. Change "Commpact UI" -> "Compact UI") I Click Commpact UI and notice that many of the top toolbar icons and the bottom breadcrumbs is hidden. The big black square with the W in it top left takes a lot of the visual attention away from the rest of the screen. Should it also be hidden? Which means to get back to the wp admin one needs to turn off full screen mode, or perhaps use the browser back button. |
2020 is not a good theme to test with because it doesn't implement the editor styles properly (using the official API). For the "W" button I'm not sure we should change that unless we find a way to avoid being blocked in the editor screen. |
I also aknowledge that the options organisation is probably not the best but i'd like for us to discuss this in #24965 and not block this PR. I expect the discussion to have very varying opinions and might require some design changes before moving to implementation. My hope is to land this as is with potentially some light wording changes. |
385e3dc
to
2c82f19
Compare
Regarding the W. The mockup from @mapk here: #22494 (comment) where the W does not contain the black background will very much help. Iterating on options is another PR. It is nice to just keep this PR focused on the writing/compact ui mode. |
featureName="focusMode" | ||
label={ __( 'Spotlight' ) } | ||
/> | ||
</Section> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a lot of options. Why not merge with spotlight?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worth keeping in mind https://wordpress.org/about/philosophy/#decisions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is one place where we can't make decision in behalf of the user IMO. Someone might want the spotlight effect combined with the top toolbar while someone else might want to remove the theme styles, use an inline toolbar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see if we can get to a better "preferences" UI next: #24965
$editor_styles_file = gutenberg_dir_path() . 'build/editor/editor-styles.css'; | ||
$settings['defaultEditorStyles'] = array( | ||
array( | ||
'css' => file_get_contents( $editor_styles_file ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we previously not use these styles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a way to get just these styles, previously we just received an array containing the editor styles the theme wants, it can or can't include these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we handle file-access failures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is already loaded that way in Core and in other places in Gutenberg, so I'm not sure we need special treatment here.
$editor_styles_file = gutenberg_dir_path() . 'build/editor/editor-styles.css'; | ||
$settings['defaultEditorStyles'] = array( | ||
array( | ||
'css' => file_get_contents( $editor_styles_file ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we handle file-access failures?
} = select( 'core/block-editor' ); | ||
const { hasReducedUI } = getSettings(); | ||
if ( hasReducedUI ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isInserterHidden
seems to only affect a classname. Is it the best way to hide?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was intentional to keep it in the tab sequence (show it when you tab into it)
The spotlight mode hasn't received love for some time now. This PR is an experiment to be a bit more opinionated on this mode which could make it more useful too :)
Here's how it looks