https://bugzilla.wikimedia.org/show_bug.cgi?id=43064
--- Comment #3 from James Forrester <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
