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: Replace the publish dropdown by a sidebar panel #4119

Merged
merged 5 commits into from
Dec 22, 2017

Conversation

youknowriad
Copy link
Contributor

This PR is the first step towards the updated publish flow #3496 (comment)

In this initial iteration, I'm not updating the current flow, just replacing the current dropdown by a sidebar panel.

screen shot 2017-12-21 at 11 56 23

Next PRs will focus on:

  • Adding a Post Publish Flow
  • Avoid the panel when updating an existing post.

@youknowriad youknowriad added General Interface Parts of the UI which don't fall neatly under other labels. Needs Design Feedback Needs general design feedback. labels Dec 21, 2017
@youknowriad youknowriad self-assigned this Dec 21, 2017
@youknowriad youknowriad force-pushed the update/publish-dropdown-2-panel branch from 77c2ffe to 82963bd Compare December 21, 2017 10:59
@jasmussen
Copy link
Contributor

Yaaaassss! I love this.

Given we're going with a "combined popover/sidebar", is it possible to make it so if the settings sidebar is toggled off, you still "push in the text"? Right now it covers it:

screen shot 2017-12-21 at 12 22 35

Also — is it possible to add animation at this point? Doesn't have to be in this PR, but structure wise, can the thing animate in from the right?

Thanks so much for working on this!

@youknowriad youknowriad force-pushed the update/publish-dropdown-2-panel branch from 0a8d83a to 240178f Compare December 21, 2017 12:51
@youknowriad
Copy link
Contributor Author

@jasmussen Ok so I had to rethink the redux sidebar state to allow multiple sidebars to be able to fix the text margin issue. It should work now.

I also added a small animation, let me know what you think

@youknowriad youknowriad force-pushed the update/publish-dropdown-2-panel branch from a274aeb to ae83845 Compare December 21, 2017 14:34
@jasmussen
Copy link
Contributor

I love the recent change. I'd speed up the animation to be double the speed, at most .2s. But 👍 👍 I think this is a great first step.

Next steps could be:

  1. Make this action only for the "Publish", and not for "Update" or "Schedule"
  2. Build an opt-out button in the bottom of the publish box, and in the ellipsis menu.
  3. Change the button to be "Publish..." when the experience is enabled, and "Publish" when it's not.

We need to think about where to put the "Switch to Draft" button when it can't sit in the dropdown, but we'll solve that I'm sure.

@jasmussen
Copy link
Contributor

To be clear, those next steps don't have to be in THIS PR, they can be done separately I think.

@youknowriad
Copy link
Contributor Author

I'd speed up the animation to be double the speed, at most .2s.

Tha animation is already .2s, should I update it to 0.1s

@jasmussen
Copy link
Contributor

Ah cool. Yeah let's try .1s

Copy link
Member

@atimmer atimmer left a comment

Choose a reason for hiding this comment

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

Looks good to me 👍🏻. One small question about CSS @keyframes.

animation: slide_in_right 0.1s forwards;
}

@keyframes slide_in_right {
Copy link
Member

Choose a reason for hiding this comment

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

Are keyframes local to a CSS file? If not, would this need a gutenberg_ prefix?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Mmmm good question, I guess this applies to all of our animations. I wonder if there's a way to nest these animations. If not, it makes sense to add a prefix for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

I do think animations are globally registered, so if registered once it's available everywhere the CSS is loaded.

It'd be nice to either have reusable animations, or well scoped ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok! I'm inclined to leave this issue to a separate PR as it's global to all animations.

@atimmer atimmer mentioned this pull request Dec 22, 2017
3 tasks
@youknowriad youknowriad merged commit 21e5b26 into master Dec 22, 2017
@youknowriad youknowriad deleted the update/publish-dropdown-2-panel branch December 22, 2017 15:13
Copy link
Contributor

@mcsf mcsf left a comment

Choose a reason for hiding this comment

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

Looks great! (Got merged as I was typing this. 😄 )

Tangent: Design-wise, the dropdown chevron will go away, as it no longer reflects the impending animation:

gutenberg-publish-dropdown-to-panel

I see, from the parent issue's mockups, that we can adopt Publish… or Publish! instead, without any other visual cue. That's fine with me. However, I'm wondering if we can use what the Customizer did for widgets as inspiration, with the ¼-turn spinning icon:

customizer-widgets-spin-icon

/>
<IconButton
icon="admin-generic"
onClick={ () => onToggleSidebar() }
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the function need to be bound? Perhaps this is an artefact of something else? I'd expect onClick={ onToggleSidebar }.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It needs to be to avoid passing the event as argument to the action creator :)

Copy link
Contributor

Choose a reason for hiding this comment

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

facepalm — obviously. I mean, you could just do some insane stuff in mapDispatch like toggleSidebar.bind( null, undefined, false ), but that's just idiotic. 😄 The arrow is naturally better. exits slowly

<PostPreviewButton />
<PostPublishPanelToggle
isOpen={ isPublishSidebarOpened }
onToggle={ () => onToggleSidebar( 'publish' ) }
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor, but we could extend mapDispatchToProps:

{
  onToggleSidebar: toggleSidebar,
  onTogglePublishSidebar: toggleSidebar.bind( null, 'publish' ),
}

and replace the prop here with onToggle={ onTogglePublishSidebar }.

'has-fixed-toolbar': hasFixedToolbar,
} );
const closePublishPanel = () => onToggleSidebar( 'publish', false );
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor, similar comment as the previous one. Since these bound action creators don't depend on component data, I'd place them in mapDispatchToProps.

*/
export function toggleSidebar( isMobile ) {
export function toggleSidebar( sidebar, force ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Also minor, but both arguments are nouns, yet they express different things, IMO. sidebar is the object of the action, while force is circumstantial. My suggestion would be shouldForce, in keeping with the convention for booleans. (To be super strict, one could rename the former to sidebarName, but I'm fine with sidebar.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think forcedValue is better than shouldForce because it represents the value and not a flag of whether to force or not

@mtias
Copy link
Member

mtias commented Dec 26, 2017

@mcsf I believe the design plan is that the Publish menu uses an ellipsis instead of a chevron. cc @jasmussen

@youknowriad
Copy link
Contributor Author

@mtias yes, updated in #4157

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. Needs Design Feedback Needs general design feedback.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants