Wikimedia Bugzilla is closed!

This mis-understands the menu - the "chain icon" launches the link inspector, but there are potentially quite a few icons in the user's context at this point. We only have the link inspector created at this stage, but we will have more before the VisualEditor is "finished".

For the first enhancement, this was fixed in bug 37904 but that has regressed - have re-opened that one.

I remain unconvinced. What other "inspectors" do you want to call on a link? (An "Open link in new tab" inspector? If yes I propose to integrate such special case functions in the link inspector itself to keep things simple and avoid decisions steps up front). 

I fear it will be an even worse user experience if users have to choose between various "inspectors" for a link. And I fear the choices will be hard to make until they have read a couple of help pages. This is not what I hope the VE will achieve...

I would prefer a bit of object-oriented context smartness. Perhaps, to satisfy the generic design (I can imagine some alternative choices for some other objects...): why not skip the "choose an inspector" step if there is only one choice for a given object in a given context? This would easily support cases where an object may truly need a choice of inspectors, but avoid the clumsiness of the current approach.

(Note that the tooltip enhancement does not help on modern touch devices, so making the interaction with links to check link correctness painless remains an issue.)

(In reply to comment #2)
> I remain unconvinced. What other "inspectors" do you want to call on a link?

It's not "on a link", it's "on some text" - yes, this includes links if one is set, but there will be quite a few annotation inspectors; in complex cases, we may need to come up with a new interface if it ever got about half a dozen or so. What you're seeing is an artefact that we haven't written the other annotation inspectors yet - not that they aren't applicable. For example, we'll be creating (or helping others create) annotation inspectors for setting the selection's language (as used on the English Wikipedia through a template, but invaluable to our multi-lingual wikis), modifying text colour and other funky formatting, marking up the content as an address (as used through an extension in Wikivoyage) or as a status update (used on MediaWiki.org), and no-doubt several others that we haven't even thought of yet.

Note that this menu (which is purely about annotation inspectors) doesn't trigger on text that isn't already a link, as we don't show it when there are no appropriate annotation inspectors for the context.

There will also be a bunch of object inspectors for "complex" things like references, templates, images and other media, galleries, Wikidata transclusions and queries, music annotations, maths equations, EasyTimeline uses, code blocks with syntax highlighting, poems, and dozens of other things that are block-level parser hooks of some kind, as tailored to the wiki and within that to the context. And, of course, this list will expand over time as the number of things that can be created and edited through the VisualEditor approaches completeness for Wikimedia's cluster install, and for third parties using MediaWiki in their own situations.

Finally, there will be a page-level inspector for page-level meta-data - like categories and language links, the "magic words" that perform title over-rides, redirects, suppression of the table of contents, etc.

[Snip]

> I fear it will be an even worse user experience if users have to choose
> between various "inspectors" for a link. And I fear the choices will be
> hard to make until they have read a couple of help pages. This is not what
> I hope the VE will achieve...

Certainly, part of our job is to make a complex task as simple as possible - but, to steal the phrase, no simpler. I fear that we haven't explained the concept of annotation inspectors in the design language well enough for the above to be clear, for which I apologise.

> I would prefer a bit of object-oriented context smartness. Perhaps, to
> satisfy the generic design (I can imagine some alternative choices for some
> other objects...): why not skip the "choose an inspector" step if there is
> only one choice for a given object in a given context? This would easily
> support cases where an object may truly need a choice of inspectors, but
> avoid the clumsiness of the current approach.

This would mean that, as you move the cursor through the text, every time you hit a link, the link inspector would load, filling the screen (and triggering a wasteful and unwanted API request to get the suggested list of pages for the link text). Clearly for you, this would be appropriate, but I don't agree that it's an interface paradigm that would work for most users.

> (Note that the tooltip enhancement does not help on modern touch devices, so
> making the interaction with links to check link correctness painless remains
> an issue.)

Sorry, but this is not true. In an iPad or Android tablet or mobile 'phone, press and hold on a link to be informed of the link's title attribute; voilà, the link destination is revealed. Yes, this is messy, but our job is to be as seemless as possible in integrating with users' operating systems' existing workflows, not inventing our own.

What you explain is pretty depressing. Just the necessity to learn all the icons for all the rare-to-be-used "inspectors" that will accumulate over time sounds like it may continue to prevent a majority of people from editing ... I fear it is dangerous if programmers try to design the user interface for normal people.

The method used by Google docs works really well for me: when clicking on an existing link, it directly shows the link target and offers "change" and "remove". Nice, simple, accessible, intuitive. And all the other non-context sensitive options for normal text stay in the menu and button and can be accessed from there. No toolbar full of accessor/inspector items that moves with the cursor and prevents reading.