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

Adds always on display of media URL #19504

Merged
merged 15 commits into from
Mar 12, 2020
Merged

Conversation

draganescu
Copy link
Contributor

@draganescu draganescu commented Jan 8, 2020

Description

Implementation of one of the variants in #18992 about always showing the URL of the current media in the media replace control.

How has this been tested?

Tested locally.

Screenshots

media-replace-url

Types of changes

Updated MediaReplaceFlow and LinkViewer.
This should eventually use the new LinkControl instead.

cc: @shaunandrews

@Soean Soean self-requested a review January 8, 2020 20:13
@draganescu draganescu added Needs Design Feedback Needs general design feedback. and removed Needs Design Feedback Needs general design feedback. labels Jan 13, 2020
@shaunandrews
Copy link
Contributor

I like it. Two suggestions:

  1. Use a button with a label (instead of a mysterious icon) for the edit action. This matches up with the Link UI, and is also more obvious and clear to users.
  2. Just general cleanup around the layout/display for editing the image URL. Here's a mockup of what I would expect it to look like:

image

@ItsJonQ
Copy link

ItsJonQ commented Jan 29, 2020

@draganescu Hai there! Thank you for working on this fix 🙌

I'm seeing some wonky UI from this PR. Just wanted to follow up to see if we were able to apply the changes suggested by @shaunandrews

Screen Capture on 2020-01-29 at 15-36-52

I also noticed that the input looks invisible when it is no longer focused 😱

Thanks again!

@draganescu
Copy link
Contributor Author

hi @ItsJonQ and thanks for testing!

Indeed, the URLInput component is raising some issues when used in this context. However now that the recent PRs that decoupled LinkControl from Popover are merged I will try to use that here in place of URLInput

@draganescu draganescu force-pushed the add/always-on-url-media-replace branch from 2cdbc0c to d41f1e3 Compare February 4, 2020 15:14
@draganescu
Copy link
Contributor Author

draganescu commented Feb 4, 2020

This now works as expected but I am not happy with the implementation, as it still uses the old LinkViewer and LinkEditor components directly instead of the new LinkControl. However, because of how this is intended to work LinkControl is not ready yet because:

  • it does not have a second "Apply" state
  • cannot be closed

cc @aduth @shaunandrews

@aduth
Copy link
Member

aduth commented Feb 4, 2020

Hi @draganescu , I'm not sure I follow what you mean by the specific requirements you list. What is the second "Apply" state, and how would a LinkControl be closed? Is this referring to the ability to have some option to "Cancel" out of the editing input and return to the preview state?

@draganescu
Copy link
Contributor Author

draganescu commented Feb 4, 2020

Yes @aduth , I should have explained better. But briefly, if you look at the GIF up in the description of this PR, the interaction is in two steps:

  1. you see the link
  2. you edit the link

And this is very similar to how the LinkControl currently works, but except that in step 2, in this case we'd need to "Apply" the link edit and get back to step 1. Currently LinkControl doesn't allow that because it assumes you always want that suggestion drawer, so the input to edit a link does not have a button to "Apply" the edit.

Second, if I want to quit editig and get back to viewing the link, LinkControl does not allow this as it assumes that "quit" means unmounting it (via ESC or focusing somewhere else). In this context, we want the menu to remain open and the LinkControl to return to the view state.

@getdave
Copy link
Contributor

getdave commented Feb 5, 2020

Currently LinkControl doesn't allow that because it assumes you always want that suggestion drawer, so the input to edit a link does not have a button to "Apply" the edit.

I think we should add an explicit "Submit" (aka "Apply") UI. We could make this optional. It would sit next to the "Reset" button.

Second, if I want to quit editig and get back to viewing the link, LinkControl does not allow this as it assumes that "quit" means unmounting it (via ESC or focusing somewhere else). In this context, we want the menu to remain open and the LinkControl to return to the view state.

In this scenario you have (for example) clicked "Edit" but then decided you want to go back and not edit? But you can't do that. Would the Apply button solve this issue?

I think both the above are solvable but should be in a separate PR.

@aduth
Copy link
Member

aduth commented Feb 5, 2020

@draganescu Thanks for clarifying. These are things I'm very interested in as well.

And this is very similar to how the LinkControl currently works, but except that in step 2, in this case we'd need to "Apply" the link edit and get back to step 1. Currently LinkControl doesn't allow that because it assumes you always want that suggestion drawer, so the input to edit a link does not have a button to "Apply" the edit.

If I understand this correctly: The applied editing does exist as handled as a form submission, but there's nothing in the UI to indicate this (or to click on for submitting). It relies on the Enter key press to submit/apply.

If my interpretation is correct, I think this can serve as a testament that #19971 would be a good revision to pursue to improve this clarity.

Second, if I want to quit editig and get back to viewing the link, LinkControl does not allow this as it assumes that "quit" means unmounting it (via ESC or focusing somewhere else). In this context, we want the menu to remain open and the LinkControl to return to the view state.

There was some similar challenges for implementing this in the paragraph (#19462 (comment)). You might be interested in the discussion in #20007.

It might be tricky for your specific use-case. My first thought was that "Escape" could toggle the internal state of <LinkControl /> to "cancel" the edit, like one of the options you mention. However, I think it's also important that "Escape" would also close the currently visible popover. I'm not sure how best to deal with a scenario where both: (a) we have an editable state to cancel, and (b) that editable state is within a popover.

Using focus as a basis for the editing state might work, but it needs to account for the additional action buttons shown alongside the input (currently "Reset", maybe in the future "Submit" and/or "Advanced Settings").

There could also be an explicit Cancel button in here as well. The problems here are that: (a) the space is limited (related) and (b) the goals of #20007 might be such that we don't want the preview state to be reachable at least in the context of paragraph link editing workflows.

@aduth
Copy link
Member

aduth commented Feb 5, 2020

Thinking more about Cancel:

  • Is it even necessary? If you're not going to submit your changes, then there's not a practical difference between "cancel" vs. simply leaving the input in its editable state, unless the Preview included some critical information.
    • To clarify, I don't feel strongly about this point, it's more a thought experiment.
  • Canceling edit in response to blur of the input and its controls could be a reasonable way to approach this, at least as a compromise to support a use-case like the one needed here.

Copy link
Contributor

@shaunandrews shaunandrews left a comment

Choose a reason for hiding this comment

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

Had some visual tweaks for the CSS to help line up elements, along with cleaning up margins and paddings. Here's how it looks with the suggested updates:

image

@draganescu
Copy link
Contributor Author

Hi @shaunandrews I've added all your suggestions and it looks pretty neat. Let me know of any other tweaks :)

@aduth
Copy link
Member

aduth commented Feb 10, 2020

Per previous comments about LinkControl applicability here, not that as of #20052, at least one of the issues you mentioned should now be resolved (a "Submit" button is always shown in the editing state).

@shaunandrews
Copy link
Contributor

Pushed a quick change to add some more spacing around the Media Library and Upload buttons. Here's how it looks:

image

🚢

@draganescu draganescu force-pushed the add/always-on-url-media-replace branch from 37681e7 to f160f8d Compare February 11, 2020 14:35
@draganescu draganescu added [Feature] Media Anything that impacts the experience of managing media [Type] Enhancement A suggestion for improvement. labels Feb 12, 2020
@draganescu
Copy link
Contributor Author

This is looking good now, but it does not use LinkControl, which is what I am working on :)

@draganescu draganescu force-pushed the add/always-on-url-media-replace branch from f160f8d to cd5f1c6 Compare February 13, 2020 17:12
@draganescu
Copy link
Contributor Author

@getdave @aduth I have implemented this UI using the LinkViewer but I had to add some changes to the component to work as needed in this situation. Therefore:

  • I added a showSuggestions prop to turn off suggestions showing (as in the case of media links we don't have media suggestions)
  • I disabled jsx-a11y/no-noninteractive-element-interactions for the form in the SearchInput component b/c I couldn't stop the key presses from propagating otherwise

Do you think these are good modifications? Is the LinkControl the correct control as this is not really a link? Should I go back to using LinkViewer and LinkEditor?

@draganescu
Copy link
Contributor Author

@Soean could you re-review and see if everything works as expected? :D Thank you 💯

@Soean
Copy link
Member

Soean commented Feb 21, 2020

@draganescu
If I use a different language with a longer button text like "Bearbeiten" in (Deutsch / German), the button is not visible on mobile.

English
Bildschirmfoto 2020-02-21 um 11 31 46

Deutsch / German
Bildschirmfoto 2020-02-21 um 11 30 12

Copy link
Contributor

@getdave getdave left a comment

Choose a reason for hiding this comment

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

Nice work on updating this to use LinkControl. It's great that we're stress testing this component. I hope it wasn't too painful!?

I noticed a few things that caught my eye. Let me know if anything doesn't make sense.

packages/block-editor/src/components/link-control/index.js Outdated Show resolved Hide resolved
onKeyPress={ ( event ) => {
const { keycode } = event;
if ( keycode === ENTER ) {
selectSuggestionOrCurrentInputValue();
Copy link
Contributor

Choose a reason for hiding this comment

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

This caught my eye. I'm sure this code got removed in earlier PRs on LinkControl. Does the action not get handled by the onSubmit handler?

If not then we could consider adding a comment here to indicate why we're having to double up here as it wasn't immediately apparent to 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.

There is this comment in the URLInput component which made this neccessary:

// If the suggestions are not shown or loading, we shouldn't handle the arrow keys
// We shouldn't preventDefault to allow block arrow keys navigation

As in this context we explicitly disable suggestions then we need to also handle stopping key propagation to observe typing. Otherwise The pop up closes.

Would you think there is a better way around this?

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 would have to also take care of the Escape button as now tests are failing b/c the link editor is not being dismissed on ESC anymore :( ugh.

@draganescu
Copy link
Contributor Author

@Soean good catch. After rebasing the new G2 UI was added and now it is a bit worse :) The button is not cut, the whole link editor is having an invisible scrollbar. I wonder what is the best solution here. I would simply hide the link on mobile, to make sure edit in all languages definitely fits. Another option would be to wrap the button ... but that raises other issues.

Copy link
Member

@Soean Soean 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 now!
We need to change $grid-size-large to $grid-unit-20, see #20529.

@draganescu draganescu force-pushed the add/always-on-url-media-replace branch from 18497c4 to f24307d Compare March 9, 2020 07:52
@shaunandrews
Copy link
Contributor

I pushed some CSS changes. Here's how its looking now:

Replace Menu

I'd be nice if the popover was left-aligned with the toggle button in the toolbar, but that might be something that needs to be done on the Dropdown level?

@draganescu draganescu merged commit 07d751a into master Mar 12, 2020
@draganescu draganescu deleted the add/always-on-url-media-replace branch March 12, 2020 09:49
@github-actions github-actions bot added this to the Gutenberg 7.8 milestone Mar 12, 2020
@draganescu
Copy link
Contributor Author

Thank you @shaunandrews for the tidy up tweaks. I am so glad this is finally merged :)

@noisysocks
Copy link
Member

Are we able to truncate the URL in the middle so that it appears as localhost…Climbing-Wall.jpg instead of localhost:8888/wp-content/…? It's not useful unless you can see the file name of the image. (Sorry if this has already been raised!)

@draganescu
Copy link
Contributor Author

Good suggestion @noisysocks ! I'll open an issue with that in it.

@draganescu
Copy link
Contributor Author

Done here it is: #21100

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Media Anything that impacts the experience of managing media [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants