Page MenuHomePhabricator

RFC: Section headings should have a clickable anchor
Open, NormalPublic

Tokens
"Like" token, awarded by nray."Love" token, awarded by Niedzielski."Burninate" token, awarded by osorio-juan-microsoft."Love" token, awarded by Sebastian_Berlin-WMSE."Like" token, awarded by Liuxinyu970226."Love" token, awarded by eflyjason."Love" token, awarded by Kaartic."Love" token, awarded by Niharika."Like" token, awarded by Pcoombe."Like" token, awarded by Ciencia_Al_Poder."Like" token, awarded by He7d3r."Dislike" token, awarded by Jooojay."Like" token, awarded by waldyrious."Like" token, awarded by gpaumier."Like" token, awarded by Arghman."Like" token, awarded by fbstj."Mountain of Wealth" token, awarded by Nemo_bis.
Assigned To
None
Authored By
brion, Dec 17 2008

Description

NOTE: Clickable section anchors ("§" next to page headers) were implemented and briefly deployed in March 2015. However, the specific way that clickable section anchors were added caused issues, discussed below, and the feature has been reverted and un-deployed.

Say you're in the middle of a long page and want to pass somebody a link... A link to the particular section would often be more helpful than just a link to the top of the page, but to do that right now you have to jump up to the table of contents and find your section again, then click that link.

It would be nicer if the section header itself were clickable, or had a little link anchor thingy you could click next to it that had the #blah bit on it to cut-n-paste or drag-n-drop.


Supplement

Requirements

  1. the feature is "activated" by hovering the header text;
  2. the link is offered in a symbol of some sort next to the header text, similar to what many do;
  3. the link is a normal one, i.e. left-click centers the section (but does not copy to clipboard) and right click + copy link can be used.

Things to watch for and possibly avoid

  1. The section symbol is being read aloud by screen readers when navigating the page by headings.
  2. The symbol appears in unexpected places due to being included in HTML (like Geohack or Google search results).
  3. Literal headings (<h2> etc.) should not have clickable section link anchors (T91271).
  4. No way to hide the symbol where it negatively affects the design (mostly main pages).
  5. The symbol § could be confusing, possible alternatives: #, , 🔗 (last one is emoji, not widely supported), Link_icon.svg.

Possible blockers or subtasks

  1. T13555: .mw-editsection links should not be part of the <h#> element
  2. ...

Workarounds

See also

Details

Reference
bz16691

Related Objects

Mentioned In
T225174: Add anchor links for each section header
T216214: Add Header for Wikidata Properties page's Sitelinks div to make it more accessible
T210822: Reconsider section heading marker ("→") in edit summaries
T76629: Numeric anchor in phabricator to link to a comment of a task does not work in IE11
T125865: Assign RFCs to ArchCom shepherds
T114851: Add more adequate interface for linking to topics
T54813: Remove "Show table of contents (for pages with more than 3 headings)" user preference from MediaWiki core
T93682: Added § symbol to 'See more' in the Image Gallery
rMW6b64c32e200d: Emergency remove .mw-headline-anchor
rMW520540538539: Emergency remove .mw-headline-anchor
T93187: Uncaught “URIError: malformed URI sequence” on en.wiktionary (fixed in jquery.cookie >= 1.4.0?)
T93000: [Regression] Google is indexing "§" characters in search result excerpts
T91865: Grey symbol on left side appearing when hovering over sections title
T91381: Comments lost in phabricator ticket T18691
rMWd5f4e01f7c7f: Hide section anchor links from screen readers using aria-hidden
rMWd2a6a73d2974: Hide section anchor links from screen readers using aria-hidden
T89690: Longer Maniphest tasks not fully displayed (as Phabricator defines a result set limit as 100 rows)
T91093: Document when to use Wikicon link icon vs. section sign '§'
T90091: Improve the UX of section anchor links
T90019: [Regression pre-wmf19] Headline anchor appearing next to all heading in Readmode
rMW6c7480e5f03e: Add clickable link for section headers
T88220: Remove overflow:hidden for headings
T86223: ToC: links to topics within the board, do not change the URL in the address bar
T78232: Make Special:Preferences preference heading IDs (for linking) discoverable
Mentioned Here
T72004: h4, h5, and h6 headers should not have the same styling
T181195: Add a share button to the mobile site (starting by enabling in beta)
T89850: "Email this page" feature
T120487: Cite : Share : Export (Consolidate and replace a variety of items on the sidebar)
T13270: Make section edit links more usable/understandable
T29027: "Share" button (tools) extension for Wikimedia projects
T96515: Replace [edit | edit source] next to section title with edit pencil at the right end of the line
T210822: Reconsider section heading marker ("→") in edit summaries
T93000: [Regression] Google is indexing "§" characters in search result excerpts
T91271: Literal headers should not have clickable section link anchors
T13555: .mw-editsection links should not be part of the <h#> element
T91093: Document when to use Wikicon link icon vs. section sign '§'
T90091: Improve the UX of section anchor links
T88220: Remove overflow:hidden for headings

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I'm guessing this is something one of the WMF teams wants to own, but in terms of community contributions, is there anything we can do to help move this along?

I can't speak for everyone, but I am pretty sure that no WMF team is currently interested in working on this. I think we would be happy to accept a patch for this, as long as it avoids the problems that resulted in the last attempt in 2015 being reverted. I think my comment from that time is still an adequate summary: T18691#1098570.

kchapman moved this task from Backlog to Inbox on the TechCom-RFC board.Feb 6 2019, 10:27 PM

Moving back to TechCom Inbox for further discussion, since there is some interest from outside the WMF in making a contribution.

FWIW I am planning to work on a design for this in the next week or two.

@osorio-juan-microsoft and I work on a wiki that has a lot of traffic coming directly into sections instead of pages, so we are working on a design that will mitigate the issues mentioned in T18691#1098570.

In order to do this, we will address the following concerns that MediaWiki community has about this feature:

  • We will use an icon instead of a symbol for the link, because: section symbols will be read aloud by screen readers when navigating the page by headings, which creates usability issues; the symbol appears unexpectedly in search engine results preview, due to being included in HTML; using a widely-recognized icon for links (instead of "§") increases usability.
  • We will hide the icon from screen readers by using an aria-hidden tag.
  • We will make literal headings (<h2> etc.) not clickable, because header tags are used in boxes with fancy formatting, and the addition of a symbol is disruptive.
  • The link anchor should be hidden on Main Page and only show on content pages.
  • Our solution will handle the case where text is right-to-left.

We plan to make this a configurable option, so that wiki admins can decide for their own wikis whether this feature should be turned on.

Our solution will be a clickable link icon showing up upon mouse hover-over.

We hope to share this work with the community once we are done :)

Please carefully test cases like:

[[File:Foo.png|thumb|left|Left floating object]]
== Heading ==
This comment was removed by Dvorapa.

@osorio-juan-microsoft and I work on a wiki that has a lot of traffic coming directly into sections instead of pages, so we are working on a design that will mitigate the issues mentioned in T18691#1098570.

[..]
I'm not a designer, but personally I think this looks like a promising approach. Thanks for sharing!
Out of professional curiosity: Are you planning to measure the impact of this change on users' reading/linking behaviour in any way?

Please carefully test cases like:

[[File:Foo.png|thumb|left|Left floating object]]
== Heading ==

Thank you, @osorio-juan-microsoft and I will make sure to do that!

Msftwikipmey added a comment.EditedFeb 12 2019, 6:04 PM

@osorio-juan-microsoft and I work on a wiki that has a lot of traffic coming directly into sections instead of pages, so we are working on a design that will mitigate the issues mentioned in T18691#1098570.

[..]
I'm not a designer, but personally I think this looks like a promising approach. Thanks for sharing!
Out of professional curiosity: Are you planning to measure the impact of this change on users' reading/linking behaviour in any way?

Thank you! Yes. We will be measuring two things:

  1. How many people visit our wiki via direct link to a section from outside of the wiki. (We currently have telemetry data to show us that there is a significant group of users who do this, which was why we believed this feature is valuable to our customers, but we expect to see this number to go up even more, because after this feature implementation, linking to a section would be much easier.)
  2. How many clicks (mouse left- or right-clicks) are done to these section header anchors. We hope to see that the majority of users who use links to section headers would choose to use this feature, rather than going to TOC to copy links.

We build our telemetry on Microsoft Azure Application Insights, which means our telemetry work for this feature won't fit every wiki out there. If the community is interested, we can share some numbers to show the impact on our wiki though.

Gnom1 removed a subscriber: Gnom1.Feb 12 2019, 6:09 PM
Krinkle updated the task description. (Show Details)Feb 13 2019, 3:36 AM

Just caught up with the history here and wanted to make sure @Msftwikipmey and @alexhollender, who are both working on a design for this feature, know about each other.

A few questions & thoughts regarding the design here:

  • Would it be beneficial to make this available without having to hover over the page title? I believe it would increase discoverability, decrease complexity of interaction, and minimize elements on the page jumping around.
  • Might we think about this more as a "share" feature, rather than an "obtain link" feature? Perhaps the nuance is subtle, but I think it might make sense to focus on (what I'm guessing will be the most common) intent, which is wanting to share a section with someone, rather than the more technical aspect which is obtaining the link to the section. "Share" also feels like an appropriate companion to "Edit", in that they are both actions you can take on the section.

Below are some designs for how this might look. The two main dimensions are: right vs. left positioning, and label vs. icon vs. icon+label. My current opinions:

  • Icon+label feels heavy in this context, and icon-only isn't clear enough. I think it works best just with a label.
  • When the links are on the right they feel easier to pickup on when scanning the page. It also feels less cluttered than when they are on the left.
right alignmentleft alignment
label + icon
label only
icon only

I will follow up in the next week with some ideas for how to handle somebody clicking on the "Share" link.

@Milimetric thanks for the heads up. FYI @Msftwikipmey.

  • Would it be beneficial to make this available without having to hover over the page title? I believe it would increase discoverability, decrease complexity of interaction, and minimize elements on the page jumping around.

totes agree. I think it would be best to find the balance between obvious and distracting.

  • Might we think about this more as a "share" feature, rather than an "obtain link" feature? Perhaps the nuance is subtle, but I think it might make sense to focus on (what I'm guessing will be the most common) intent, which is wanting to share a section with someone, rather than the more technical aspect which is obtaining the link to the section. "Share" also feels like an appropriate companion to "Edit", in that they are both actions you can take on the section.

I will follow up in the next week with some ideas for how to handle somebody clicking on the "Share" link.

Perhaps if we used the link icon we could just change the url in the address bar (and copy it to their clipboard?). I suppose you could do the same with the share icon, but I would expect that to open a modal or an anchored dialog...

Niedzielski added a subscriber: Niedzielski.
  • Would it be beneficial to make this available without having to hover over the page title? I believe it would increase discoverability, decrease complexity of interaction, and minimize elements on the page jumping around.

For section headers, I totally agree. A concern of mine is regarding sub-headers, where the sub-header is not separated from the body of text to follow. If icons and/or labels are added after these, without a visual separation (the horizontal line), readers might confuse the Share button as part of content. Here is an example of sub-headers, from Wikipedia page about Obama.

In the case of the wiki my team services, links to sub-sections are also highly sought-after, which is why we initially proposed the hover-over solution.

  • Might we think about this more as a "share" feature, rather than an "obtain link" feature? Perhaps the nuance is subtle, but I think it might make sense to focus on (what I'm guessing will be the most common) intent, which is wanting to share a section with someone, rather than the more technical aspect which is obtaining the link to the section. "Share" also feels like an appropriate companion to "Edit", in that they are both actions you can take on the section.

I think this is a great observation. Just want to add one bit onto it: it would be nice if the Sharing function is able to provide an internal wiki link as well as an external one. In my experience, based on the data that I have for the wiki that my team services, there is significant amount of traffic coming into sections (that happens when user visits a page like somewiki.com/wiki/some_page#some_section) from a wiki page itself, meaning that our users do have the need to share a wiki section within the wiki.

Maybe we can provide a "share within this wiki" option and a "share with email" option, after the user clicks on "Share"? :)

I think this is a great observation. Just want to add one bit onto it: it would be nice if the Sharing function is able to provide an internal wiki link as well as an external one. In my experience, based on the data that I have for the wiki that my team services, there is significant amount of traffic coming into sections (that happens when user visits a page like somewiki.com/wiki/some_page#some_section) from a wiki page itself, meaning that our users do have the need to share a wiki section within the wiki.
Maybe we can provide a "share within this wiki" option and a "share with email" option, after the user clicks on "Share"? :)

Maybe something like this icon / interaction?

Thanks @alexhollender for putting together options -

Really like the Blue links on right, label-only! Fits into the place nicely..

What happens when I click share? we should just show a toast message "link copied to the clipboard"
similar toast that shows up when you Publish an edit on Vector

Quiddity added a comment.EditedFeb 28 2019, 7:53 PM

Re: Right / Left

  • Right-floating is what I currently use (via a personal Stylus user CSS) because I find it too distracting next to the headers,
  • That's what all the Wikimedia sites originally/previously used (from 2004–2013) but it was globally changed (in Vector) to be next to the headings in 2013. (after failed attempts to do so (?) in 2007 and 2009).
    • See the detailed research that led to the 2013 change, linked at T96515#1219109 and T13270 and other links within those.
  • Some other people (like me) also disliked the change and they float it back with user CSS. E.g. A search for ".mw-editsection {float: right;}" on Enwiki (but this search only finds people using this exact string/spacing/etc, so there are probably many more)

[edit -- addendum]

  • One of the historical issues that plagued the right-floated links (when they were standard), was when they would "bunch up" under a tall navbox or a string of images. E.g. See the "April to June" heading here. There were complex docs on Help:How to fix bunched-up edit links!
  • Personally I don't advocate for or against changing the current placement, but I love that I can override it easily. And the placement as a whole is complicated because of past history.

Re: Share

  • It mustn't copy the link to the user's clipboard, because that would unexpectedly overwrite the contents of someone's clipboard. (I often have important draft content stored there, when jumping back and forth between tabs and writing content).
  • A variation on the MediaViewer popup (that Dbarratt posted above) could work well. It would need to have the internal and external links.
    • There is a similar existing precedent in the links at the top of every File: page. E.g. File:2016_Konica_Auto_S3_1.jpg click the two "Use this file" links in the top-bar, the first giving useful details on how to attribute.
  • Please see T29027: "Share" button (tools) extension for Wikimedia projects and the 4 seealso links for many prior discussions about strongly related/overlapping ideas.

Maybe something like this icon / interaction?

In addition to this externally-shareable link, I think it would be great to also have a wikilink.
i.e. Provide two links the users can copy:

1. [https://example.com/wiki/Example_page#Example_section]
2. [[Example_page#Example_section]]

It mustn't copy the link to the user's clipboard, because that would unexpectedly overwrite the contents of someone's clipboard. (I often have important draft content stored there, when jumping back and forth between tabs and writing content).

+1 for that. I feel the same for that.

In addition to this externally-shareable link, I think it would be great to also have a wikilink.
i.e. Provide two links the users can copy:

1. [https://example.com/wiki/Example_page#Example_section]
2. [[Example_page#Example_section]]

I'd prefer without underscores, and no URL-encoding:

2. [[Example page#Example section]]
  • It mustn't copy the link to the user's clipboard, because that would unexpectedly overwrite the contents of someone's clipboard. (I often have important draft content stored there, when jumping back and forth between tabs and writing content).

What if, it just updated the address bar in your browser (i.e. it went to anchored link) and you could copy it from there?

polybuildr added a subscriber: polybuildr.
Quiddity added a comment.EditedMar 1 2019, 7:30 PM

What if, it just updated the address bar in your browser (i.e. it went to anchored link) and you could copy it from there?

That's just a normal clickable anchor, and what this task was originally all about? (So, yes. Of course that'd be fine!) We could also add a clipboard icon within the popup, per the MediaViewer example and regular external practices; but that cannot be the default action of clicking on "Share".


@Msftwikipmey and @Ciencia_Al_Poder

I'd prefer without underscores, and no URL-encoding:

Yup. Also the results wouldn't need square-brackets (external links don't need them, and internal links might or might not need them (Visual Editor, various interface-forms, etc)).

It would be good to have those 2 options as a baseline (useful for all MediaWiki installations), and some (site-configurable) additional elements for wikis that have a primary external focus.

E.g. like file pages (as I mentioned above) have this:


Wikimedia wikis would want at least:

  1. External plain link + title (for sharing): https://example.org/wiki/Example_page#Example_section Example page – Wikipedia
  2. a link to [[Special:CiteThisPage]] that specifies the section (example but + #Example_section)
  3. Internal wikitext link (for editors): Example page#Example section

and possibly we would want (eventually - plan for growth&change!) these extra elements:

  1. a "Share via email" link, per T89850#1057885
  2. Permanent revision link: https://example.org/w/index.php?title=Example_page&oldid=123456
  3. Short-URL link: https://w.wiki/123
  4. other elements described in T120487: Cite : Share : Export (Consolidate and replace a variety of items on the sidebar)

(But that's all much more complicated than required/requested here. We just need a OOUI PopupWidget with 2-3 lines of text, if we go this route.)

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki?

Is it? Perhaps we should run a test on a high-traffic wiki and see which option is clicked more?

Quiddity added a comment.EditedMar 1 2019, 8:09 PM

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

I agree that the icon should be considered as an option, instead of the word "Share". That would more cleanly match the use-case of "I need the text-link to use in a wikipage" which is what all editors will want it for (in 3rd party wikis and Wikimedia wikis). And that would be less intrusive in the UI, especially if it only appeared on mouseover of the ==header== (as we were originally discussing). I'm not sure what I'd prefer/recommend (with volunteer or staff hat). It's complicated!

Is it? Perhaps we should run a test on a high-traffic wiki and see which option is clicked more?

I worry that users of different wikis will have different behaviors, which means data from any one wiki might not be fully representative. For example, on Wikipedia a page might have tens of thousands of readers but only a few editors (which means generally users would need to share more than to edit), but in the case of a workplace documentation wiki a page might be project-specific and all of its readers are working on this project, which means they also frequently change the page (hence editing is much more sought after in this case).

With that being said, maybe we could answer this question with usability research? Whichever design that has the best usability. After all, the customer pain point they are trying to solve are the same: users need to share links to sections but it is currently hard to do.

I like the idea of the share button, even though it adds an extra click to a relatively simple action. However, what are we doing to address the earlier concern of placing more actions next to the Edit action, when Edit is the most important action on a wiki? Also, do we need to consider the mobile case as well (i.e. creating a solution for mobile browsing parallel to a desktop version)?

Could the mobilefrontend skin show the icon by default, but the desktop skins show it on mouseover?

I worry that users of different wikis will have different behaviors [...]

Agreed. Perhaps this could be solved by having different solutions for different audiences? I.e.

  • logged-out users get the basic set (e.g. externally sharable link+title, cite this page, email this page),
  • and logged-in users get the "internal wiki link" added at the top, and additional items added below?

(I don't know how technically feasible that is with caching etc?)

For example, the various states on desktop/Vector could be (very roughly):

1. current state (optional, if it starts hidden and needs a mouseover)F28318033
2. visible icon (link icon or share icon or share icon)
3. clicked icon shows PopupWidget (logged-out or logged-in)
alexhollender added a comment.EditedMar 5 2019, 12:51 PM

Alright, there have been a lot of awesome ideas since I last posted here. I am attempting to address them all in these updated designs. General notes:

  • As @Msftwikipmey pointed out, the Edit (and Edit source) links are currently present for all section headers. This made me realize that the page I used for the initial designs I posted perhaps wasn't the best (since it only had <h2>s). So this time I'm using two different Wikipedia pages: one which is rather extreme (it has a bunch of headings, all the way down to <h5>), and another which is more ordinary (<h2>s and one <h3>).
  • While logged-in users with their Editing mode preference set to "show me both editor tabs" will see both "Edit" and "Edit source" actions, I've decided to focus the mockups on the more common case, which is people who only see Edit (this would be all logged out users, and all logged in users without the "both editor tabs" setting).
1) Right vs. left alignment

@Quiddity provided some useful history of right vs. left alignment of these buttons. I believe that this information, combined with the awkwardness that occurs for headings lower than <h2> with right-aligned buttons (you get buttons that are just kind of floating in space), changes my preference to left-aligned.
Preference: left

2) Do we add Share on every heading?

I think this should be configurable per-wiki. I do think the interface gets cluttered, and the actions start to distract from the content, if we include Share on every heading (illustrated below). I think a sensible start for Wikipedia would be to limit Share to just <h2>s. I do not think this changes much as the result of using an icon vs. text.
Preference: no, only <h2> to begin with

3) Icon vs. text

There have been some suggestions that we should use an icon just for the Share action. I think this would be confusing, and I don't believe it offers any additional value to the user. Looking at the example @Quiddity posted here I find the relationship between the icon and the "[edit]" text confusing. The share icon does take up less space than the word Share, but I don't feel like it makes it any less distracting.
Preference: text-only for all actions

4) Should we consider mobile?

I think it's always a good idea to consider mobile. In this case there is already an effort afoot to add Share to mobile (T181195). While the focus there isn't currently on section-sharing, there are already ideas for how to handle it, so I think we don't have to worry about it in this discussion.
Preference: don't worry about it here

5) Will Share distract from Edit?

My instinct is that no, these actions are not competing with each other. As @dbarratt suggested, perhaps this is something we can test rather straight-forwardly, if we're indeed concerned about it.

And now for the updated designs:

ordinary caseextreme case
left alignment
right alignment

To illustrate (yes, in a rather extreme way) my concern around added distraction from having Share at every heading (mentioned in point #2 above):

And now for the new designs, inspired by @Quiddity's designs above:

logged out userlogged in user

Perhaps we can start simple for logged-in users, with just the URL and the Wikitext link, and eventually build towards something more comprehensive like the "Use this file on the web" feature in Commons that @Quiddity mentioned.

Wonderful to see all of the collaboration on this ticket! This is a great topic to explore, and I like where it's gone so far.

In terms of point #5:

Will Share distract from Edit?

We should experiment with this, particularly if it's going to be an option on mobile - which, based on recent usertesting that I performed at an editathon, a lot of people use section editing type features because they are in a mobile environment as it provides shortcuts to alleviate excess scrolling.

I suspect that this will be a bit of cognitive overload for the user, showing them so many different action options. Perhaps there is a way to differentiate or uncouple the set of actions through a different style treatment?

@alexhollender in your "left alignment" designs above, the "ordinary case" and the "extreme case" reverse the order of "Edit" and "Share" ("ordinary case" has "Edit" then "Share" and the "extreme case" has "Share" then "Edit").

Was that intentional?

I think for left alignment, it should be "Edit" then "Share" since edit appears on every heading and "Share" only appears on some. Right alignment should be the reverse (which is what you have).

@dbarratt great catch — that was not intentional. I've just updated the left/extreme case mockup.

I suspect that this will be a bit of cognitive overload for the user, showing them so many different action options.

I agree with this. I prefer the hover -> link icon in gutter approach proposed earlier and used on sites like GitHub: https://github.com/wikimedia/eslint-config-wikimedia#example-configurations

I also think there is an expectation these days that 'share' will open a set of social media sharing tools, so this may make for unexpected behaviour.

Thank you @alexhollender for sharing the amazing designs :)

I agree with this. I prefer the hover -> link icon in gutter approach proposed earlier and used on sites like GitHub: https://github.com/wikimedia/eslint-config-wikimedia#example-configurations

The added visual load is also why I initially wanted it to be a hover too. I believe that although slightly less obvious than the always-present icons, the hover link can be understood by readers fairly quickly. (but it would be great if a usability person can weigh in here :D)

I also think there is an expectation these days that 'share' will open a set of social media sharing tools, so this may make for unexpected behaviour.

Agreed. Initially I was expecting that too when I heard of the "share" button. Might be unexpected for users especially on mobile.

alexhollender added a comment.EditedMar 6 2019, 3:14 PM

I suspect that this will be a bit of cognitive overload for the user, showing them so many different action options.

I agree with this. I prefer the hover -> link icon in gutter approach proposed earlier and used on sites like GitHub: https://github.com/wikimedia/eslint-config-wikimedia#example-configurations

I disagree. I do not believe that the addition of one action, only on '<h2>` elements, (resulting in two actions total for the majority of users) warrants cognitive overload. Furthermore, the expected increase in awareness by showing the link without having to hover, in my opinion, is worth the persistent presence of the action (even if it comes at the cost of causing a slight distraction).

I also think there is an expectation these days that 'share' will open a set of social media sharing tools, so this may make for unexpected behaviour.

I think this is a fair point, although I'm not sure what the downside is. Are you concerned that people won't use the action? Or perhaps that they will be disappointed not to find what they expect? By using a more technical term like "Permalink", or only an icon, I fear we will loose a large amount of potential people who are unfamiliar with the term/icon. Perhaps "Link" could work (in the sense of a verb, e.g. link someone to this section), but I imagine "Share" is closer to the user intent, and most importantly more understandable. Again, I think the upside strongly outweighs the downside here. (For whatever it's worth here is the "Share" experience on Reddit, which does not not "open a set of social media sharing tools". Google docs also comes to mind but seems less analogous since it isn't public content in most cases)

For clarification @Msftwikipmey, both @iamjessklein and I are "usability [people]" :)

Furthermore, the expected increase in awareness by showing the link without having to hover

The functionality is like going to be a fairly low-use edge case, I don't think it needs particularly high visibility.

(For whatever it's worth here is the "Share" experience on Reddit, which does not not "open a set of social media sharing tools". Google docs also comes to mind but seems less analogous since it isn't public content in most cases)

Although in that case "share" is the label for a group of actions of which one is "copy link".

Perhaps more user research is needed. Currently the only people requesting this feature are advanced users who are probably familiar with the GitHub style, but it would likely be of use to a much broader audience, and we don't really have anyone to copy. It could be the case that non-advanced users simply aren't even aware that it's possible to link to a section of a page, so wouldn't be looking for this feature in the first place.

Preference: no, only <h2> to begin with

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful, for example if I wanted to share https://en.wikipedia.org/wiki/Barack_Obama#War_in_Iraq, a sizeable section, I would have to link to https://en.wikipedia.org/wiki/Barack_Obama#Presidency_(2009%E2%80%932017), which is several full pages away from the content.

I do not believe that the addition of one action, only on '<h2>` elements, (resulting in two actions total for the majority of users) warrants cognitive overload.

By using a more technical term like "Permalink", or only an icon, I fear we will loose a large amount of potential people who are unfamiliar with the term/icon.

As a fellow "usability person" who is not a designer by any stretch of the imagination, I completely agree with what you are saying. :)

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful.

Maybe making this configurable per-wiki is a potential solution?

Preference: no, only <h2> to begin with

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful, for example if I wanted to share https://en.wikipedia.org/wiki/Barack_Obama#War_in_Iraq, a sizeable section, I would have to link to https://en.wikipedia.org/wiki/Barack_Obama#Presidency_(2009%E2%80%932017), which is several full pages away from the content.

This scenario happens all the time on our internal wiki :) There are so many articles whose sub-sections or even sub-sub-sections are specific steps/FAQs that people often want to directly point to.

waiting for product to discuss/decide on this prior to TechCom IRC meeting.

I wanted to share some additional thoughts that came up today.

I was thinking more about how to handle sharing from headings lower than <h2> in a way that didn't feel like there were Share actions scattered all over the page. I was wondering if it would make sense for the Share action on headings lower than <h2>s to only show on hover, even though this would be inconsistent with how one would Share a main section. At first this idea was exciting, but as I started to mock it realized that it is perhaps awkward to have some actions ("Edit" and "Edit source") be persistent, and have "Share" be visible only on hover. The github example that has been referenced several times in this discussion is different than our use case in that on github headers there are no actions aside from the one that appears when you hover. I mention this because I think the fact that we have persistent actions near headers would only further contribute to the lack of discoverability of hover actions, not to mention it just seems a bit awkward to have both persistent and hover-only actions on an element. In any case here is a mockup of how it could possibly work to show Share only on hover for headings lower than <h2>:

texticon

Side note: I still support the idea of making this a configurable setting. For Wikipedia it'd be great to get data on what percentage of articles use <h3>, <h4>, etc. — I've reached out to @Tbayer for suggestions on how we might get that data.

[...] At first this idea was exciting, but as I started to mock it realized that it is perhaps awkward to have some actions ("Edit" and "Edit source") be persistent, and have "Share" be visible only on hover.

I think I said it above, but just to reiterate: Personally I do like the idea of "share only appears on hover" for all headings (h2 and below) on desktop, because:

  • the appearing link helps remind readers that they can edit at all (those [edit] links tend to get ignored after years of looking at them, like "banner blindness")
  • it's not part of the content, and keeping the page as clean as possible has always been an aesthetic goal (why we're so minimal/plain in design), in order to make the content stand out.

Side note: I still support the idea of making this a configurable setting. For Wikipedia it'd be great to get data on what percentage of articles use <h3>, <h4>, etc. — I've reached out to @Tbayer for suggestions on how we might get that data.

There are some old (2015) stats on H5 & H6 usage at Enwiki, at T72004#1407800 which halfak kindly generated for me back then (it was an overnight query on the stats boxes)

As a Wikipedia editor, I frequently need to link to subsections of discussion pages, and of policy/guideline pages, which are commonly H3s or lower. E.g. https://en.wikipedia.org/wiki/Wikipedia:INSOURCE - this is partially why we had to invent the hack of "shortcuts", to save the frustation of having to copy&paste from the page-title and subsection independently (or remove the underscores from the URL).

Maybe if we're afraid of too many links next to each header, we can consider to have only two: the edit link, and a "more..." link, that when clicked could expand to a list of actions (link to that section, share, copy link for use on an edit...). Even the edit link can be made expandible if we have the dual edit link (wikitext edit, visual editor edit). Just an idea.

waiting for product to discuss/decide on this prior to TechCom IRC meeting.

Wanted to confirm that we met with @Msftwikipmey and @osorio-juan-microsoft to discuss potential implementation options, the result of which is reflected in @alexhollender's comment T18691#5024680. So far, it seems we're aligned and ready to move forward with this task. Our next steps would be to agree on a potential implementation and answer all open questions (currently around configuration of depth of the headers as well as other configuration options such as the exact wording of the link). We'll keep this task updated with progress.

...

Side note: I still support the idea of making this a configurable setting. For Wikipedia it'd be great to get data on what percentage of articles use <h3>, <h4>, etc. — I've reached out to @Tbayer for suggestions on how we might get that data.

There are some old (2015) stats on H5 & H6 usage at Enwiki, at T72004#1407800 which halfak kindly generated for me back then (it was an overnight query on the stats boxes)

Thanks! Do you happen to still have the underlying database query and could post it here so we could re-run it?
In the meantime, here are some dump-based numbers for two Wikipedias (I'll try to run this for enwiki too), for mainspace pages:

itwiki:
total number of articles: 1510504
... with Level 2s: 1417437 = 93.839%
... with Level 3s: 473253 = 31.331%
... with Level 4s: 92182 = 6.103%
... with Level 5s: 8402 = 0.556%
... with Level 6s: 588 = 0.039%
... with Level 1s: 12 = 0.001%

barwiki:
total number of articles: 27833
... with Level 2s: 24446 = 87.831%
... with Level 3s: 2888 = 10.376%
... with Level 4s: 262 = 0.941%
... with Level 5s: 17 = 0.061%
... with Level 1s: 7 = 0.025%
... with Level 6s: 2 = 0.007%

(data source)

...

In the meantime, here are some dump-based numbers for two Wikipedias (I'll try to run this for enwiki too), for mainspace pages:

And here is the result for enwiki:
total number of articles: 5817124
... with Level 2s: 5500191 = 94.552%
... with Level 3s: 1282941 = 22.055%
... with Level 4s: 172667 = 2.968%
... with Level 5s: 13084 = 0.225%
... with Level 6s: 763 = 0.013%
... with Level 1s: 443 = 0.008%

(data source - btw this took 5h 28min, thankfully PAWS did not kill the process)

Thanks! Do you happen to still have the underlying database query and could post it here so we could re-run it?

I searched and asked, but we do not have it available anymore, sorry.

While the stats on heading levels usage are interesting, I'm not sure they will help with the dilemma: If a heading is commonly used that makes the case for both adding the sharing links and that adding those links will clutter the interface. Conversely for less-used headings it is safer to drop the sharing links, but also won't help will reducing clutter.

What might be helpful would be knowing how much content appears under each heading level, however that would be a much more complex thing to calculate.

For shorter articles that don't have any/many h3's that might be fine, but for feature-article length pages it would be not very useful.

Maybe making this configurable per-wiki is a potential solution?

I'm not sure how that solves the problem for our big wikis? Or are you thinking of other use cases?

Moving this to blocked on others pending our follow-up meeting with @Msftwikipmey and @osorio-juan-microsoft.

nray awarded a token.Apr 3 2019, 5:53 PM

Change 513234 had a related patch set uploaded (by Juan Osorio (Microsoft); owner: Juan Osorio (Microsoft)):
[mediawiki/core@master] Adds a Share widget to the Section Headers

https://gerrit.wikimedia.org/r/513234

This is the current implementation I have pushed:

Looking forward to your feedback/questions!

Looking forward to your feedback/questions!

Looks good to me. It may be useful to also discuss it on the mailing lists to get more input

Quiddity added a comment.EditedMay 31 2019, 5:13 PM

This is the current implementation I have pushed:

  1. Overall: Looks great to me. :)
  2. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?
  3. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Looking forward to your feedback/questions!

The screenshot looks great.

  • would it be possible to test the feature out?
  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel? The easiest way to inspect the styling of them might be from here. Here is a screenshot of the panel I'm referring to:
  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

+1

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

+1

  1. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?

By this, do you mean we should place the subsection title as-is after the # on the Wikitext version? Or just replace underscores with spaces?

  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Definitely. Do you at WMF have a test site we could deploy this to? From our end we currently don't have the capacity to open up a place where everyone can test out the feature.

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

I think this is part of the Popups extension. Correct me if I'm wrong, but I think what we should do is update the WikimediaUI styles for OOUI PopupWidget to match the Popups extension. The alternative is to use the Popups code, but as this is part of the core I think that would be more difficult.

  1. Would it be possible to strip the underscore _ character out of the Heading_text in the Wikitext version?

By this, do you mean we should place the subsection title as-is after the # on the Wikitext version? Or just replace underscores with spaces?

I think I mean the former? I'm not entirely clear on what the technical distinction would imply. :-) The main thing I want to avoid, is having to manually replace the underscores with spaces, which I currently have to do whenever I copy part of the URL from the browser-address-bar. (I/we remove the underscores because otherwise they lead to linewrap issues, as well as being not an actual part of the title).

  1. I suggest running tests on multilingual content, especially non-latin characters and right-to-left languages.

Definitely. Do you at WMF have a test site we could deploy this to? From our end we currently don't have the capacity to open up a place where everyone can test out the feature.

We do have a Cloud VPS infrastructure that you could use for this, with extensive documentation at https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS

Alternatively, you could simply copy some strings of text from existing projects. I tend to just pick whatever the Featured Article of the day is from the main page. E.g. https://ja.wikipedia.org and https://fa.wikipedia.org - then add e.g. ?uselang=ja to the URL to change the interface language (and direction for RTL languages).

The main complexity (based on my limited understanding) is making sure the feature does not turn 白血病#概要 into %E7%99%BD%E8%A1%80%E7%97%85#%E6%A6%82%E8%A6%81 (as it does when I copy the full URL from the address-bar).

Perhaps some developers already watching this task can give better suggestions for how to test this kind of thing?

I think I mean the former? I'm not entirely clear on what the technical distinction would imply. :-) The main thing I want to avoid, is having to manually replace the underscores with spaces, which I currently have to do whenever I copy part of the URL from the browser-address-bar. (I/we remove the underscores because otherwise they lead to linewrap issues, as well as being not an actual part of the title).

I have to think about this one because it should still be valid Wikitext for subsections with special characters like ] (closing square bracket)

The main complexity (based on my limited understanding) is making sure the feature does not turn 白血病#概要 into %E7%99%BD%E8%A1%80%E7%97%85#%E6%A6%82%E8%A6%81

What it looks like after playing around a bit:

Notice that the actual URL has some escaped characters. This behavior is taken from the TOC and is consistent with it.

Also, check out the widget with RTL rendering:

  • for the styling of the Share panel, would it be possible to match the styling of the existing page preview panel?

I think this is part of the Popups extension. Correct me if I'm wrong, but I think what we should do is update the WikimediaUI styles for OOUI PopupWidget to match the Popups extension. The alternative is to use the Popups code, but as this is part of the core I think that would be more difficult.

I wonder if @Jdrewniak @thiemowmde or @Jdlrobson might be able to provide some technical guidance here, as I am unfamiliar with the code.

I would suggest not to call any code from the Popups extension (tagged as Page-Previews here on Phabricator, as well as Reference Previews). I would also suggest not to reuse the design from the Popups extension. I mean, there is not really anything wrong with this design. It still fits quite well with the current style guide. But it's outdated and much older than the current OOUI styles. Please stick to the OOUI PopupButtonWidget.

Technically, the design of the popup windows as shown by the Popups extension can only be reused if you are fine with having very strict, pixel-based size constraints (always 320px wide).

There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):

There is now an mw.widgets.CopyTextLayout in core, as used on the URL shortener (https://meta.wikimedia.org/wiki/Special:UrlShortener):

Yes, @Fomafix mentioned it on the Code Review. I have since changed my patch to use it. I have also added some changes to that widget: being able to select partial text from field, and being able to style it as seen in the Section Header Share widget.