Page MenuHomePhabricator

[EPIC] Fixed "sticky" site header
Closed, ResolvedPublic

Assigned To
Authored By
ovasileva
May 24 2021, 2:17 PM
Referenced Files
F34704927: Screen Shot 2021-10-21 at 11.58.57 AM.png
Oct 21 2021, 4:59 PM
F34704924: Screen Shot 2021-10-21 at 11.59.03 AM.png
Oct 21 2021, 4:59 PM
F34671345: image.png
Oct 4 2021, 5:26 AM
F34607524: sticky table header.webm
Aug 20 2021, 12:05 AM
Tokens
"Party Time" token, awarded by Jdlrobson."Yellow Medal" token, awarded by Ladsgroup."Love" token, awarded by alexhollender_WMF.

Description

Background

As a part of the Desktop Improvements project, we are planning on introducing additional functionality that allows access to commonly used tools previously available only at the top throughout the page via a “sticky” or “fixed” header. Our goal is to make it easier for readers and editors to access the tools they frequently need without needing to scroll all the way to the top of the page.

Use Cases

As a reader, I want to know what article I’m reading at all times, so that I can easily orient myself within the site
As an editor, I want the ability to access important functionality (e.g. edit, go the the history page or the talk page of the article) from anywhere in the page, so that I do not waste time when scrolling up
As a multilingual reader, I want the ability to switch languages at any point of my reading experience, so that I can switch directly after I find a confusing word or sentence

Feature description and requirements

MVP
A sticky/fixed header will appear at the top of the page once a user scrolls past the current header on the page.
For logged-in users, the header will contain the following:

  • Wiki logo
  • User tools menu (see user tools page)
  • Search
  • Page name
  • Section name
  • Link to talk page
  • Link to history page
  • Link to source and/or edit (following the preferences of the wikis itself)
  • Language switching functionality

The scrolling behavior of the header must adapt to the needs of logged-in users. Initial scrolling behavior will be for the sticky header to be persistent once the header of the page has been scrolled through
The header must be adaptable at lower screen resolutions (down to 500px)

Second iteration
For anonymous users, the header will contain the following:

  • Wiki logo
  • Search
  • Page name
  • Section name

The scrolling behavior of the header must adapt to the needs of users. Adjustments to triggers might be made after first iteration of sticky header.

Bugs to the above features will be considered a part of the feature work for the feature. Any additional work outside the above requirements will be tracked in a separate epic.

Design

Prototype (note: you have to login to see the sticky header): https://di-community-round-2.web.app/Audre_Lorde

Quantitative testing

We will be monitoring the before and after usage of the links included in the sticky header on our pilot wikis following our initial deployments. We expect to see a small but significant rise in access to some of these links, in particular, to the talk page and history page.

Related Objects

StatusSubtypeAssignedTask
Resolvedovasileva
Resolvedssastry
Resolvedssastry
Resolvedcscott
OpenNone
Resolvedcscott
Opencscott
Resolvedmatmarex
DeclinedNone
DeclinedNone
Resolvedovasileva
Resolvedovasileva
ResolvedSpikeJdlrobson
ResolvedSpikeJdlrobson
DeclinedNone
Invalid alexhollender_WMF
Resolvedovasileva
Resolvedovasileva
Resolvedcjming
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Duplicate alexhollender_WMF
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedcjming
ResolvedJdlrobson
Resolvedovasileva
ResolvedSpikeovasileva
Resolved alexhollender_WMF
Resolvedovasileva
Resolvedjwang
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedjwang
Resolvedjwang
Resolvedjwang
Resolvedovasileva
Resolvedovasileva
Resolved alexhollender_WMF
Resolvedovasileva
ResolvedSpikeovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedjwang
Resolvedovasileva
OpenNone
Resolvedovasileva
OpenNone
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
ResolvedNone
Resolvedovasileva
Open ppelberg
Resolved ppelberg
ResolvedMNeisler
Resolvedovasileva
Resolved ppelberg
Resolvedovasileva
DeclinedNone
ResolvedEsanders
Resolved ppelberg
Resolvedovasileva
Resolvedovasileva
ResolvedDLynch
Resolvedovasileva
Resolvedmatmarex
ResolvedJdlrobson
Resolved ppelberg
OpenNone
Resolved ppelberg
Resolved ppelberg
Resolvedovasileva
ResolvedDLynch
Resolvedovasileva
DuplicateNone
Open ppelberg
OpenNone
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva
Resolvedovasileva

Event Timeline

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

I had already mentioned that on one of the feedback pages (can’t find it anymore), but I would like to point it out here as well: the feature should not clash with sticky headers of tables already used on pages. A sticky site header would overlap sticky table headers and make them useless. Maybe such situations have already been addressed in the meantime, just wanted to mention it again. I’m looking forward to the feature!

Thank you for pointing that out @XanonymusX! Seems like the Visual Editor toolbar (when it becomes fixed) could be problematic as well. Do you happen to have an example of a page where the tables have sticky headers?

True, I remember having tested to fix the VE toolbar in such situations, the overlap is very annoying. A page with several sticky table headers on dewiki is eg this discography (the template is of course used on thousands of pages). On enwiki, there is even a Gadget that can be activated for basically all tables.

True, I remember having tested to fix the VE toolbar in such situations, the overlap is very annoying. A page with several sticky table headers on dewiki is eg this discography (the template is of course used on thousands of pages). On enwiki, there is even a Gadget that can be activated for basically all tables.

Thanks for pointing this out. VE won't be an issue since the sticky header we're building will not appear in editing mode.

Regarding sticky table headings, it seems like it might be as simple as adjusting the top CSS attribute to account for the sticky header. For example, if the new sticky header is 60px tall you would adjust the CSS on the table resulting in the following:

Yes, I was thinking of that. But would that have to be done for every template and gadget or would new Vector automatically modify top:0 in tables? In templates, it would of course be possible to target Vector and change the top property only there, but I don’t know how that would affect Vector Legacy. And much depends on the final version of the sticky site header: if it only appears on mouseover, it might not be necessary to change sticky table headers at all, as they would only be covered temporarily; otherwise, elements would have to move whenever the sticky site header appears. If the site header remains sticky all the time, the table headers need to remain visible all the time. And if the site header will be configurable through user preferences, the configuration would have to adapt accordingly.

Because of the way position sticky works, I think one potential solution which would work given the plan for the sticky header to be a JavaScript-only experience would be to find all sticky elements in the page and change the top value so that they appear below the sticky header. We could compute that, but it would likely be expensive and probably best avoided, so I think some edits to templates may be required.

This would work best if all sticky elements had a class that identified them. e.g. "content-sticky".

What would be helpful at this stage in development is to know the current class names of any widely used sticky content in the article. We can make sure at least to start with, we have accounted for those.

Yes, that's what I thought. On dewiki, I am not aware of other templates generally using sticky table headers, so "my" templates would be the most common, if not only use cases so far. Those tables all use the class charts-stickyhead (as documented here). I have no idea if other projects have done similar experiments, the Gadget on enwiki (@TheDJ) can probably be adapted to the Skin-specific differences. I think if this sticky header is deployed, the potential problem and its fix (eg, adding a certain standardized class) should be clearly documented somewhere for reference, then fixing any unwanted effects should be relatively easy. I will follow it closely in any case ;)

Awesome. I'll be creating tasks soon and I'll make sure there is specifically one around finding a short term and long term solution for existing sticky headers.

Skin-specific differences

Actually, even skin-internal differences are a problem: Timeless has a sticky header in desktop but not in mobile resolution, so even if you plug in a top designed for one it doesn't look pretty for the other without a more cumbersome change, which definitely would be sad for TemplateStyles cases.

I know it's a bit off but are there plans to remove those terrible gradients from the header? I have been using some css rules to make it bearable:

image.png (139×1 px, 21 KB)

Hey @Ladsgroup, would you mind moving your comment over to T283803?

General comment on the current implementation (I couldn't find a dedicated subtask): of the icons in the sticky header, talk page and history still need a tooltip (or is there a specific reason to treat these two differently from the rest?). Should be fixed before deployment.

General comment on the current implementation (I couldn't find a dedicated subtask): of the icons in the sticky header, talk page and history still need a tooltip (or is there a specific reason to treat these two differently from the rest?). Should be fixed before deployment.

@XanonymusX - these are now available:

Screen Shot 2021-10-21 at 11.59.03 AM.png (202×796 px, 65 KB)

Screen Shot 2021-10-21 at 11.58.57 AM.png (154×858 px, 45 KB)

Hello,
Sticky header is live at euwiki, and the result impacted me, but it makes navigation better. The weirdest thing in the sticky header is that we don't know what website we are at. The logo is completely missing, and this is something no one I know is doing. I think the logo should be there, or there should be a really powerful reason not to add it.

A/B test is now completed. Iterations on the feature will be tracked individually, including explorations into showing the logo. Resolving this one.