LinkControl Refresh #50891
Comments
richtabor
added
[Package] Components
|
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. |
|
@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.
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? |
Do you mean in a scenario where two pages are titled “About”, you wouldn’t know which is which? |
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). |
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 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:
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 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. |
Are you refererring to this screen? 
I.e. that you are only allowed to make a custom link if you actually add a tld at the end? 
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 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. |
|
@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 |
|
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 🙏 |
I never saw any improvements. I had to click several times to get the "open in new tab" feature. Even with regular updates. |
|
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 |
I confirm this. Not just you. Yep, more annoying.
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.)
Yep, 6.5, updated mine just now.
I confirm this, too.
Oh god please no lol. |
|
There is an attempt to improve the situation here: #50998 |
|
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? |
|
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
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... |
|
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 |
As already pointed out in 6.4 it was pasting, check the box -> two steps. |
So when you create, or select, a link, you see the full edit view, like this:
|
|
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? |
|
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? |
|
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 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. |
Hi. How do I rollback to 6.2.2. At this point I am also willing to risk it because this is so maddening. |
|
@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. |
|
@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... |
|
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)
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.
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 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.)
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.
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?
The workflow in the video above is also counterintuitive, at least to me:
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. |
|
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. |
Yup, tracking. This issue would resolve that — #60436 |
I'd rather make it a preference #60444, than make it an inconsistency—regardless of frequency (which we can't assume). |
|
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. |
|
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: 
Elegant, smooth and simple. Let's re-introduce it and make everybody happy. |
|
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. :) |
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! |
|
So I searched across wordpress.org forums and unsurprisingly they agree this sucks: Exhibit 1 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:
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 ❤️ |
and others
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
Key concepts:
Navigation links
Key concepts:
Media links
Key concepts:
props to @getdave @jasmussen @jameskoster @SaxonF.
The text was updated successfully, but these errors were encountered: