WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#29806 closed task (blessed) (fixed)

Focus (continued)

Reported by: iseulde Owned by: markjaquith
Milestone: 4.1 Priority: normal
Severity: normal Version:
Component: Editor Keywords: ux-feedback ui-feedback has-patch
Focuses: ui, javascript, administration Cc:

Description

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.
...

Attachments (9)

Screen Shot 2014-09-30 at 00.56.58.png (126.2 KB) - added by iseulde 5 years ago.
Screen Shot 2014-10-05 at 18.29.09.png (16.2 KB) - added by iseulde 5 years ago.
29806.patch (70.0 KB) - added by iseulde 4 years ago.
29806.2.patch (63.1 KB) - added by iseulde 4 years ago.
29806.3.patch (62.8 KB) - added by iseulde 4 years ago.
29806.4.patch (64.8 KB) - added by iseulde 4 years ago.
29806.5.patch (64.8 KB) - added by iseulde 4 years ago.
29806.6.patch (65.3 KB) - added by iseulde 4 years ago.
29806.7.patch (7.0 KB) - added by iseulde 4 years ago.

Download all attachments as: .zip

Change History (76)

#1 follow-up: @iseulde
5 years ago

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.

#2 @iseulde
5 years ago

  • Keywords ux-feedback ui-feedback added

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

#3 in reply to: ↑ 1 @azaozz
5 years ago

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 :)

#4 @azaozz
5 years ago

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.

#5 follow-up: @iseulde
5 years ago

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. :)

#6 in reply to: ↑ 5 @azaozz
5 years ago

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.

Last edited 5 years ago by azaozz (previous) (diff)

This ticket was mentioned in IRC in #wordpress-dev by avryl. View the logs.


5 years ago

#8 @mark.cheret
5 years ago

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.

#9 @iseulde
5 years ago

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. :)

#10 @iseulde
5 years ago

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

#11 @iseulde
5 years ago

Here's a GIF:

https://cldup.com/ODhD_BFeHY.gif

#12 @nphaskins
5 years ago

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

#13 @iseulde
5 years ago

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.

#14 @azaozz
5 years ago

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.

#15 @iseulde
5 years ago

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.

#16 follow-up: @nphaskins
5 years ago

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.

http://f.cl.ly/items/3o1C3x3O150E2k0z2i3N/Image%202014-10-04%20at%207.47.42%20AM.png

#17 follow-up: @azaozz
5 years ago

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.

#18 in reply to: ↑ 16 ; follow-up: @celloexpressions
5 years ago

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.

#19 in reply to: ↑ 18 @iseulde
5 years ago

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.

#20 follow-up: @iseulde
5 years ago

@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.

#21 @azaozz
5 years ago

In [29841]:

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

#22 in reply to: ↑ 20 @azaozz
5 years ago

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.

Last edited 5 years ago by azaozz (previous) (diff)

#23 @azaozz
5 years ago

Been testing/playing with the plugin, 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.
Last edited 5 years ago by azaozz (previous) (diff)

#24 @azaozz
5 years ago

  • Type changed from enhancement to task (blessed)

This ticket was mentioned in IRC in #wordpress-ui by _Redd. View the logs.


5 years ago

#26 @adamsilverstein
5 years ago

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.

#27 @iseulde
5 years ago

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

#28 @lumpysimon
5 years ago

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).

#29 @iseulde
5 years ago

Related: #21605.

#30 follow-up: @johnbillion
5 years ago

@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.

#31 @johnrom
5 years ago

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"

#32 @iseulde
5 years ago

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.

#33 in reply to: ↑ 30 @azaozz
5 years ago

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.

#34 @johnrom
5 years ago

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.

#35 @iseulde
5 years ago

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.

#36 @azaozz
5 years ago

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.

#37 @khromov
5 years ago

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.

https://dl.dropboxusercontent.com/u/2758854/ODhD_BFeHY.gif

I'd love to hear your thoughts on this.

Last edited 5 years ago by khromov (previous) (diff)

#38 @johnrom
5 years ago

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.

#39 @wonderboymusic
5 years ago

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.

#40 follow-up: @iseulde
5 years ago

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! :)

#41 @iseulde
5 years ago

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

#42 @nphaskins
5 years ago

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.

#43 in reply to: ↑ 40 @DrewAPicture
5 years ago

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.

#44 follow-ups: @iseulde
5 years ago

... 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.

#45 in reply to: ↑ 44 @DrewAPicture
5 years ago

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.

#46 in reply to: ↑ 44 @DrewAPicture
5 years ago

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.

#47 @iseulde
5 years ago

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?

#48 in reply to: ↑ 17 ; follow-up: @afercia
5 years ago

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
https://cldup.com/0dWY7xn5fF.png

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

https://cldup.com/8l0q-brPVP.png

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

https://cldup.com/WtTSPl3BUt.png

#49 @azaozz
5 years ago

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

#50 in reply to: ↑ 48 @azaozz
5 years ago

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).

#51 @azaozz
5 years ago

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
4 years ago

#52 @iseulde
4 years ago

  • Keywords has-patch added

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

This ticket was mentioned in Slack in #feature-focus by janneke. View the logs.


4 years ago

@iseulde
4 years ago

@iseulde
4 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


4 years ago

#55 @usability.idealist
4 years ago

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

cu, w0lf.

This ticket was mentioned in Slack in #accessibility by ginsterbusch. View the logs.


4 years ago

This ticket was mentioned in Slack in #accessibility by ginsterbusch. View the logs.


4 years ago

#58 follow-up: @markjaquith
4 years ago

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.

#59 in reply to: ↑ 58 @iseulde
4 years ago

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
4 years ago

@iseulde
4 years ago

#60 @iseulde
4 years ago

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

@iseulde
4 years ago

#61 @markjaquith
4 years ago

  • Owner set to markjaquith
  • Resolution set to fixed
  • Status changed from new to closed

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

#62 @Otto42
4 years ago

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
4 years ago

#63 @iseulde
4 years ago

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. :)

#64 @iseulde
4 years ago

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.

#65 @iseulde
4 years ago

Oh, and we need to add a pointer.

#66 @johnbillion
4 years ago

RTL bug: #30356

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

#67 @Clorith
4 years ago

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.

Note: See TracTickets for help on using tickets.