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

LinkControl Refresh #50891

Closed
10 of 13 tasks
richtabor opened this issue May 23, 2023 · 100 comments
Closed
10 of 13 tasks

LinkControl Refresh #50891

richtabor opened this issue May 23, 2023 · 100 comments
Labels
[Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) Needs Accessibility Feedback Need input from accessibility [Package] Block editor /packages/block-editor [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues

Comments

@richtabor
Copy link
Member

richtabor commented May 23, 2023

This issue combines design explorations into one implementation plan and supersedes #49091 for tracking LinkControl. There are three key area of this proposal: inline, navigation, and image links.

I've drawn out the flows for each key area below, consolidating feedback into actionable issues to improve link application across the editor experience. And the tasks listed are prioritized in general implementation order.

Tasks

Follow-up

Inline links

CleanShot 2023-05-30 at 13 09 50

Key concepts:

  • Initial state suggests pages (scrollable area).
  • Search results return from all available post types.
  • "Add new page" opens this modal.
  • Only either “Add link” or “Add new page” is rendered, based on the field value.
  • Press enter, or click “Add link:” to add a link/item.
  • Clicking on an inline link brings up the edit state of the link.
  • The “Save” button is disabled unless there are changes.

Navigation links

CleanShot 2023-05-30 at 13 56 24

Key concepts:

  • Initial state suggests pages (scrollable area).
  • Search results return from all available post types.
  • “Add block” control is appended to the foot of the component.
  • Navigation Link block variations (Post Link, Category Link, Tag Link, etc) initial state renders type based on the variation—i.e. Category Link renders categories.
  • Navigation Link search results return items based on the query type.

Media links

CleanShot 2023-05-30 at 13 11 23

Key concepts:

  • Replaces the existing control on media blocks (Image, Media & Text).
  • Initial state suggests pages (scrollable area).
  • Search results return from all available post types.
  • Media-specific tooling to link to the image file and the attachment page.

props to @getdave @jasmussen @jameskoster @SaxonF.

@richtabor richtabor added [Package] Components /packages/components [Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) labels May 23, 2023
@richtabor richtabor changed the title LinkControl Refresh LinkControl: Refresh May 23, 2023
@richtabor richtabor changed the title LinkControl: Refresh LinkControl refresh May 23, 2023
@richtabor richtabor changed the title LinkControl refresh LinkControl Refresh May 23, 2023
@fabiankaegy
Copy link
Member

Thank you for working on this proposal. At first glance, I really like the refined UI here.

Something I'm a little worried about though, is the removal of the URL in the suggested items when searching for any piece of content. A lot of sites I'm working on have a ton of content with sometimes very similar names. Since the URL needs to be unique, it helps editors on those large sites to be able to better differentiate between the very similarly named posts. Looking at these explorations here, I feel like that nuance is getting lost here, and whilst the designs look great with that very ideal content I worry that more complex sites will struggle a lot without these additional contextual clues.

@getdave
Copy link
Contributor

getdave commented May 24, 2023

@richtabor Thank you for these designs. These address many of the concerns I've raised previously about the designs that have been proposed in the past and also unifies a lot of the flows. That's great.

I think we should now look at what is feasible within the scope of 6.3 and look to address those issues that are the most impactful. I anticipate this effort may run into 6.4, but that does of course depend on how many contributors engage with this effort.

the removal of the URL in the suggested items when searching for any piece of content

I agree with Fabian here. I've received feedback before that adding additional context helps to find the correct entity. I appreciate their is a design/visual trade off here, but it may be considered a UX regression if we don't include it. How much do you feel this impacts on the usability of the control? For example, does the additional "noise" of the URL make it harder to scan the results?

@richtabor
Copy link
Member Author

Since the URL needs to be unique, it helps editors on those large sites to be able to better differentiate between the very similarly named posts.

Do you mean in a scenario where two pages are titled “About”, you wouldn’t know which is which?

@richtabor
Copy link
Member Author

I think we should now look at what is feasible within the scope of 6.3 and look to address those issues that are the most impactful.

I put the task list in implementation order (theres a bit of leeway of course). Of those, what do you think we won’t get to?

From my POV, perhaps the “Add block” state may take the most effort.

I’m cool with keeping the media linking out of the initial effort (but having a clear technical path for that context).

@fabiankaegy
Copy link
Member

Since the URL needs to be unique, it helps editors on those large sites to be able to better differentiate between the very similarly named posts.

Do you mean in a scenario where two pages are titled “About”, you wouldn’t know which is which?

The example of two about pages is not the one I would have gone for even though thinking about it as soon as you add multilingual installations into the mix that may very well exist. Where you have two pages called About. One with the url /en/about and one with au/about because of localized / legal differences 🤷

What I've seen sadly too often is duplicate copies of a page for making revisions and then being able to use the URL makes it easier especially when you are still in the early days of a website before it goes live to choose the correct version.

What I think would also be great to see is how very long page titles get handled. If there is any truncation happeing in the title itself having the url there helps because the way it is truncated usually is different to the title. (Title usually cutts of everything from the end and url truncated in the middle to show the end. Which can often be the most important part.)

Like imagine having these posts:

  • Top 10 block editor related features shipping in WordPress 6.2
  • Top 10 block editor related features shipping in WordPress 6.1
  • Top 10 block editor related features shipping in WordPress 6.0

If the URL doesn't appear we should at least ensure there is never any truncation happening on the titles :) So showing some longer titles in the mockup is probably a good idea just to showcase that from the beginning :)

Because of the similar names across multisite or staging sites with duplicate content I personally think it helps a ton.


Thinking about it more I actually have another relevant story from just yesterday where the URL saved me. I was working on a site and wanted to link to a page I had just created. Because I still had an older page with the same title in the trash the url automatically appended -2 at the end of the URL. And I only caught that mistake when I tried to add that page to the navigation block because you usually don't often see the URL of things when just publishing content.

Yeah, I would have probably caught it not too late after when visiting the page on the frontend. But even that isn't always a given because many browsers don't show the full URL anymore.

@jasmussen
Copy link
Contributor

The example of two about pages is not the one I would have gone for even though thinking about it as soon as you add multilingual installations into the mix that may very well exist. Where you have two pages called About. One with the url /en/about and one with au/about because of localized / legal differences 🤷

Are you refererring to this screen?

Screenshot 2023-05-25 at 09 44 24

I.e. that you are only allowed to make a custom link if you actually add a tld at the end?

Screenshot 2023-05-25 at 09 44 54

I don't think it would be the end of the world if we had to add back the "Add URL", but I support Rich's design, because it's currently way too easy to make a completely broken link, like just typing asdf and pressing Enter and getting something useless as a result. In that light, it might be good to do some very light validating such if the phrase includes a /, http, www, a # or even a ., then we show the URL suggestion. That would at least catch common "bad link" cases.

Speaking specifically to the multilingual case, I would worry about optimizing too much for that. Implementations vary a lot, in some you'd just see the language as a parent page and the dialog would work fine. Moreover, I like to think that as we go into the multilingual phase 4, issues like these can be absorbed and handled more smartly, perhaps through a locale picker in the UI. That's not to negate the use case, just that it's probably good to not optimize too heavily for it at this point.

@fabiankaegy
Copy link
Member

@jasmussen my concern is not about having the add url button. It is that the various suggestions of content from the current site doesn't show the URL of that post anymore

@getdave
Copy link
Contributor

getdave commented May 25, 2023

This is a good discussion. Update: we should probably move it to #50885 as that's more specific.

I have to say I support @fabiankaegy's point about distinguishing between links. Why? Because it was previously a real user problem in the Link UI. It's an identified user need and a common pain point.

If, by revising the UX of this control, we remove the ability to distinguish between links that users have previously specifically requested, then we are regressing the interface. That would be unfortunate.

I appreciate the push for a clean interface and Joen's point about the UI adapting in the future to accommodate i18n, but our users need a way to distinguish between similarly named posts today.

I think we need to at least consider adding in the URLs or provide some other means for users to distinguish between posts appearing in the search results without having to select one 🙏

@kalimba666
Copy link

Greetings. Sorry to revive this issue which was supposedly closed. Is it just me or have we gone back to annoyingly having to click 4 times just to open a link in a new tab? I thought there was an understanding that this was unnecessary? Did we just have a new WordPress update? I have checked on multiple websites and you guys have once again hidden open-in-new-tab behind that pencil. Not only that, but when you click on the choice, you also need to click on the save button, which is redundant. Maybe it's just me but guys, this is supper annoying. Bloggers have enough things to worry about, what with the carnage of the Google March Core update, without having to deal with this issue again.

I never saw any improvements. I had to click several times to get the "open in new tab" feature. Even with regular updates.

@TapiwaZvaks
Copy link

It's really sad. Literally hundreds of bloggers have cried out about this issue on various platforms and the developers have chosen to go back. It's like users do not matter at all. I had found a workaround in that when I pasted a link using Ctrl V, the option to open in new tab immediately popped out. I only needed to click on it once and it was automatically saved. However, that has since been taken away for some reason. Now I need to paste the link. Then I click on the pencil thingy. Then I click on the open in new tab option. Then I click on the save button. I don't think any of the developers has ever used WordPress. Maybe it's for us unwise people. They probably use Joomla or something. Otherwise they wouldn't make life a misery for millions of people so needlessly

@firepainting
Copy link

Is it just me or have we gone back to annoyingly having to click 4 times just to open a link in a new tab?

I confirm this. Not just you. Yep, more annoying.

I thought there was an understanding that this was unnecessary?

As one of these brilliant and lovely devs said, they totes understand stuff, no need to repeat that. (But of course that's not the point.)

Did we just have a new WordPress update?

Yep, 6.5, updated mine just now.

I had found a workaround in that when I pasted a link using Ctrl V, the option to open in new tab immediately popped out.
However, that has since been taken away for some reason.

I confirm this, too.

They probably use Joomla or something.

Oh god please no lol.

@scruffian
Copy link
Contributor

scruffian commented Apr 3, 2024

There is an attempt to improve the situation here: #50998

@TapiwaZvaks
Copy link

What do you mean? Remember there was no problem initially before 6.3 I think. The open in new tab option automatically opened when you pasted a link. Then they created a problem in 6.3. They solved it in 6.4 but not perfectly. However, it was workable. Now they have regressed by going back to the problem, ie you need 4 clicks to perform a simple action. Moreover, that action is fairly commonly carried out by users. I don't see why they should create problems in the first place? So they can try and solve them?

@richtabor
Copy link
Member Author

Here is the current flow inserting a link (yes, on my own WordPress blog that I post with regularly) using the control and setting it as external. This is clearly a step forward from previous releases.

link.mp4

There is an attempt to improve the situation here: #50998

Inserting links via the control, or with CMD+K, engages the link preview—reducing the need to click on the toolbar. We should do the same when a link is pasted in.

@TapiwaZvaks
Copy link

Here is the current flow inserting a link (yes, on my own WordPress blog that I post with regularly) using the control and setting it as external. This is clearly a step forward from previous releases.

link.mp4

There is an attempt to improve the situation here: #50998

Inserting links via the control, or with CMD+K, engages the link preview—reducing the need to click on the toolbar. We should do the same when a link is pasted in.

Lol. Where is the laughter emoji here? How is that progression? FYI, in 6.4, those 5 steps that you outlined were only 2. After highlighting the link text, I would paste the URL (using ctl + V) and the option to open in new tab would appear automatically. I would then click on the checkbox and that was it. No need to click on the Save button. This is a huge step backwards. Two clicks have become 5 and you call that progress? I honestly doubt you blog regularly. As I noted earlier, you guys don't even get it. It's frustrating...

@TapiwaZvaks
Copy link

Sorry but we spent several months offering suggestions here and the issue was solved in 6.4, at least to a very high degree. So, what issue were you trying to solve really in #50998? I just don't get it

@kalimba666
Copy link

Here is the current flow inserting a link (yes, on my own WordPress blog that I post with regularly) using the control and setting it as external. This is clearly a step forward from previous releases.

As already pointed out in 6.4 it was pasting, check the box -> two steps.
Your recording shows five steps.
I don't see a progress with the new update.

@richtabor
Copy link
Member Author

So, what issue were you trying to solve really in #50998? I just don't get it

So when you create, or select, a link, you see the full edit view, like this:

CleanShot 2024-04-03 at 17 03 24

@TapiwaZvaks
Copy link

TapiwaZvaks commented Apr 4, 2024

You do realize why some of us are surprised right? That behavior was there pre 6.3. After a lot of negotiating it was reintroduced in 6.4. Its surprising why you were still exploring the issue. As I stated, in 6.4 when a link was added using ctl +v, that window automatically popped up. One then only needed to click on the checkbox and everything was saved automatically. I guess being open source software anyone can come in and make their own changes and there is no coordination. You were trying to solve an issue that was solved already and by so doing you have destroyed the solution. And where are the advanced options in this solution that you are coming up with?

@JoostWP
Copy link

JoostWP commented Apr 4, 2024

You know what WordPress version I've installed on my main website? 6.2.2.

Yes, I'm willing to risk working with a super outdated WordPress core due to how horrific this one particular feature is. Try updating 100 old blog posts with it without losing your mind.

It is obscene to read that link management is only regressing further.

It's almost as if the WordPress developers are trolling us at this point. It is super evident there is a problem. There isn't evidence of even a single user who is happy with these changes made to the link management.

Plus as mentioned, many in the blogging space have seen their traffic decimated throughout the last Google updates and don't need the extra stress that such a core feature brings, at all.

Really, what is happening here?

@TapiwaZvaks
Copy link

Upon reflection @richtabor I think I see where there is a bit of confusion. I read through the article on your blog introducing 6.5. Specifically the section titled >Refreshed link control.
I have also read through #50998. I think there is some misunderstanding regarding the issue. Particularly when it comes to dealing with internal and external linking. For me, internal links are not really a problem since I am perfectly happy to have them open on the same window.
It would appear though that the process with which you are seized deals with the placement of internal links and improving usability regarding the open in new tab option. I don't know if this makes sense? But, for me at least, the most important aspect on which focus should be is the placement of external links. Here are the steps that I go through when doing so;

  1. First I find the web page to which I wish to link. Say example.com. I usually use Google to find the site. From Google, I either open the page and read through it before copying the link URL, or I copy the URL directly from Google.
  2. With link copied, I go to the WordPress editor and I highlight the text on which I wish to place the link.
  3. Next, I press ctl + v on my keyboard to paste the link. Some people prefer to right click on the mouse before choosing paste.
  4. In 6.4, when we did this, the popup containing the option for opening in a new tab automatically ...popped up
  5. All that I needed to do was to click on the checkbox and the setting was automatically saved without needing to press on the Save button.
  6. Unfortunately, this setting has been removed in 6.5 increasing two clicks to 5 or so. In 6.3 the clicks were about 6 so that's barely an improvement.

I see in your example clips on your blog and in the one from @getdave on #50998 that you search in the search box for a link, presumably internal, before choosing it. I just thought I should highlight that I never do this. I doubt many people ever do this. The search box is good for internal linking but internal linking is not the issue at issue here. In any case, I add internal links basically in the same way outlined in my point above. I go to my Posts, search for the page I wish to link to and then proceed as from step 2 in the above.

I just thought I should clarify the flow for a typical WordPress user. Never mind internal links. What we want is to have external links open in a new tab. Basically the popup window should popup when I paste the link onto the link text. When that happens, it should be one click to select the option for opening in a new tab and for no following a link. As it was in 6.4.

@TapiwaZvaks
Copy link

You know what WordPress version I've installed on my main website? 6.2.2.

Yes, I'm willing to risk working with a super outdated WordPress core due to how horrific this one particular feature is. Try updating 100 old blog posts with it without losing your mind.

It is obscene to read that link management is only regressing further.

It's almost as if the WordPress developers are trolling us at this point. It is super evident there is a problem. There isn't evidence of even a single user who is happy with these changes made to the link management.

Plus as mentioned, many in the blogging space have seen their traffic decimated throughout the last Google updates and don't need the extra stress that such a core feature brings, at all.

Really, what is happening here?

Hi. How do I rollback to 6.2.2. At this point I am also willing to risk it because this is so maddening.

@draganescu
Copy link
Contributor

@richtabor reading @TapiwaZvaks 's description of their workflow I wonder if in #50998 we should treat the two cases differently: if there is an internal link chosen from the suggestions box go to preview, if there is a pasted link or an external link typed, go to the details form.

I am all for consistency, but in this case external links are different because of reasons, so maybe their different flow is justified? Also, the biggest draw back in #50998 is the huge splash of UI when going straight to the details form, but if this is reserved for pasted/external typed links the effect is way smaller in frequency.

@TapiwaZvaks
Copy link

@draganescu what frustrates me (us) as users is that the interface was perfect before 6.2. It was messed up in 6.3. It became workable again in 6.4. It's messed up again in 6.5. Yet you guys seem to be reinventing the wheel. It's nearly a year now with people crying for things to go back to what they were in 6.2. There is really no need for you guys to reinvent the wheel. Your suggestions are great but this is not something that needs reinvention. If you can just check 6.2 going back, you will see how things need to be. Perhaps it's a case of needing something to do?

I have already pointed out that tables are barely usable. You could maybe expend all your energies on that so people do not need a hodgepodge of table plugins. There are many other useful changes that can be made. On this one you regressed. Even in the preview to 6.3, there were people stating that this was not the way to go. It touches on the core of usability. Forcing people to click 5 or 6 times where there was previously just 1 or two clicks is something else.

And this is not the only thing that is being detrimentally cleaned up. I mentioned somewhere the very useful 'i' that used to be in the top left corner which showed the header structure as content was being written. That has since been hidden so well only a determined user can find it. With 6.5, the URL is also no longer simply visible while drafting a post. You need a couple of clicks to reveal all of it. So, there is this desire to clean up the user interface. Unfortunately, whoever is doing the cleaning up is determined to remove very useful elements. Never mind what users have been saying...

@firepainting
Copy link

First off many thanks to @TapiwaZvaks for patiently reiterating what I personally thought was easy to grasp. However, it seems there must be some misunderstanding (which is why this issue still isn't resolved in the first place, and for a long damn time).

Second, @richtabor hats off to you for consistently accommodating these comments. In this light I suggest keeping a separate issue for this and just keeping it open so those who encounter this issue across the web gets redirected there. This particular thread #50891 (10 of 13 tasks) IMO isn't a good place for that.

Now back to the first point, which pertains to "Open in New Tab". Yes, now it requires MORE clicks than ever. No one in their right mind would claim that is intuitive.

@richtabor We basically don't care about how internal linking works (it worked/works fine and it's not the issue here in the first place), but I personally would like the experience to be the same for both external links (which has the option to open in a new tab and nofollow RIGHT OFF THE BAT) and internal links--in this case, the way internal links are created/edited should follow that of external links. Again, before this screwup, everything was fine. "Fine" = there was no public backlash enough to warrant a shakeup in the WP dev world. Otherwise, we should've already seen it.

Adding my thoughts of @TapiwaZvaks's workflow (which is similar to mine)

First I find the web page to which I wish to link. Say example.com. I usually use Google to find the site. From Google, I either open the page and read through it before copying the link URL, or I copy the URL directly from Google.
With link copied, I go to the WordPress editor and I highlight the text on which I wish to place the link.
Next, I press ctl + v on my keyboard to paste the link. Some people prefer to right click on the mouse before choosing paste.

I do Ctrl+K and then Ctrl+V because it's the same across all the other apps I use (GMail, Google Docs, Office suites, etc.) But I also like the solo Ctrl-V because it reduces the number of clicks/presses.

@TapiwaZvaks:

I see in your example clips on your blog and in the one from @getdave on #50998 that you search in the search box for a link, presumably internal, before choosing it. I just thought I should highlight that I never do this.

I never do that, too. More specifically, I never type out stuff inside the search box (of course this only works for internal links).

For external links, I only either copy the URLs from my notes (LibreOffice Writer) or copy them directly from the browser (external links are just open while I'm doing the draft).

For internal links, I just open my "Published posts" page on WordPress wp-admin/edit.php?post_status=publish&post_type=post and copy relevant links there (Right-click on View below the Post Title (to be linked to), and then Copy Link (on Firefox).

Before publishing a post I Preview it and I check every single link in there--left-clicking them to see if external links do open in a new tab. (With this workflow I don't need link previews in the link dialog box.)

@TapiwaZvaks:

I just thought I should clarify the flow for a typical WordPress user. Never mind internal links. What we want is to have external links open in a new tab. Basically the popup window should popup when I paste the link onto the link text. When that happens, it should be one click to select the option for opening in a new tab and for no following a link. As it was in 6.4.

Well-put. @richtabor, we'd appreciate any questions you may have. I personally don't like it when you seem to have wasted your time working on something that misses the point.

@draganescu:

@richtabor reading @TapiwaZvaks 's description of their workflow I wonder if in #50998 we should treat the two cases differently: if there is an internal link chosen from the suggestions box go to preview, if there is a pasted link or an external link typed, go to the details form.

I think this is another accident waiting to happen. How about sticking to one efficient solution for both cases first, and then fine-tune the other one (internal links) once things are going well?

@draganescu:

Also, the biggest draw back in #50998 is the huge splash of UI when going straight to the details form, but if this is reserved for pasted/external typed links the effect is way smaller in frequency.

The workflow in the video above is also counterintuitive, at least to me:

  • URLs are usually pasted, not "searched", straight into the URL field.
  • If I want to change the anchor text, I don't do it under "TEXT" inside the dialog box, I change it on the editor/paragraph itself!
  • And of course, so many clicks.

Again, show us some data that "we should treat the two cases differently" and "I am all for consistency, but in this case external links are different because of reasons, so maybe their different flow is justified?"

We're already telling you what's up. If things are unclear, ask us so nobody's time gets wasted.

@firepainting
Copy link

Nice to see a couple of devs who get it. Also, it does seem that this whole debacle started just because the WP guys were "not sold on this", which is just...sad.

@richtabor
Copy link
Member Author

What we want is to have external links open in a new tab. Basically the popup window should popup when I paste the link onto the link text.

Yup, tracking. This issue would resolve that — #60436

@richtabor
Copy link
Member Author

I am all for consistency, but in this case external links are different because of reasons, so maybe their different flow is justified? Also, the biggest draw back in #50998 is the huge splash of UI when going straight to the details form, but if this is reserved for pasted/external typed links the effect is way smaller in frequency.

I'd rather make it a preference #60444, than make it an inconsistency—regardless of frequency (which we can't assume).

@jasmussen
Copy link
Contributor

I'd like to support what Rich is doing, and has done, to fix existing issues with the link control. I think he has good instincts, and to that end, I'd lean towards supporting #60444.

@TapiwaZvaks
Copy link

Hi @jasmussen. I agree with you to a very small extent. Anything that removes the ennui that comes from having so many clicks would be welcome. But out of curiosity, are you a writer or a developer? My feeling over the past year is that developers mostly have very bad instincts on this issue. They don't know how their own creations are used. I told a while back the story of developers who were hired to automate graders (earthmoving equipment). The idea was that once that was done, human grader operators would be discarded, thus saving a lot of money. Unfortunately, or fortunately, the programmers were not grader operators. They had no idea how grader operators worked. As a result, it didn't take more than a couple of minutes for the company to realize it's mistake. Humans were subsequently rehired. Well, maybe it's just me.... Anyway, let me rest my case for now. I think I have said my piece on this one. My solution is to rollback to 6.2 till the issue is resolved.

@JoostWP
Copy link

JoostWP commented Apr 5, 2024

Hi @jasmussen. I agree with you to a very small extent. Anything that removes the ennui that comes from having so many clicks would be welcome. But out of curiosity, are you a writer or a developer? My feeling over the past year is that developers mostly have very bad instincts on this issue. They don't know how their own creations are used. I told a while back the story of developers who were hired to automate graders (earthmoving equipment). The idea was that once that was done, human grader operators would be discarded, thus saving a lot of money. Unfortunately, or fortunately, the programmers were not grader operators. They had no idea how grader operators worked. As a result, it didn't take more than a couple of minutes for the company to realize it's mistake. Humans were subsequently rehired. Well, maybe it's just me.... Anyway, let me rest my case for now. I think I have said my piece on this one. My solution is to rollback to 6.2 till the issue is resolved.

I second this. Let's roll back to 6.2 and then reflect on whether a new implementation is really necessary - and if so, only implement when there is widespread buy in from the broader community.

For reference, this is what to old link management flow looked like:

1 2 3

Elegant, smooth and simple. Let's re-introduce it and make everybody happy.

@TapiwaZvaks
Copy link

TapiwaZvaks commented Apr 5, 2024

image

After downgrading to 6.2, this is what I get. Aaaaah, blessed sanity!!!

@JoostWP
Copy link

JoostWP commented Apr 5, 2024

image

After downgrading to 6.2, this is what I get. Aaaaah, blessed sanity!!!

Glad you managed to roll back. Didn't realize this was still possible. I just never upgraded. :)

@elgato91
Copy link

elgato91 commented Apr 8, 2024

I'd like to support what Rich is doing, and has done, to fix existing issues with the link control. I think he has good instincts, and to that end, I'd lean towards supporting #60444.

Since when have we started relying on individual instincts in UX design, rather than on testing and feedback?

I would like to thank @TapiwaZvaks, @firepainting, and many others who have patiently provided feedback and reasoning on this issue. It seems that everything that needed to be said has already been said. A long time ago.

And as someone said: you’re trying to reinvent the wheel and pass it off as the development of a new feature. But hey, you just messed up something that already existed for decades, worked well enough, and now it’s broken.

Wouldn’t it be sufficient to revert to the previous situation? We’ve had enough of these endless threads (like new #60444 )... advanced versions, basic versions, internal link versions, external link versions. It's a senseless obsession. It seems like this is purely for your personal enjoyment. It’s a waste of effort and time, and it’s clearly frustrating for users.

In the meantime, we are practically forced to use outdated versions of WP to be able to work without wasting a lot of time. We’re also battling with Google’s erratic search results and the unfair competition from AI. It’s absurd. Please, enough is enough!

@firepainting
Copy link

So I searched across wordpress.org forums and unsurprisingly they agree this sucks:

Exhibit 1
Exhibit 2
Exhibit 3
Exhibit 4
Exhibit 5

What's interesting to me is that last one, Exhibit 5, especially for those WP devs that don't believe us mere mortals 😆️

In it Adam Connell commented. For those who don't know I think he's one of those legit blogger-influencers. When I was just starting out I would use some of his advice through his site bloggingwizard.com. I would listen to him. Again, he's a PRO BLOGGER--he knows a thing or two about senseless UX downgrades. This is his comment 6 months and 2 weeks ago:
adam

@elgato91

We’re also battling with Google’s erratic search results and the unfair competition from AI.

To the devs, no offense but I'm pretty certain you wouldn't understand the above, but that's okay because you are DEVS, NOT PRO BLOGGERS. And that is why we, BLOGGERS, are here giving you feedback ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Link Editing Link components (LinkControl, URLInput) and integrations (RichText link formatting) Needs Accessibility Feedback Need input from accessibility [Package] Block editor /packages/block-editor [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
None yet
Development

No branches or pull requests