Page MenuHomePhabricator

[Design spike] configurability & constraints for sticky header
Closed, ResolvedPublic

Assigned To
Authored By
alexhollender_WMF
Aug 25 2021, 1:17 AM
Referenced Files
F34636102: image.png
Sep 7 2021, 9:50 PM
F34629371: image.png
Sep 2 2021, 2:35 PM
F34629369: image.png
Sep 2 2021, 2:33 PM
F34629368: image.png
Sep 2 2021, 2:33 PM
F34629357: image.png
Sep 2 2021, 2:32 PM
F34629359: image.png
Sep 2 2021, 2:32 PM
F34629363: image.png
Sep 2 2021, 2:32 PM
F34628388: image.png
Sep 1 2021, 10:20 PM

Description

Description

The sticky header is meant to be a configurable component that adapts to the needs of a given page/namespace, user, or project. The general behavior of the sticky header (showing once you've scrolled past the page header) will remain consistent; the elements inside of the sticky header should vary based on your context.

The purpose of this task is to imagine possible configurations so that we can build the sticky header with the necessary flexibility and constraints in mind.

The general structure of the sticky header:

image.png (531×1 px, 429 KB)

Rough configuration requirements

The sticky header should have the ability to be configurable for up to X elements. This includes:

  • The ability to add and remove functionality from the sticky header using gadgets and user scripts (ex: removing the language button, adding a watchlist button)
  • The ability to add gadgets and other new functionality (ex: clock) to the sticky header
  • The ability to set different functionality based on the wiki and page (for example, we should be able to configure the sticky header on a talk page differently than on the main page)
  • icons/styling???
  • Configurable elements on the sticky header must be either links and menus. No other elements are permitted.

Examples of configurations

Examples of how this might differ based on context:

main namespace
image.png (463×1 px, 243 KB)
talk namespace
image.png (914×3 px, 671 KB)
Page title is displaying section title, Languages replaced by New section (styled as a framed button), Talk replaced with Article, Edit and Edit source removed, Watch added
gadgets
image.png (463×1 px, 244 KB)
Section title removed, Watch, More tools, and Watchlist added, Languages replaced with Last modified gadget
Commons
image.png (449×1 px, 414 KB)
History removed, Languages replaced with Upload (styled as a primary button)

Acceptance criteria

  • Document initial requirements for sticky header configuration on wiki

Event Timeline

@iamjessklein @ppelberg do you have the time to engage with this in the next week or two? It would be great to get a clear sense of what you think could work for the sticky header on talk pages. I took a first pass at it (sketch in task description).

ovasileva updated the task description. (Show Details)

@ovasileva, @Jdlrobson, and myself have been talking about ways to simplify & constrain the sticky header layout. Some things we've discussed so far:

  • hide the sticky header below 1200px (potentially revisit responsiveness later on)
  • drop the section title element
  • define a max-width for the page title element
  • set some constraints around icon buttons (tbd how we plan to enforce these)

for example:

image.png (174×1 px, 29 KB)

note: the max-width for the icon buttons comes from the width of an icon menu button (e.g. the user menu in the site header), which are 56px wide

Given those constraints a maxed-out sticky header (which I think would be rare, since it means that every icon button would be a menu and the primary button is at its max) would look like this:

image.png (114×1 px, 20 KB)

@iamjessklein @ppelberg do you have the time to engage with this in the next week or two? It would be great to get a clear sense of what you think could work for the sticky header on talk pages. I took a first pass at it (sketch in task description).

Yes, we are thinking about it in conjunction with the work described here T249579 (which we are working on now). Thanks for laying everything out so clearly in this ticket. cc/ @KieranMcCann

@alexhollender / @ovasileva / @Jdlrobson: being able to see the thinking you all are doing to bring shape to the sticky header component makes it easier for us – prospective "re-users" of said component – to understand its potential as a tool and subsequently use it to meet the needs of the people who will end up depending on it...thank you.

A couple of thoughts for you all below. cc @iamjessklein


In general, we think there would be value in offering people the sticky header on talk pages. Within the sticky header on talk pages, we can imagine wanting to offer people access to the following information and actions:
1. Actions

  • A) An affordance for starting a new discussion topic, so that people can act on this instinct to start a discussion about something new without needing to lose sight of the context which may have prompted them to have this thought.
  • B) An affordance for subscribing to or watching the talk page [i], so that people can act on this instinct to be made aware when there is new activity on the talk page and quickly return to what they were doing when this thought occurred to them.
  • C) An affordance for accessing the talk page's history, so that people can retrieve a link to a diff they are wanting to reference [by opening the page in a new tab] without needing to navigate away from the comment or new discussion they are drafting.
  • D) An affordance for accessing the subject page to which the talk page is related, so that people can easily reference a specific part of the artifact they are wanting to improve with others without needing to navigate away from the comment or new discussion they are drafting.

2. Information

  • A. The name of the discussion (read: == H2 ==) someone is currently reading, so that people can maintain awareness of the topic of conversation they are reading, regardless of how long that conversation is.
  • B. The number of distinct comments within the discussion someone is currently reading, so they can have a sense of "where" they are within a larger conversation and decide how much more they should consider reading before adding what they are thinking to the discussion.

i. This affordance could take the form of the existing "Watchlist" star (⭐️). We can also imagine a future where this affordance offers people a way to be notified when a new discussion is started on the talk page in question (T263821).

@ppelberg thanks so much for providing this.

1. Actions
...

  • B) An affordance for subscribing to or watching the talk page [i], so that people can act on this instinct to be made aware when there is new activity on the talk page and quickly return to what they were doing when this thought occurred to them.

are you still considering adding discussion/topic-level subscriptions? I wonder if we need to be mindful about potential confusion between subscribing to/watching the entire page (side note: which I believe also automatically watches the Article as well?), and subscribing to/watching a specific discussion/topic within the page?

2. Information
...

  • B. The number of distinct comments within the discussion someone is currently reading, so they can have a sense of "where" they are within a larger conversation and decide how much more they should consider reading before adding what they are thinking to the discussion.

this number would change as your scroll to different discussions within the page?

this number would change as your scroll to different discussions within the page?

Is this necessarily a number? I was under the impression this could be a binary option.

are you still considering adding discussion/topic-level subscriptions? I wonder if we need to be mindful about potential confusion between subscribing to/watching the entire page (side note: which I believe also automatically watches the Article as well?), and subscribing to/watching a specific discussion/topic within the page?

yes and big yes. There is a high level confusion of spaces that need to be untangled for the Talk Page contributor here, including what's a watchlist vs. what's a topic subscription.

In T289641#7338000, @alexhollender wrote:

1. Actions
...

  • B) An affordance for subscribing to or watching the talk page [i], so that people can act on this instinct to be made aware when there is new activity on the talk page and quickly return to what they were doing when this thought occurred to them.

this number would change as your scroll to different discussions within the page?

@alexhollender: can you share what number are you referring to in the above?

As @iamjessklein alluded to in T289641#7345436, in writing the above, I was referring to the star icon that already exists on talk pages or maybe, in the future, a new affordance that would enable people to elect to be notified when a new discussion topic was added to a talk page (T263821).

2. Information
...

  • B. The number of distinct comments within the discussion someone is currently reading, so they can have a sense of "where" they are within a larger conversation and decide how much more they should consider reading before adding what they are thinking to the discussion.

are you still considering adding discussion/topic-level subscriptions?

Yes. In fact, discussion/topic-level subscriptions are currently available as a beta feature at most Wikipedias.

You can see how they look and work by visiting: https://en.wikipedia.org/wiki/User_talk:AHollender_(WMF)?dtenable=1 (notice the [ subscribe ] affordances that appear right-justified within each section heading. [i]

I wonder if we need to be mindful about potential confusion between subscribing to/watching the entire page (side note: which I believe also automatically watches the Article as well?), and subscribing to/watching a specific discussion/topic within the page?

Great spot. The confusion/tension you are describing here maps to a larger question that, to me, sounds something like, "How responsive – if at all – should the information and actions within the sticky header be to what people are reading/engaging on within the page's content?"

Related to the above: is there a place where you are exploring the answer to this question?

Note: it seems like the answer to the question above will also impact how the edit affordances within the sticky header in the main namespace will behave. [ii]


i. Note: we're going to iterate upon how the [ subscribe ] affordance is presented as part of T269950; see the Section title actions section within the task description's Requirements section.
ii. More context in T287545: Editors, across experience levels, are clear what to do (read: what to click) in order to edit a particular part of the page so they can efficiently navigate to the specific content they are wanting to edit/inspect.

@iamjessklein @ppelberg apologies for the confusing comment...I had reversed the topics & questions...i fixed it: T289641#7338000

Resolving this. Next steps for community configuration will follow up via on-wiki conversation. For configuration of different namespaces, new tasks will be created