Focus (continued)

[iseulde]

MarkJaquith: So, one of the things I originally wanted to do (and avryl had in early versions of the Focus plugin) was to do some fading of the rest of the UI when you are actively typing into a post. I think this would get us the rest of the way to DFW's feature set.
MarkJaquith: So my goal for 4.1 would be to remove DFW completely.
​...

[iseulde]

Clorith: That's going to make some people scream xD

ericandrewlewis: If you want opinions: fading the UI felt uncomfortable to me, and I don't see a lot of user experience gain from it.

wonderboymusic: what is the impetus for ditching DFW? I never liked the fading

johnbillion: I'm not a huge fan of the fading myself, but we should certainly revisit it

folletto: fading as any animation will actually give MORE attention to the context, because will attract attention (animations attract user attention)

Clorith: I'm thinking that fading UI elments is a bad experience for users with reduced sight

Something else we could do is, instead of initialising DFW when pressing the fullscreen button, collapse the menu, switch to two columns, hide the kitchen sink, enable editor scrolling and remember the previous states. We could do this is in a way that it doesn't affect the user settings. If you leave "fullscreen" mode, we just set the original states back. Only when in "fullscreen" mode, fade out the admin bar, collapsed menu, meta boxes below the editor, title and notices, and fade them back in when they're hovered (not necessarily all at once). The admin bar and menu could fade in/out together.

[iseulde]

Far from perfect and very simple:
​https://github.com/avryl/focus

[azaozz]

Replying to avryl:

Something else we could do is, instead of initialising DFW when pressing the fullscreen button, collapse the menu, switch to two columns, hide the kitchen sink...

Was thinking something similar: we probably should try "merging" DFW with editor scrolling, not "removing DFW".

Fading out the rest of the UI on pressing the Fullscreen button may work. Fading in the UI on moving the mouse to a particular place or scrolling past the editor end may work too... Needs more experimenting :)

[azaozz]

We can look at this from DFW's side too: imagine DFW but with the full editor toolbar, and faded-out admin menu and side and bottom postboxes that will fade-in on hover.

[iseulde]

Well, this solution is kind of the new DFW. By removing DFW I mean the current solution. No need to have separate code for a new toolbar (doesn't work well anyway; no tooltips, active state etc.), the editor switch, autoresizing...
The the "merge" would be like remove DFW and start over. :)

[azaozz]

Replying to avryl:

No need to have separate code for a new toolbar (doesn't work well anyway; no tooltips, active state etc.), the editor switch, autoresizing...

Right. The current DFW is pretty much CSS based, it is very very easy to remove the minimal toolbar and move the full one to the top, including the editor switching and Add Media button, etc. No need to keep the current full-screen transitions.

What I mean is "merging" the two concepts: hide/fade-out most of the UI and show/fade-in on mouse move or hover. This will need some redesign of the Edit Post screen (for example moving the Publish | Save Draft | Preview buttons out of the "Publish" postbox like we talked about yesterday) and the ability to start in "minimal/faded-out" mode. Also, the "fullscreen" button will not be needed any more.

[mark.cheret]

I like how the DFW concept originally took off.
I'm also in favour of not fading things. This is less of a pain for myself as a routine WP user/developer. But I've seen lots and lots of customers shy away from this feature due to this inconsistency to the rest of how WP behaves.

My suggestion would be to leave the top bar opaque at all times and maybe only slightly fade it out but not 100%.
Another idea is to display the Post/Page title at all times either as an additional element or leave the currently used element in a fixed position and only scroll the content container.
Another option here is to leave the lowest used heeding visible while scrolling the content or have a table of contents view similar to the birds eye view of the document within "Sublime Text 2" for the Mac.

[iseulde]

First attempt: ​https://github.com/avryl/focus.

Just fades the surrounding UI when the editor is focussed. Fades everything back in when the mouse moves out of the editor area.

Please try and give feedback. :)

[iseulde]

• When you move focus with the keyboard, it should fade in when the focus is outside the editor area.

[iseulde]

Here's a GIF:

[nphaskins]

That is stinkin' awesome. I'd love to see that background fade to white. We could also fade out the adminbar?

[iseulde]

In previous versions of Focus, the surrounding UI faded in and out as you hovered in an out the editor area. Now it only fades out when you click on the editor or title. It fades back in when you either move the mouse out of the editor area for more than 20px or when you scroll up or down and the location of the mouse is outside the editor area.

The reason I decided to slide the menu is that there are two DIVs with a black background that partially overlay each other. Fading them both out would cause one part to get darker during the transition.

I'll now work on a different version that uses an overlay div. With that div we *can* fade the menu properly. It also ensures that everything other than the editor is faded (instead of targeting specific sections). This would also give us the ability to detect a touch on a touchscreen (e.g. Windows 8) and fade in.

Then I'll add another version that will fade everything out partially (a low opacity) and then completely after a few seconds.

[azaozz]

Yeah, overlay div (like DFW) and "fade to white" would probably feel best. The fade-in has to be pretty speedy too, perhaps something like 100-150ms. That might feel a bit too fast but one caveat with using overlay is that the components under it are not accessible/clickable while the fade-in is running.

[iseulde]

Not accessible, but that solves the touch problem. It's also best to fade in as quickly as possible. Fading out can still be slow.

I'm not sure if fading to white is best. With a grey background there is some contrast between that and the title/editor.

[nphaskins]

I think there's enough of a break with the border around the editor to define the editable areas, with the overlay done in white. Just feels a bit more clean than the default #f1 remaining in place.

[azaozz]

In [29835]:

Pin the admin menu on scrolling similarly to how the side metaboxes are pinned on the Edit Post screen, first run. See #29806.

[celloexpressions]

Replying to nphaskins:

I think there's enough of a break with the border around the editor to define the editable areas, with the overlay done in white. Just feels a bit more clean than the default #f1 remaining in place.

I find it way clearer and easier on the eyes with the #f1f1f1 background - having some contrast makes it a lot easier to look at. And it also makes it easier to focus on the editable portions of the screen, which seems to be the primary goal here.

[iseulde]

Replying to celloexpressions:

I find it way clearer and easier on the eyes with the #f1f1f1 background - having some contrast makes it a lot easier to look at. And it also makes it easier to focus on the editable portions of the screen, which seems to be the primary goal here.

I agree. It's also less of a change form the "default", so the transition is less likely to annoy people.

[iseulde]

@azaozz, [29835] seems to break z-indexes when the menu wrap has a fixed position. Setting the z-index of the wrap to 9999 instead of the submenus seems to fix it, but I'm not sure what the cause is.

[azaozz]

In [29841]:

Add default z-index to the admin menu, see #29806

[azaozz]

Replying to avryl:

Right. Most of the time the menu is position:fixed because of .sticky-menu which also adds z-index. May as well add the z-index as default.

[azaozz]

Been testing/playing with ​the plugin for some time, trying to "get a feel for it" when using it for extended periods of time:

• The menu sliding is quite distracting, even though it happens on hover/mouse move. This is something I really hate: any moving "things" while trying to concentrate reading, even worse when writing. IMHO fading out is a lot less distracting.

• I like the idea to have two steps fade-out and quite fast fade-in (about 150-200ms). The whole fade out could be:
  • Wait for 3 sec.
  • Fade to about 25%.
  • Wait for 2-3 sec. (can be longer).
  • Fade out completely.

• Hiding the Add Media and editor switching buttons on scrolling down seems good but makes it a bit uncomfortable when you need to use them. The direction you normally scroll while writing is down. You need to scroll a bit up to show them, that "looses" the current place on the screen where the caret is.

• A good enhancement would be to keep the caret a bit higher than the editor bottom (have some white space at the end). IMHO it's uncomfortable when typing near the bottom of the screen.

[adamsilverstein]

Tested the plugin a bit and will keep using and testing it, looks really good so far!

Agree with azaozz's feedback above - the menu sliding is distracting. The delay and bottom buffering also sound like good ideas.

[iseulde]

The plugin is now available in the wordpress.org directory: ​https://wordpress.org/plugins/focus/.

[lumpysimon]

Just testing the plugin: clicking in (or tabbing into) the title field works fine, but it's only working for the post content field when in Text mode, not in Visual mode (tested in Chrome and Firefox on Win7).

[iseulde]

Related: #21605.

[johnbillion]

@azaozz: RE [29835]. Can we get a body class added when the menu gets pinned, similar to the sticky-menu body class? pinned-menu would be a good name.

[johnrom]

I personally think this needs to be a button. I don't think that fading out critical navigation items while a user is typing is a good thing all of the time. I've often found myself needing to click "Pages" in the middle of typing content, and having to click out of focus mode and wait for the animation to finish would be a bit much work for a UI feature that I did not request at that moment. I think there are times when someone will want to focus, and others where they may want all of the information at their fingertips.

Plus, if you make this a button like full-screen is, then you won't have to worry about making the transitions as unobstrusive as possible, since the user will have requested the animation to happen. We can then take out of consideration the effect on users who did not request the effect, such as "this transition was too sudden / distracting"

Additionally, interrupting CTRL+D(istraction-free) may be a good balance for users that use the feature a lot, though this would block bookmarks. Shift + F11 may be better for users used to Sublime Text and is currently unused in Chrome, but the interruption of function keys is questionable in the browser.

For those who wish for the feature to happen automatically, I recommend adding a checkbox to Settings -> Writing, like "Enter Distraction-free mode on Editor Focus"

[iseulde]

It is a button now. But it's turned 'on' by default. 'on' is the wrong word really, it more like auto/off. We'll probably merge this with the editor scrolling setting.

I've often found myself needing to click "Pages" in the middle of typing content, and having to click out of focus mode and wait for the animation to finish would be a bit much work for a UI feature that I did not request at that moment.

It doesn't require a click to fade out (unless you're talking about touch?), just moving your mouse outside of the editor should trigger the fade in. And by the time you mouse reaches the button you want to click, the animation should be mostly done. Even if it's not 100% done, everything is clickable again form the moment the animation starts.

[azaozz]

Replying to johnbillion:

Can we get a body class added when the menu gets pinned, similar to the sticky-menu body class?

Sure but what would that be used for? There are some differences when the top or the bottom is pinned, so we probably will need two, perhaps: pinned-menu-top and pinned-menu-bottom.

[johnrom]

As long as it is an option in the Writing settings, I'm happy. It's a cool concept, and I'm definitely on board.

Alternatively, maybe add an admin notice when a user edits a post, "Would you like to enter Distraction Free mode / Focus mode when using the Editor? Yes / No", that saves user meta through an AJAX call, and goes away and never comes back once the user meta is saved. In this case, the checkbox should probably fall under the user's profile.

Again, this is all just my opinion, but for every UI feature there are those who like it, those who do not like it, and those who like it sometimes. I'm trying to appeal to those who will like it sometimes.

I'm not available to write anything this weekend, but if you'd like I can throw together the admin notices portion this week sometime.

[iseulde]

There wouldn't be a setting anywhere, just a button to switch between auto and off. The same button that is now used for DFW/fullscreen mode. It would be auto by default (but you can turn it off and it will stay off, based on the user), and we'll add a "new feature" pointer that can be dismissed next to the button.

The setting for editor scrolling that is now under screen settings could merge with this, but I can see why you would want this but not the other thing.

[azaozz]

Yeah, a toggle button that "remembers" state and a new-feature pointer are a good combination. Thinking that the checkbox for disabling editor scrolling (in Screen Options) should disable this too and hide the toggle button.

[khromov]

Happy to see this discussion!

I maintain a plugin called "Distraction Free Writing Mode Themes" which themes the DFWM.
Being able to scale away everything and being able to use dark color schemes like Monokai is much better than the default "burns your eyes"-white background of the current DFWM.

With my plugin, these kinds of DFWM looks are possible:
​https://wordpress.org/plugins/distraction-free-writing-mode-themes/screenshots/

I feel you would possibly alienate quite a few people by radically changing the DFWM look.

This mockup below is probably the best, because we would still be able to change the background color, but I would really like to have seen the tinymce bar disappear as standard behaviour (it could be enabled by pressing a button next to Add Media.) and making the admin bar visible only when user hovers at the top of the page.

I'd love to hear your thoughts on this.

[johnrom]

My thought was centered around the ability to manually enter DF mode, as that is how some would ideally use this feature. Sublime Text, for example, doesn't go into DF mode every time you start typing, but you can enter into it. The current method would leave me with only one other option -- off. Especially since I typically move the cursor out of a textarea in order for the cursor itself not to be a distraction while I'm typing. However, in this automatic mode it would appear that would exit DF mode. In the manual way, it would be the same button, replacing Enter with Exit.

Something like

Auto | Manual
[Enter Distraction-Free Mode] (button, visible when Manual is selected)

Maybe there's a better way, but I'd love to see an on-demand mode incorporated.

[wonderboymusic]

I am going to strongly object to this being on ("auto") by default - while I'm sure some bloggers *might* like it, I can guarantee that no one who produces Dealbook is going to want anything to do with it.

I have love and respect for everyone who is working on this - I still severely dislike the fading.

[iseulde]

Turning it off by default would make it much harder to discover than turning it off when it's on auto, imho.

So you're okay with this as long as it's not on by default? I mean, you're not strongly opposing the idea in general (and as a replacement for DFW)?
Is there any way you can think of that could improve it?

Thanks a lot for the feedback! :)

[iseulde]

It'd be great if others could raise their concerns/thoughts here.

[nphaskins]

I like the direction that this is headed, but to be completely honest I feel there's too much movement as compared to the current implementation of DFW. At minimum everything should fade out in one fluid motion. I'd also like to find a way to do this sans user actions. I think "clicking into the editor which triggers this" would be considered unexpected behavior to new WordPress users.

That is unless DFW was the default view when the edit post screen is loaded.

I realize that's a bit of a drastic departure from the traditional edit-post screen, but I don't think it would be such unexpected behavior, and also wouldn't be tied to a specific user action.

[DrewAPicture]

Replying to avryl:

Turning it off by default would make it much harder to discover than turning it off when it's on auto, imho.

So you're okay with this as long as it's not on by default? I mean, you're not strongly opposing the idea in general (and as a replacement for DFW)?

It's been said before that if the inclination is to disable a new feature by default, perhaps it's not worth the effort of adding that feature in the first place. I think Scott (@wonderboymusic) raises a valid concern about a degraded experience in the editor should the fading be included.

I tend to agree with that sentiment. I've never been a fan of the fading in DFW, and would not like to see it come to the default editor either.

[iseulde]

... but to be completely honest I feel there's too much movement as compared to the current implementation of DFW. At minimum everything should fade out in one fluid motion.

I don't think the current transition from the default editor to DFW is fluid. :)

It's been said before that if the inclination is to disable a new feature by default, perhaps it's not worth the effort of adding that feature in the first place.

It's more about not setting it to "auto" by default. This is a replacement for DFW too, which is off by default.

[DrewAPicture]

Replying to avryl:

It's been said before that if the inclination is to disable a new feature by default, perhaps it's not worth the effort of adding that feature in the first place.

It's more about not setting it to "auto" by default. This is a replacement for DFW too, which is off by default.

DFW itself is not disabled, it can be toggled on with all of the features that come along with it, so that's really not a fair comparison.

This really comes down to decisions not options, IMO. Doing something "automatically" inherently implies that it will be enabled by default with an option to disable it. So if we're inclined to add the feature but disable its automatic-ness, then I question whether this is something we should be adding.

[DrewAPicture]

I like shiny features as much as the next person, but I think we need to consider whether this will actually improve the editing experience for 80% of the users. Doing user tests or showing user test data that this improves the experience would go a long way to convincing me and others that this serves a purpose other than consolidating one editing experience into another -- the former being something that's not the default editing experience in the first place.

[iseulde]

So can this? It can be toggled on and off. Yes, if it's on, it's not always faded, we do it automatically. I see this as an improvement to DFW, which is gentle enough that we can *consider* turning it on by default.

I'm totally up for user tests! How can we make that happen?

[afercia]

Replying to azaozz:

In [29835]:

Pin the admin menu on scrolling similarly to how the side metaboxes are pinned on the Edit Post screen, first run.

Looks like the pinned admin menu works fine on hover

but not so fine on focus (notice focus is on the "Permalinks" settings link):

When shrinking/resizing the browser window height, it gets a little crazy:

[azaozz]

In 29898:

Admin menu:

• Fix pinning after resizing the window.
• Merge the two DOM ready callbacks in common.js
• Fix the submenus position adjustment on focus.

See #29806

[azaozz]

Replying to afercia:

[29898] should fix all of these (and more). The pinning is disabled in iOS. Because of position:fixed when the keyboard is open, the previous behavior is better there.

Needs testing on an Android tablet (preferably with larger screen resolution).

[azaozz]

In 29978:

Admin menu:

• Fix scrolling the pinned menu with a mouse wheel.
• Fix pinning when the menu is only slightly taller than the viewport.
• Disable pinning on IE8, updating CSS top makes it jump when scrolling with a mouse wheel.

See #29806

[iseulde]

I know this is not done yet.
Most of editor expand is the same, it's just indented.
​https://github.com/avryl/focus/commits/master/editor-expand.js

[usability.idealist]

BTW: A forced "slide out" of the admin sidebar menu would also wreck extreme havoc with a11y ^_

cu, w0lf.

[markjaquith]

The "Save" button hijacking needs to go. It doesn't work right, and it’s a huge change that shouldn't be smuggled in with this.

[iseulde]

Replying to markjaquith:

The "Save" button hijacking needs to go. It doesn't work right, and it’s a huge change that shouldn't be smuggled in with this.

ok

[iseulde]

Last patch just removes the dfw button from the text editor for mobile.
​https://github.com/avryl/focus/commit/a24d301e6ef6bc3d419933eebd1ad3282c70e19c

[markjaquith]

In 30338:

Introduce Distraction-Free Writing v2, a re-think of DFW that uses the main editor instance

• the "DFW" button is now an auto/off toggle
• defaulting to auto during beta, decide later for release
• "auto" means that DFW gets enabled as you start typing in editor
• tabbing and mousing out will bring the full interface back
• there is a slight grace period during which your mouse can quickly return

Feature plugin work happened here: ​https://github.com/avryl/focus

props avryl, azaozz, Michael Arestad
fixes #29806

[Otto42]

Bug report (unsure whether to make a new ticket for something so minor):

When disabling the DFW via this code in a plugin:

add_filter('wp_editor_expand','__return_false');

The button for DFW is removed from the Visual editor, but remains in place (but non-functional) on the Text editor tab.

[iseulde]

Patch fixes issue above. Ideally we need to set the wp-editor-expand class on wp-editor-wrap, not postdivrich, so a variable can be set and scripts can be loaded form within the editor class. That's also where other classes such as has-dfw and tmce/html-active are set. Only downside is a more complex CSS rule. :)

[iseulde]

Remaining issues:

• add_filter('wp_editor_expand','__return_false'); does not remove quicktags button. See comment above.
• Shall we remove old dfw completely? See #feature-focus conversations. If not we need to make sure new dfw can be replaced with old dfw. I'm in favour of removing it completely. A plugin can copy the files from 4.0 and improve the code.
• There's a weird bug in Safari when the window height is smaller than the menu content. Everything fades in as soon as you start scrolling. Maybe related to the menu?
• The dfw button for quicktags lacks style for the disabled state.

[iseulde]

Oh, and we need to add a pointer.

[johnbillion]

RTL bug: #30356

(PS we should be using separate tickets for new issues from now on)

[Clorith]

So a little bit late to the party with this remark (sorry! I know we're in beta and all)... but the current icon tells me "full screen", which was technically right for the old DFW format, but not any more.

I must admit I don't have any amazing ideas for a new icon off the top of my head, but the current one feels wrong never the less.