Last modified: 2014-05-17 09:01:30 UTC
"What links here" is MediaWiki's best kept secret. Hidden in a misleading "Toolbox" in a crowded left navigation bar, surely it is not found by many users that would enjoy this feature. Imagine that link in a more prominent spot, as a tab: | Page | Talk | Context | Where "Context" == "What links here". This is where it actually belongs. Example: You are very interested about http://en.wikipedia.org/wiki/Simeon_%28Hebrew_Bible%29 (random article) After reading the article you can check the discussions about it http://en.wikipedia.org/wiki/Talk:Simeon_(Hebrew_Bible) And then you can also check the pages that link to it, obviously related http://en.wikipedia.org/wiki/Special:WhatLinksHere/Simeon_%28Hebrew_Bible%29 Neat. This proposal is not perfect. Ideas welcome: * Discussion pages also have "What links here" so how should we treat this. In my own experience I use this feature often for articles, almost never for discussions (and when I try most time there are zero results). * Yes, I'm aware of the issues reported about What Links Here and I do suffer them as well (mildly). Still, I keep using this feature regularly because it is useful and awesome. I believe highlighting it would give us a better idea of the pain points (if any) for regular users and perhaps more developer attention from volunteers would be put here.
(In reply to comment #0) > * Discussion pages also have "What links here" so how should we treat this. > In > my own experience I use this feature often for articles, almost never for > discussions (and when I try most time there are zero results). "Context" is still a valid definition: if there are other pages or discussions linking the discussion, they probably contain context. I almost always check whatlinkshere when I'm interested in a discussion, and add crosslinks between related discussions. I don't know what position and name would be the best, but in the case of tabs it would probably make sense to hide it when there are no incoming links (other than redirects): either forcing it to be in the dropdown; or removing it altogether and moving it to the toolbox as it currently is. If a varying position is confusing, the toolbox link could be kept and the tab be used in addition to rather than as a replacement; this could be useful also for those with narrow screens where the additional tab would be automatically hidden in the dropdown. This specific proposal shouldn't IMHO be regarded as a way to address bug 43170: removing one item doesn't help that; this is rather a way to work around the problem, unless we find new positions for a majority of links of sidebar/toolbox(es), or there's universal consensus that the other links are completely useless in comparison (unlikely, even if we consider only readers).
Personally I think the last thing we need is yet another tab. The tab as a unit of organization is not something that scales well, especially to minor or tangential pieces of metadata about an article.
(In reply to comment #2) > Personally I think the last thing we need is yet another tab. The tab as a > unit of organization is not something that scales well, especially to minor or > tangential pieces of metadata about an article. I agree. The current bug summary is: Morph "What links here" into a "Context" tab next to "Talk". I'm changing the bug summary to be more inline with what I think is actually being requested: Find a better way to expose "What links here" functionality to readers. I agree with the general premise of this bug: the toolbox sidebar section (and consequently Special:WhatLinksHere) is trivial to overlook, particularly in the Vector skin, with its collapsible sidebar sections.
MZMcBride: Broadening the scope of a bug report by changing the subject to "Find a better way to do x", instead of describing either the problem to solve or the specific change requested, is almost certainly making it impossible to fix the report.
I agree with Andre. I defined a problem and a specific proposal. You can disagree with the problem or with the solution proposed, but then provide better arguments. If a tab is not the right solution, then what?
(In reply to comment #4) > MZMcBride: Broadening the scope of a bug report by changing the subject to > "Find a better way to do x", instead of describing either the problem [...] Not if "x" describes the problem (e.g., "[better] expose 'What links here' functionality to readers"). Don't be silly. (In reply to comment #5) > I agree with Andre. I defined a problem and a specific proposal. Sort of. Bug reports exist to describe problems or potential feature requests. You have to guard against attempting to simultaneously both identify and diagnose an issue (something we're all occasionally guilty of). As I understand it, the bug here (as now described in the bug summary) is that the exposure of Special:WhatLinksHere to readers is currently insufficient. A possible remedy or resolution to this bug is adding a "Context" tab to the top of the page. If you truly believe that this bug should focus only on adding a "Context" tab to the top of the article, you're free to revert the change to the bug summary, but it seems quite likely that this will result in the bug being marked resolved/wontfix. > You can disagree with the problem or with the solution proposed, but then > provide better arguments. If a tab is not the right solution, then what? I agree with the problem and I disagree with your proposed solution. I said this almost explicitly in comment 3, but I'm happy to repeat it here in comment 6. This is a tricky design question that may not have an obvious answer. That's okay. The myth that all bug reports be immediately actionable is soundly and roundly debunked by this bug report and many, many others. Sometimes the right answer isn't apparent or simply isn't ready. For example, a complete redesign of the user interface, abolishing the space-wasting sidebar, may ultimately be the approach taken here. But that isn't to say that a less drastic or dramatic approach can't also work to resolve this bug.
(In reply to comment #6) > This is a tricky design question that may not have an obvious answer. That's > okay. The myth that all bug reports be immediately actionable is soundly and > roundly debunked by this bug report and many, many others. Not all tickets need to be immediately actionable. But it must be possible to define when a bug report can be considered FIXED, in this case: When is the exposing "good enough".
