Page MenuHomePhabricator

RFC: Section header "share" link
Open, NormalPublic

Tokens
"Love" token, awarded by Quiddity."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

Today, it is hard to share links to sections of wiki pages. Sections on a page don’t have their own links, except for in the Table of Content at the top of the page. If the page is long, the reader has to scroll all the way to the top to pinpoint the link to the section they want to share.

This task aims to make it easier for wiki readers to share links to sections of wiki pages, both "external" links (direct URL to the section) and "internal" links (wikitext for internal links).

The implementation looks like this:


Supplement

Things to watch for

  1. Accessibility: the section section share link is being read aloud by screen readers when navigating the page by headings.
  2. Internationalization: the section share link should work for both left-to-right and right-to-left reading.
  3. Literal headings (<h2> etc.) should not have clickable section link anchors (T91271).

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

StatusAssignedTask
OpenNone
OpenNone

Event Timeline

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

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.

@Esanders @alexhollender I have removed some of the extra styles so that the copy field looks the same as the other CopyTextLayouts.

@Esanders @alexhollender I have removed some of the extra styles so that the copy field looks the same as the other CopyTextLayouts.

Looks awesome 👍

Elitre removed a subscriber: Elitre.Thu, Aug 29, 9:08 AM
WDoranWMF added a subscriber: WDoranWMF.

I'm going to move this into CPT's clinic duty for review but we'll need the merge conflict resolved first if that's ok.

I'm going to move this into CPT's clinic duty for review but we'll need the merge conflict resolved first if that's ok.

Fixed merge conflict. Thanks!

On https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513234, @daniel commented:

Note that this functionality is subject to an ongoing RFC, T18691.
It should not be merged until that RFC has been approved.

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.
  2. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

It seems that the design questions are resolved and the implementation is under review. Should the RFC be scheduled for discussion at TechCom?

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.
  2. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

W.r.t...
#1 - The design has indeed evolved quite a bit as we work with @ovasileva @alexhollender to the section anchor more usable and intuitive. We can update the description of this RFC.
#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

Josve05a removed a subscriber: Josve05a.Thu, Sep 12, 7:28 PM

#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

It means enabling it on at least some of the WMF sites. Whether it's part of core or an extension isn't so relevant.
The original RFC has been filed with the idea of having this enabled on Wikipedia and friends, but I'd like to have explicit word on that from the relevant WMF folks.

  1. We don't know if this is proposed purely as a third party feature, or for deployment on WMF systems. If it's just for 3rd parties, it may not even need an RFC, and could perhaps be done as an extension as well. If it's for WMF production, we will have to look very closely on the implications for caching and overall performance.

Offering a technical perspective: the current implementation of this feature relies on some changes to the Parser output and the Skin template, which require changes to the core. In order to accomplish the same in an extension, there still needs to be some change in the core - specifically to provide the anchor values on the SkinEditSectionLinks hook (which means all the changes except the actual adding of the 'share' link would need to go into the core anyway). I think because of this it makes more sense to have this as a core change. It is still configurable through $wgEnableSectionHeaderShare global, which is off by default. When the value is false, no extra logic or JavaScript/CSS resources are invoked by the feature.

@osorio-juan-microsoft Thanks, that does sound like it would be difficult to do this in an extension. And if we (WMF) don't enable it, it probably wouldn't need an RFC. But if we are planning to enable it on WMF sites, it will need a closer look.

#2 - Does "deployment on WMF systems" mean to make this part of MediaWiki core software? I think this has always been the expectation, which is why it has gone through many iterations of design, i18n and perf improvement :) Could WMF friends chime in to confirm this is still the case?

Yes, we are planning on enabling the feature on en.wiki once it becomes available.

Yes, we are planning on enabling the feature on en.wiki once it becomes available.

Thank you for clarifying, Alex!

Krinkle renamed this task from RFC: Section headings should have a clickable anchor to RFC: Section headings with clickable anchor.Wed, Sep 18, 7:54 PM
Msftwikipmey renamed this task from RFC: Section headings with clickable anchor to RFC: Section header "share" link.Wed, Sep 18, 8:34 PM
Msftwikipmey updated the task description. (Show Details)

We did briefly discuss it in the TechCom meeting yesterday. Two issues have come up:

  1. The proposal in the task description is quite different from what has been implemented. For this to progress as an RFC, the task description has to be updated to reflect what we are actually deciding on.

The task description has been updated to reflect what was actually designed by @alexhollender and implemented by @osorio-juan-microsoft :)

daniel moved this task from Under discussion to Inbox on the TechCom-RFC board.Thu, Sep 19, 9:37 AM

Putting this in the RFC inbox for discussion.

I assume the idea is to get approval on this. So the next step could be a public meeting for discussion. Or we could go directly for last call. A TechCom member will probably want to have a closer look beforehand, though.