Editor: updating layout and design #11536

mtias · 2017-02-22T18:51:47Z

This work seeks to simplify the interface of the editor, provide a "distraction free" mode by toggling the sidebar off, clarify some of the UI elements around statuses, and overall reduction of the visual weight of the editor favoring the content:

(Snapshot of the editor before this PR)

To-do:

Fix all interactions in the status module.
Move visibility to status if possible.
Move trash to status if possible. 1fd65d5
Find a placement for drafts shortcut.
Hook up sidebar-close action to the x. 85da460
Use translateX for inner content transition when opening sidebar.
Remember state of the sidebar in the editor, and show it open by default. db3a6f2
Add compact version of <Site>.

matticbot · 2017-02-22T18:51:48Z

Test live: https://calypso.live/posts?branch=try/edito-chrome-update

a8ci18n · 2017-02-22T18:56:17Z

client/post-editor/editor-status-label/index.jsx

@@ -125,7 +125,7 @@ export default React.createClass( {
 				} );
 				break;
 			case 'draft':
-				label = this.translate( '{{strong}}Draft saved{{/strong}} %(relativeTimeFromNow)s', {
+				label = this.translate( '{{strong}}Saved{{/strong}} %(relativeTimeFromNow)s', {


Hi! I've found a possible matching string that has already been translated 22 times:
translate( '{{strong}}Scheduled{{/strong}} %(relativeTimeFromNow)s' ) ES Score: 19.25
See 1 additional suggestion in the PR translation status page

Help me improve these suggestions: react with 👎 if the suggestion doesn't make any sense, or with 👍 if it's a particularly good one (even if not implemented).

timmyc · 2017-02-22T22:30:13Z

Wow! This is quite an impressive change. I'm testing things out now - hoping we can get lots of 👀 and devices on this PR since it is a big change. I'm going to just drop notes here as I find them in-lieu of doing one big comment at the end.

First up - When the chrome sidebar is exposed, an 'X' is shown which I assumed would toggle the sidebar to a closed state. Instead the draft drawer is exposed.

The author selector also feels kind of crowded near the top. The auto-save indicator, and sticky, visibility and trash gridicons appear to have a uniform padding between them and the top of the pane, but the user gravatar is almost touching the top:

timmyc · 2017-02-23T00:01:22Z

In b125814 I updated the location and featured media buttons to be compact to match the revisions button in the "Status" accordion - it looks better to me so I figured I'd push it up here to see what you all thought.

mtias · 2017-02-23T11:07:24Z

Thanks @timmyc, very helpful!

When the chrome sidebar is exposed, an 'X' is shown which I assumed would toggle the sidebar to a closed state.

Your assumption is right, it's the missing task above "hook up the sidebar close button". The proper way would be to have an action in state/ui to toggleBetweenSidebarAndContent, or focusSidebar, focusContent.

The author selector also feels kind of crowded near the top.

I've been going back and forth with the values for the inner margin of the content next to the fixed header. For some reason it varies depending on the site you are in or content you are editing.

The category names themselves seem quite large compared to the rest of the text in the accordion.

Yes, we need to lower the font-size of the large version of the category selector. We use is-compact to distinguish between the version with few categories and the version with a lot of categories, and that isn't great. We should have is-large for that purpose and is-compact just for visual adaptation that applies across.

Example: the category selector when you are creating a new category is fine to have bigger fonts, but the ones in the accordion should match the smaller font.

Might be nice to come up with a standard "sub heading" font size and weight here that could be used across the accordions.

There's an editor-drawer__label-text class for this. But this shows the problem of relying on classes—we should have a sub-component of editor drawer that is editor-drawing/label or heading and use that consistently.

Also some funky-ness going on with the error messaging.

I switched the error message to use a compact notice and the proper notice-action sub-component. It seems we've had some regressions in how we present the action there. cc @rickybanister

The "Get current location" button and "Search" placeholder text both do feel quite large compared to the balance of the font sizes.

Agreed, didn't get to them yet.

Hovering over the clock gridicon opens a tooltip which displays the timezone, currently the tooltip is not oriented properly.

We need to adjust a bunch of the tooltips to go to the left. Also the schedule popover is displayed correctly but it's set to open to the right.

On smaller viewports, the publish button is hidden:

Smaller view needs a bunch of work at the code level because of the recent refactor we did to the mobile view :)

The changes now should be aligning the expectations better (top level bar that contains site and main actions, etc).

mtias · 2017-02-23T11:29:46Z

Updated the core Search component to support a compact version:

rickybanister · 2017-02-23T15:32:16Z

I'll try to take a look, I think my narrow styles for regular notices bled into the compact one. Not sure how easy it will be to sequester that stuff.

folletto · 2017-02-23T15:40:44Z

After a great round of iterations and brainstorming with @mtias and @jasmussen we polished a few rough edges with the mock above.

Guiding principles:

A user that wants just to write can just write immersively and publish. Boom. No more sidebar.
An advanced user can keep the sidebar open all the times.
Anywhere in between the sidebar can toggle open and closed.
Clarifying and cleaning some options we got feedback they are quite obscure.

So here a quick rundown of the changes:

"Publish" moved to a compact version to align better.
Compact version of the site badge, so we get a slimmer tab bar that aligns with the standard height.
"Post" still opens the sidebar. Since it's a toggle, we drop the ×
Most of the in-page elements are moved into the sidebar since they are for more advanced use, and will benefit from the additional space for labels.
No change from the initial PR, but for clarity: the "Ground Control" component gets the same treatment, making it explicit and avoiding the obscurity of the cog near the time.
Author got centered as the "cog" tab acts as an indicator now.
Status is now in the bottom-left corner.

There isn't a specific mobile mock, but the overall structure isn't radically different from what we have now, thus we can reuse the same idea of the icons without label in the same way across desktop and mobile sizes.

shaunandrews · 2017-02-23T16:04:50Z

Seeing the sidebar on the right was a little shocking at first. But I'm sure I'll get used to it after a day or two.

This proximity of "Post" and "Publish" caught my eye — they're almost synonyms, and putting the so close together made me question which one is which. -- If I open and close the sidebar, then click the back arrow below My Sites, it doesn't do anything. --

There's been a lot of work around getting a consistent and always available help button in Calypso. Its nice to see it still in the sidebar, but now its on the right — and its hidden by default. Any thoughts on trying to keep it always visible *or* on the left?

rickybanister · 2017-02-23T16:07:54Z

I like @shaunandrews's idea about the help button. At first I felt like its location made sense (mirrored from the regular sidebar), but I could see it on top of the white 'paper' on the left in its normal location.

jasmussen · 2017-02-23T16:11:04Z

Seeing the sidebar on the right was a little shocking at first. But I'm sure I'll get used to it after a day or two.

❤️

This can also be seen as a chance to converge a little bit with core:

davewhitley · 2017-02-23T16:22:55Z

Obviously still really early, but I really like the direction.

I would consider having one of the accordions already expanded (the top one) when the user opens the settings sidebar. It would reveal the most important info in the top accordion while reducing a click to see it.

folletto · 2017-02-23T16:28:13Z

Any thoughts on trying to keep it always visible or on the left?

Maybe when the sidebar is closed the ? icon can stay on screen?

mtias · 2017-02-23T17:53:35Z

This proximity of "Post" and "Publish" caught my eye — they're almost synonyms, and putting the so close together made me question which one is which

The "post" is meant to be the noun — it changes based on post type (page, post, portfolio). Post is not a great noun, though.

mapk · 2017-02-23T19:22:41Z

This proximity of "Post" and "Publish" caught my eye — they're almost synonyms, and putting the so close together made me question which one is which

The "post" is meant to be the noun — it changes based on post type (page, post, portfolio). Post is not a great noun, though.

This was my initial struggle as well. I was hesitant to click "Post" in fear that it would post my draft. It wasn't until I realized I was on my test site, that I said, "What the hell" and clicked it.

mapk · 2017-02-23T19:26:26Z

I like moving the sidebar to the right. As @jasmussen points out, it's aligning nicely with the direction in Core. It's also fairly predictable that left sidebars are often for navigation, while right sidebars are used for in-page editing or other tasks related to the content.

supernovia · 2017-02-23T20:06:33Z

Ahhh I really don't want to sound like a naysayer. I haven't been following the back story on why we're moving things around, but I do follow users a lot. Based on my interactions with them:

I appreciate that the post options are on the same side as they are in wp-admin, but users who haven't been using wp-admin (that's most of our users, since we haven't been showing wp-admin links to new users for a while now) are used to having things on the left. I know for many of us it's pretty easy to look around on the screen and find things that have moved. But in my workshops I've noticed less techy people rely more on memory, or even on steps they've written down, instead of intuition. For them, major moves can be debilitating.
In feedback on other projects, users have complained of having to click around more to get what they need, when they used to be able to just see the options in front of them. Also from a support standpoint, it's an extra click we have to step people through, not to mention lots of docs and videos that will definitely need an update.

Personally I'd rather see the sidebar available (preferably on the left) by default, but give folks an option to hide it. A little collapse button like the one we have in the customizer might work. :)

timmyc · 2017-02-23T20:10:55Z

Great to see all the discussion here, and a large number of design 👀 on this! In particular, @folletto thanks for the voicing the why behind these changes in the iteration design:

The driving idea of this concept is to have an editor that is minimal and allows users to quickly write and post, in an immersive way.

I'm still a bit concerned about how this change will be accepted by wpcom users. Recent experiences with editor changes ( i/o editor, and calypso editor launch - though that went much smoother ), always cause me to pause when considering a visual overhaul to this key flow for our users.

Inevitably, there will likely be a group of users that will be disturbed by any change ( Moving 🧀 sort of thing ) - but I'm wondering if this change can be communicated/framed for wpcom users as a positive enhancment for the editing experience.

One old issue that @jasmussen opened after the Calypso editor was launched could possibly be addressed here too #1265 - maybe expanding the editor area given the increased horizontal space.

jasmussen · 2017-02-24T08:44:38Z

This proximity of "Post" and "Publish" caught my eye — they're almost synonyms, and putting the so close together made me question which one is which. -- If I open and close the sidebar, then click the back arrow below My Sites, it doesn't do anything. --

This was my initial struggle as well. I was hesitant to click "Post" in fear that it would post my draft. It wasn't until I realized I was on my test site, that I said, "What the hell" and clicked it.

I lost some sleep over this one.

The button was initially labelled "Document", but in the long game, we're thinking about an inspector that can take up this space. So the more contextual the sidebar is to the document you're looking at, the better. And so by being labelled Post when you're editing a post, or Page when you're editing that, the contents of the sidebar become 100% contextual. When you then select a block, we would replace the contents of the sidebar with controls for that specific block, and there would be a breadcrumb in the top:

That's still speculative, but I like it showing the document type moreso than just saying "Document".

Any other ideas?

I would consider having one of the accordions already expanded (the top one) when the user opens the settings sidebar. It would reveal the most important info in the top accordion while reducing a click to see it.

Agreed. In addition to this, can we cache which accordions the user opens themselves so they stay open?

I appreciate that the post options are on the same side as they are in wp-admin, but users who haven't been using wp-admin (that's most of our users, since we haven't been showing wp-admin links to new users for a while now) are used to having things on the left. I know for many of us it's pretty easy to look around on the screen and find things that have moved. But in my workshops I've noticed less techy people rely more on memory, or even on steps they've written down, instead of intuition. For them, major moves can be debilitating.

In feedback on other projects, users have complained of having to click around more to get what they need, when they used to be able to just see the options in front of them. Also from a support standpoint, it's an extra click we have to step people through, not to mention lots of docs and videos that will definitely need an update.

I'm still a bit concerned about how this change will be accepted by wpcom users. Recent experiences with editor changes ( i/o editor, and calypso editor launch - though that went much smoother ), always cause me to pause when considering a visual overhaul to this key flow for our users.

Responding to these three as a group, as they all touch a little on the same — "moved my cheese" and "options shown by default".

Sidebar open by default

We can simply show the sidebar as being open by default — the ability to toggle off the sidebar is then simply the immersive mode. Any thoughts on this? CC: @folletto @mtias

Sidebar on the right

Showing the metadata on the right makes sense from a UX perspective — we read from the left to the right, and so it makes sense in most of Calypso that navigation is to the left, and then the content. On the Post editing page, it makes the most sense that meta data, which is a subset of the content, is on the right.

Moved my cheese

It seems true that users are likely going to need some time getting used to the change, no matter what we do and no matter how good a change it is, which Timmy also referred to.

There's an old article about design changes and how to best do them. The most relevant bits here:

[…] those complaining about a change are the ones who know exactly what’s being changed, and how everything works before and after the change. This means that the people criticizing the change are actually not going to be confused by the new interface. So why the negative feedback?

It’s a case of the user’s power being seized by the designer, albeit a very tiny amount. People spent the time learning your interface — they’ve invested this time — and as a result they’ve gained a little power in the world — that is, they’ve gained the ability to better control their environment. With every interface change, their level of control gets pushed back a little, and they have to reorient themselves around the new design. But what’s worse is probably not that people need to spend time learning the new interface — this probably won’t take long — but that they can feel power being taken away from them.

The best way I can think of, to alleviate this, is to have both editors running for a period. The new editor then has a button that says "Temporarily switch back to the old editor", or something in that vein. Is this technically possible at all? Is this something we want to do?

jasmussen · 2017-02-24T09:19:40Z

I found this screenshot of what the editor looked like, when we launched the desktop app.

We've already come a long way.

folletto · 2017-02-24T11:19:01Z

We can simply show the sidebar as being open by default — the ability to toggle off the sidebar is then simply the immersive mode. Any thoughts on this?

Yes. I think that since the approach we have is a toggle, we're very very flexible on taking this decision as it's just how we set the initial state.

That said, I'd probably start with the open sidebar, as it's the current default for both Calypso and WP Admin. :)

That's still speculative, but I like it showing the document type moreso than just saying "Document".
Any other ideas?

...what about the boring but clear options like: "Settings" or "Inspect"?

moved my cheese

It think it's a fair concern, however that's a concern with any design change. This design specifically has some goals that achieves, not just having a cleaner interface, but also better labeling and better guidance (I recall issues with the hidden cog settings and sticky).

I'll try to be even more specific here on the benefits of this design:

Distraction free mode — without any special control for that, huge win
The ground control cog removal — now we have an accordion with a label, no more hunting for revisions, date, sticky, review options.
Less in-page mystery — currently we have a top corner with three "mystery" icons, of which probably only trash is somehow clear. Moving these into the sidebar is another win. Every setting is now in the sidebar!
Aligned with Core — both today's and tomorrow's WordPress is closer in terms of layout. This doesn't matter for .com only users, but creates better integration for the ones that instead are using both.
Closer to mobile — Now the desktop and mobile layouts are far more similar. A minor thing, but worth noting.

Also I know it matters little in terms cheese moved, but the right sidebar is also better in terms of visual hierarchy, as the focus is shifted more on the content.

In the future we'll also move away the TinyMCE toolbar that we're currently stuck with (not really stuck, just requires a lot of work to be independennt) and that will make the main editing area really clutter free. :)

I hope it helps. :)

mtias · 2017-02-24T12:51:13Z

The right sidebar was on the original scope for the Calypso editor if we could split the site / publish combo card, so this is just the culmination of that effort. We have done a few significant iterations already, like the app-style design going full width and white for the whole content area that @jasmussen mentioned.

supernovia · 2017-03-09T23:42:04Z

I just did some testing on HTML being stripped after reading a comment from a rather distraught user: "Can you not remove all the evil and wickedness from the visual editor?"

The new chrome has the same issue.

To test:

Head to the HTML tab, add some html (special characters for example or a nonbreaking space)
click visual
Go back to HTML, notice the HTML is selectively gone

timmyc · 2017-03-10T00:24:22Z

@supernovia by chance did you test the same flow in wp-admin?

timmyc · 2017-03-10T00:51:13Z

@supernovia I confirmed the same thing happens in wp-admin and a .org install - so should likely be raised upstream in .org instead of calypso.

alisterscott · 2017-03-10T07:00:32Z

Minor, on 13" MBP width the saved status cuts-off the right hand side:

alisterscott · 2017-03-15T23:16:37Z

I noticed last night that on Safari in mobile view the settings sections become inaccessible as you open them with this redesign. Raised here: #12212

lancewillett · 2017-06-07T21:19:07Z

I raised a new bug for small screens: #14882 — I think it could affect anyone using the Press This bookmarklet.

@mtias

**Simplify step**: the `EditorStatusLabel` is only a shadow of its former self, showing just a simple label that's not interactive at all. It used to be more than that: it was clickable and could open a popover with post status. That was changed by @mtias in #11536, where he moved the post status to the sidebar accordion. This PR removes the dead code related to `onClick` and `advancedStatus` props, which are no longer used. **Reduxify step**: retrieve the edited post (the saved version, not the modified one) from Redux instead of passing the `savedPost` prop from Flux store.

@mtias

**Simplify step**: the `EditorStatusLabel` is only a shadow of its former self, showing just a simple label that's not interactive at all. It used to be more than that: it was clickable and could open a popover with post status. That was changed by @mtias in #11536, where he moved the post status to the sidebar accordion. This PR removes the dead code related to `onClick` and `advancedStatus` props, which are no longer used. **Reduxify step**: retrieve the edited post (the saved version, not the modified one) from Redux instead of passing the `savedPost` prop from Flux store.

It was never visible anyway because of `showIcon=false` prop and `display: none` style. It was added a long time ago in #8679. You can see on the screenshots that the editor looked very differently back then. Then the editor was redesigned to the current look in #11536, where `PostStatus` was hidden, but not completely removed.

…ks (#30963) * PostTime block: migrate CSS to webpack, use withLocalizedMoment * Post Status block: migrate CSS and fix ESLint warning in the docs example * Remove usage of PostStatus block in EditorPostType It was never visible anyway because of `showIcon=false` prop and `display: none` style. It was added a long time ago in #8679. You can see on the screenshots that the editor looked very differently back then. Then the editor was redesigned to the current look in #11536, where `PostStatus` was hidden, but not completely removed.

mtias added [Feature] Post/Page Editor The editor for editing posts and pages. [Status] In Progress labels Feb 22, 2017

mtias requested review from jasmussen and aduth February 22, 2017 18:51

matticbot added the [Size] XL Probably needs to be broken down into multiple smaller issues label Feb 22, 2017

a8ci18n reviewed Feb 22, 2017

View reviewed changes

matticbot added the [Size] XL Probably needs to be broken down into multiple smaller issues label Feb 23, 2017

matticbot added the [Size] XL Probably needs to be broken down into multiple smaller issues label Feb 24, 2017

timmyc mentioned this pull request Mar 9, 2017

Editor: Taxonomy Sidebar Visually Broken in RTL #11954

Closed

mtias added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Mar 9, 2017

mtias merged commit 71ec9bc into master Mar 10, 2017

matticbot removed the [Status] Ready to Merge label Mar 10, 2017

marekhrabe mentioned this pull request Mar 10, 2017

Editor: Disabled preview button still handles clicks #11992

Closed

jasmussen mentioned this pull request Mar 10, 2017

Editor: Various improvements to the new editor #11996

Closed

7 tasks

aduth mentioned this pull request Mar 10, 2017

Editor: Hide toolbar borders dependent on sidebar presence #12004

Merged

timmyc mentioned this pull request Mar 14, 2017

Editor: Fix footer styling issues #12078

Merged

timmyc mentioned this pull request Mar 16, 2017

Editor: blinking trash Icon is a bit confusing #1646

Closed

nb deleted the try/edito-chrome-update branch March 17, 2017 10:14

timmyc mentioned this pull request Mar 17, 2017

Editor: Not able to edit passwords on password protected posts #12276

Closed

lancewillett mentioned this pull request May 15, 2017

Editor: Press This missing wp-admin press-this features #1552

Open

3 tasks

lancewillett mentioned this pull request Jun 7, 2017

Editor: opening in small window from Press This broken in recent layout design change #14882

Closed

mcsf mentioned this pull request Aug 23, 2017

Editor: Hide bottom status label when revisions open #17468

Merged

michaeldcain mentioned this pull request Nov 8, 2017

Editor: Sticky Button is seemingly hidden #18217

Closed

jsnajdr mentioned this pull request May 9, 2018

Post Editor: remove action bar component from sidebar #24754

Merged

jsnajdr mentioned this pull request May 15, 2018

Editor Status Label: Reduxify and simplify #24874

Merged

jsnajdr mentioned this pull request Feb 22, 2019

Migrate CSS of PostTime and PostStatus blocks to CSS, plus a few tweaks #30963

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editor: updating layout and design #11536

Editor: updating layout and design #11536

mtias commented Feb 22, 2017 •

edited by jasmussen

Loading

matticbot commented Feb 22, 2017 •

edited by folletto

Loading

a8ci18n Feb 22, 2017

timmyc commented Feb 22, 2017

timmyc commented Feb 23, 2017 •

edited

Loading

mtias commented Feb 23, 2017

mtias commented Feb 23, 2017

rickybanister commented Feb 23, 2017

folletto commented Feb 23, 2017

shaunandrews commented Feb 23, 2017 •

edited

Loading

rickybanister commented Feb 23, 2017

jasmussen commented Feb 23, 2017

davewhitley commented Feb 23, 2017 •

edited

Loading

folletto commented Feb 23, 2017

mtias commented Feb 23, 2017

mapk commented Feb 23, 2017

mapk commented Feb 23, 2017

supernovia commented Feb 23, 2017 •

edited

Loading

timmyc commented Feb 23, 2017

jasmussen commented Feb 24, 2017

jasmussen commented Feb 24, 2017

folletto commented Feb 24, 2017 •

edited

Loading

mtias commented Feb 24, 2017

supernovia commented Mar 9, 2017 •

edited

Loading

timmyc commented Mar 10, 2017

timmyc commented Mar 10, 2017

alisterscott commented Mar 10, 2017

alisterscott commented Mar 15, 2017

lancewillett commented Jun 7, 2017

Editor: updating layout and design #11536

Editor: updating layout and design #11536

Conversation

mtias commented Feb 22, 2017 • edited by jasmussen Loading

To-do:

matticbot commented Feb 22, 2017 • edited by folletto Loading

a8ci18n Feb 22, 2017

Choose a reason for hiding this comment

timmyc commented Feb 22, 2017

timmyc commented Feb 23, 2017 • edited Loading

mtias commented Feb 23, 2017

mtias commented Feb 23, 2017

rickybanister commented Feb 23, 2017

folletto commented Feb 23, 2017

shaunandrews commented Feb 23, 2017 • edited Loading

Seeing the sidebar on the right was a little shocking at first. But I'm sure I'll get used to it after a day or two.

rickybanister commented Feb 23, 2017

jasmussen commented Feb 23, 2017

davewhitley commented Feb 23, 2017 • edited Loading

folletto commented Feb 23, 2017

mtias commented Feb 23, 2017

mapk commented Feb 23, 2017

mapk commented Feb 23, 2017

supernovia commented Feb 23, 2017 • edited Loading

timmyc commented Feb 23, 2017

jasmussen commented Feb 24, 2017

jasmussen commented Feb 24, 2017

folletto commented Feb 24, 2017 • edited Loading

mtias commented Feb 24, 2017

supernovia commented Mar 9, 2017 • edited Loading

timmyc commented Mar 10, 2017

timmyc commented Mar 10, 2017

alisterscott commented Mar 10, 2017

alisterscott commented Mar 15, 2017

lancewillett commented Jun 7, 2017

mtias commented Feb 22, 2017 •

edited by jasmussen

Loading

matticbot commented Feb 22, 2017 •

edited by folletto

Loading

timmyc commented Feb 23, 2017 •

edited

Loading

shaunandrews commented Feb 23, 2017 •

edited

Loading

davewhitley commented Feb 23, 2017 •

edited

Loading

supernovia commented Feb 23, 2017 •

edited

Loading

folletto commented Feb 24, 2017 •

edited

Loading

supernovia commented Mar 9, 2017 •

edited

Loading