Skip to content
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

Chrome: Add a publish dropdown v1 #2887

Merged
merged 3 commits into from
Oct 16, 2017
Merged

Chrome: Add a publish dropdown v1 #2887

merged 3 commits into from
Oct 16, 2017

Conversation

youknowriad
Copy link
Contributor

This PR tries to implement the v1 of the publish dropdown closes #708
It is intended as a PR to try the technical viability and discuss this, rather than the final version of this dropdown.

Screenshots

screen shot 2017-10-05 at 13 06 20

@youknowriad youknowriad added the General Interface Parts of the UI which don't fall neatly under other labels. label Oct 5, 2017
@youknowriad youknowriad self-assigned this Oct 5, 2017
@codecov
Copy link

codecov bot commented Oct 5, 2017

Codecov Report

Merging #2887 into master will increase coverage by 1.46%.
The diff coverage is 29.72%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2887      +/-   ##
==========================================
+ Coverage   34.07%   35.54%   +1.46%     
==========================================
  Files         192      197       +5     
  Lines        5675     6201     +526     
  Branches      996     1125     +129     
==========================================
+ Hits         1934     2204     +270     
- Misses       3165     3366     +201     
- Partials      576      631      +55
Impacted Files Coverage Δ
editor/header/index.js 0% <0%> (ø) ⬆️
editor/header/publish-with-dropdown/index.js 0% <0%> (ø)
editor/header/publish-dropdown/index.js 0% <0%> (ø)
editor/header/publish-button/index.js 85% <100%> (-3.47%) ⬇️
editor/header/publish-button/label.js 83.33% <83.33%> (ø)
editor/modes/visual-editor/inserter.js 94.44% <0%> (-5.56%) ⬇️
blocks/library/gallery/block.js 9.52% <0%> (-2.25%) ⬇️
editor/actions.js 39.06% <0%> (-2.12%) ⬇️
components/dropdown/index.js 85.18% <0%> (-1.49%) ⬇️
editor/index.js 0% <0%> (ø) ⬆️
... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1400611...3cacbcf. Read the comment docs.

@jasmussen
Copy link
Contributor

jasmussen commented Oct 5, 2017

YOU ARE A BULLET TRAIN! CHOO CHOOO!

I really dig this. Thanks so much for working on it.

This particular implementation seems to be using a "split button" approach, where if you click the left side of the button, you publish, if you click the right side, you get the dropdown. Correct?

The alternative approach would be a single button that always invoked the dropdown, no matter where you clicked.

Both approaches have their pros and cons. The split button gives the benefit of quicker publish access, though perhaps at the cost of simplicity. More of a power user feature, so to speak. This can be alleviated by design:

screen shot 2017-10-05 at 14 21 54

The split button design is perhaps strongest when the post is already published, and needs to be updated, where it might make sense to skip the dropdown.

Personally I'm partial to the single button approach. It makes it extremely easy to understand what happens — the first time you click the button, you learn what's up, and from then on you always know it. This also puts the actual publish action behind a "review and confirm", which as I've suggested in the past is desirable friction, so you don't accidentally publish.

I'm super okay with trying either, though I'd love some quick thoughts by @karmatosed, @mtias or @folletto.

When we decide whether to go split button or single button, some tiny tweaks should be made.

  • If we go split button, we should add the vertical blue separator
  • If we go single button, the dropdown icon should be much closer to the "Publish" label

⭐️ ⭐️ ⭐️ ⭐️ ⭐️ work, Riad, you get a medal! 🥇

@folletto
Copy link
Contributor

folletto commented Oct 5, 2017

Quick thought: I'd prefer to have an intermediate dropdown/sidebar all the times.

Rationale:

  1. Simpler.
  2. Publish is not slowed down that much, just one extra click.
  3. Having a reliable space for actions right before publish allows also plugins to rely on this to add their own items. Some actions are not much "Editor" but more "Publish", so I think they fit better a publish dropdown/sidebar, and it's important they aren't hidden on an optional dropdown but a checkpoint. This can include things like grammar check, validation, social media custom messages, etc. There's a lot that is more publish than editor and until now always got mixed in the editor because there isn't another appropriate space for them.
  4. Some automated publishing actions are irreversible: pings gets sent, emails get sent, Facebook and Twitter gets updates, etc. This is very very important for a lot of people and businesses, and nobody wants to send out such actions by accident.

@karmatosed
Copy link
Member

@youknowriad this is awesome! I worry a little that the 'just publish' and potential for slipping is a bit increased here. I would say it should only happen in the drop down.

@jasmussen
Copy link
Contributor

Quick thought: I'd prefer to have an intermediate dropdown/sidebar all the times.

@folletto can you clarify the above a bit?

Do you mean like how it works on WordPress.com?

publish

@youknowriad
Copy link
Contributor Author

Probably need some polish but it's only opening the dropdown right now.

@folletto
Copy link
Contributor

folletto commented Oct 6, 2017

can you clarify the above a bit?

Yes, I mean confirming your position here:

Personally I'm partial to the single button approach. It makes it extremely easy to understand what happens — the first time you click the button, you learn what's up, and from then on you always know it. This also puts the actual publish action behind a "review and confirm", which as I've suggested in the past is desirable friction, so you don't accidentally publish.

And also clumsly hinting — I didn't want to deviate this thread — that maybe a sidebar would be better than a dropdown for that because:

  1. Dropdowns are usually single-action (not always, but commonly)
  2. Dropdowns have a perception "it's going to close" so it's less "stable"
  3. Dropdowns cover content
  4. A sidebar is a pattern we already have
  5. A sidebar will allow for more extensibility

So I think either way it would work — but if possible I'd explore using a sidebar instead of a dropdown.

@jasmussen
Copy link
Contributor

Solid points, Davide. The "Publish..." phrase on wp.com seems nice, it keeps it a single button without the chevron.The room that the sidebar brings is also welcome, and if we could make it pluggable would be really nice. A sidebar also solves the issue of dropdowns inside dropdowns (i.e. date picker etc.)

The primary downside of the sidebar as I see it (but this could very well just be me) is that it causes a jarring jog if it invokes when you have otherwise dismissed the Settings sidebar.

Does it make sense for this to be a different sidebar? One that "covers" the content, exists on a higher plane than the editor itself and slides in with a shadow under it?

Something like the following, but polished perhaps?

publish

publish confirm

There's some wonkiness with that pattern to work out, though — it's hard to find a good spot for that publish button. LMK if you want the sketch file.

@youknowriad If we were to go with a sidebar instead of a dropdown, as Davide has suggested, would it be a ton of work to change this branch? What would make it easier/harder? What are your thoughts?

@folletto
Copy link
Contributor

folletto commented Oct 6, 2017

The primary downside of the sidebar as I see it (but this could very well just be me) is that it causes a jarring jog if it invokes when you have otherwise dismissed the Settings sidebar.

This is a good point, I'm not sure what the answer is. The mockup might be a good way to tackle it: still covers the content, but still improves on all the other points, and avoids the jog.

Maybe when it covers the "top" area, which matches the white toolbar at the top with "Publish..." button, just has a title, so it's "inactive", and the actual publish button is somewhere below?

@jasmussen
Copy link
Contributor

Maybe when it covers the "top" area, which matches the white toolbar at the top with "Publish..." button, just has a title, so it's "inactive", and the actual publish button is somewhere below?

Yeah, seems like if we did want to go this direction it's something we need to solve.

I like the idea that the publish button is right under, so if you know what you're doing you can "double click". But on the other hand it might not also be too easy to confirm then. It's hard finding the right amount of friction here.

@youknowriad
Copy link
Contributor Author

@youknowriad If we were to go with a sidebar instead of a dropdown, as Davide has suggested, would it be a ton of work to change this branch? What would make it easier/harder? What are your thoughts?

Technically, it can be challenging. If we go this road, I think we should do it in a separate PR, because it's more likely to impact the current settings sidebar as well.

I personally have a preference for this:

  • Keeping the dropdown for the publish button (seems lighter).
  • Update the current settings and inspector sidebar to behave like the suggested publish sidebar above. It makes it feel like something we need to "close" instead of keeping it around when typing and adding content.

@folletto
Copy link
Contributor

folletto commented Oct 6, 2017

Update the current settings and inspector sidebar to behave like the suggested publish sidebar above. It makes it feel like something we need to "close" instead of keeping it around when typing and adding content.

Keeping it around is one of the reason of the current design: we have two kinds of users, one that will keep it open, and one that will keep it closed. Both exist, but they have different patterns. It's very important for the inspector sidebar to look natural both open and closed. :)

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis complains that tests for editor/header/publish-button/index.js are failing.

Code wise I like this proposal a lot. It's almost ready to land if we would omit all UX considerations that are discussed above :)

} from '../../selectors';

function PublishWithDropdown( { isSaving, isPublishable, isSaveable } ) {
const isButtonEnabled = ! isSaving && isPublishable && isSaveable;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to expose it from connect as one prop.

@@ -0,0 +1,8 @@
.editor-publish-with-dropdown {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It nicely replaces the existing override 👍

return (
<Dropdown
position="bottom left"
className="editor-publish-with-dropdown"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newbie question, file name is editor/header/publish-with-dropdown/index.js. A class name is combined from editor keyword and folder name. Is that a pattern we use and the reason that header subfolder is ignored?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's how we do it right now :)

isBeingScheduled,
user,
} ) {
const isContributor = user.data && ! user.data.capabilities.publish_posts;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice idea to extract this logic in a variable 👍

Is there any plan to have a similar way to access API data as we have with Redux selectors? I can imagine we might want to use isContributor check in other places. At the moment we would have to duplicates what we have here. What I like the most about selectors is that they hide the structure of data representation. /cc @aduth

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably related to how with make withApiData state aware

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Selectors are just functions which happen to follow a particular first-argument convention. If it became a common pattern, I could see how it might be useful to create better organization around operating on API data. However, the implementation of withAPIData makes some compromises hinging on an assumption that its usage is very ad-hoc. To @youknowriad's point, if we were to make this more organized, we might similarly want to rethink how it works in the first place. One example might be to support a separate argument on the higher-order component akin to react-redux's mapStateToProps which helps provide a barrier between the component implementation and the underlying data structure.

<Dashicon icon="arrow-down" />
</Button>
) }
renderContent={ ( { onClose } ) => <PublishDropdown onSubmit={ onClose } /> }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice way to close the dropdown on submit.

} ) {
const isButtonEnabled = user.data && ! isSaving && isPublishable && isSaveable;
const isContributor = user.data && ! user.data.capabilities.publish_posts;

let buttonText;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An excellent idea to put this logic into its own component.

@jasmussen
Copy link
Contributor

Thanks for the thoughts, Riad.

Keeping the dropdown for the publish button (seems lighter).
Update the current settings and inspector sidebar to behave like the suggested publish sidebar above. It makes it feel like something we need to "close" instead of keeping it around when typing and adding content.

Is there a third option, more like what's mocked up here, where the publish sidebar is something entirely different than the inspector sidebar — an overlay that floats above the main canvas. If the inspector sidebar is open, it will be covered by the publish sidebar. If the inspector sidebar is not open, the content below will be overlaid. You could almost think of this as a different design for the dropdown. Or am I missing something?

I'm personally still a fan of the dropdown, but I hear Davide and I'm thinking of solutions that might meet in the middle.

@youknowriad
Copy link
Contributor Author

youknowriad commented Oct 9, 2017

Is there a third option, more like what's mocked up here,

My concerns with this is: "Another UI pattern to grasp for the user", that's why I thought about reusing this pattern for all sidebars. We already have dropdowns, and we already have sidebars but happy to go with whichever you'll think is the best approach.

@jasmussen
Copy link
Contributor

Good point. I'll think a bit about this.

@gziolo
Copy link
Member

gziolo commented Oct 9, 2017

My concerns with this is: "Another UI pattern to grasp for the user". We already have dropdowns, and we already have sidebars but happy to go with whichever you'll think is the best approach.

We have a dropdown on the left side and quite random interactions on the right side of the top bar, but when you see the arrow down icon then you know what to expect. In the end it all depends on how much content we want to render in this new area. It makes a lot of sense to leave it as it is with the current shape. I'm afraid using sidebar would end up having lots of whitespaces if we don't add more options there.

@jasmussen
Copy link
Contributor

Since the dropdown is implemented, it might be worth going with that for now, and getting feedback. In the mean time I will explore some alternate routes as well, see what patterns we can take inspiration from.

In the end it all depends on how much content we want to render in this new area.

I would suggest one thing that's more important than this (and is likely best discussed separately) — it is more important to make this area pluggable.

@folletto
Copy link
Contributor

folletto commented Oct 9, 2017

I would suggest one thing that's more important than this (and is likely best discussed separately) — it is more important to make this area pluggable.

+1,000

@jasmussen
Copy link
Contributor

Here's what LivingDocs does:

livingdocs

That is — the entire content area below changes. This may be a bit drastic than changing just the sidebar.

The other common pattern I've seen, Medium, notion.so, Spark, they all show a dropdown of sorts. This dropdown can have various sizes and be dismissable or not with a click outside it, but it's definitely a pattern.

I don't know which approach is best — I still lean towards a dropdown, even if it's a big one, as I feel like it is the least disruptive to the rest of the UI, scales better to mobile, and is also fairly lightweight when it comes to our adding intentional friction to the publishing experience.

That is — I'm not at all against us trying other things, but would it be sensible to polish this PR up, merge as is, and then iterate?

@folletto
Copy link
Contributor

scales better to mobile

On mobile I'd just cover the entire screen, as there's little value imho in having something that uses the whole screen of space but keeps some borders just to hint "it's a dropdown". Full screen would also make scroll issues less problematic.

The comment above is not to say "do a sidebar", just to point out that regardless on mobile it's probably more sensible that regardless of the desktop approach it should go full screen.

would it be sensible to polish this PR up, merge as is, and then iterate?

I think so. Regardless of the final choice of dropdow/sidebar — the behaviour we want is still the same in terms of interaction.

@jasmussen
Copy link
Contributor

That sounds good to me. 👍 👍 for merge from me, then we can get a feel for it!

@youknowriad
Copy link
Contributor Author

Ok let's ship this

@youknowriad youknowriad merged commit f8219f9 into master Oct 16, 2017
@youknowriad youknowriad deleted the try/publish-dropdown branch October 16, 2017 09:19
@aaronjorbin
Copy link
Member

Is there any documentation for plugins extending this?

@youknowriad
Copy link
Contributor Author

@aaronjorbin This is not yet extendable, It should probably be discussed in #1352

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider publish dropdown button
7 participants