Page MenuHomePhabricator

Vector 2022 sidebar font size & padding & line-spacing too large, sidebar alignment is off
Closed, ResolvedPublic

Description

Breaking this out as a specific issue related to T327719 , for clarity.

The initial release had two issues with sidebar style that were frequently mentioned:

  • The sidebar had too much horizontal spacing, and no non-whitespace delineation from the body text.
  • The sidebar-TOC wrapped TOC lines, added a line for counting comments, and was free with vertical linespace, making it hard to see more than 12-15 sections at once, or even see how many there were overall, requiring an in-sidebar TOC-scrollbar. This is particularly rough for pages frequented by active editors that regularly have 100+ sections: popular talk pages, noticeboards, user-talk pages of very active users.

The late-Jan update magnified both of these issues, trending away from the style of navigation and tool templates within articles (i.e.: compact, carefully-kerned, visibly different from the rest of the page, for recurring sections that are repeated across many pages in predictable places on the page). Some specific changes away from that style:

  • Sidebar text is now the same font size as body text. This is hard to scan + differentiate.
  • Sidebar linespacing is now larger than that of the body text. This is hard to read and a significant stylistic change.
  • Sidebar sections are harder to scan: no font-face or font-size difference between section titles and links in the section, and no distinguishing linespacing.

These choices differ from the style of most infoboxes and navboxes on WM wikis. I would be keen to see examples of this that work well on other sites, online or in print. Tools + Main Menu sidebars are also asymmetric (more discussion in T324877)

  • Different spacing b/t them and the body
  • Different horizontal placement w/in their side
  • Different vertical alignment w/ the page
  • Different line alignment of the bottom of each line (they don't line up)
  • Different behavior when clicking "hide", different icon/text/caret for unhiding
  • Interlanguage links now appear in all possible places, adding to the confusion. (language selector up top, 'Translations' in the user menu dropdown, prominent box saying 'your languages are in another castle' on the L, "edit interlanguage links" link — now the only instance of smaller font! — on the R)

I am stymied by all this :) Newcomers and readers may be too, with less recourse.

Screenshots of the misalignment across the sidebars (observed on chrome + ff / macos):

Screen Shot 2023-01-23 at 18.03.37.png (456×1 px, 233 KB)
Screen Shot 2023-01-23 at 18.04.09.png (440×2 px, 123 KB)
Screen Shot 2023-01-23 at 18.04.31.png (406×2 px, 249 KB)

Expected behavior:

I expected a bit more alignment in approach and style between sidebar nav and main-content nav, so we're all iterating towards the same goals.

  1. A sidebar style that matches the style of navigation in project content.
  2. A process for rolling out changes as significant as sidebar functionality + readability to a subset of users for feedback, including a subset of community-layout-maintainers, not to all Vector 2022 users and all anons
  3. Maintaining roughly the padding and font-size and linespacing of the V2010 sidebar, with distinguishable sidebar headings. This is not particularly low-hanging fruit to improve -- unlike the idea of making use of the right hand margin -- and there's a downside to experimentally changing this for everyone.
  4. Continuing to support magic words like TOC. This gives editors recourse to improve the reading experience for pages rendered less usable by the change: those with long TOCs, or those that rely on readers being able to see the whole TOC at once or to see numbered sections.

Event Timeline

For me, the new page tools sidebar text is actually larger (14px) than the body (12.25px) text.

The ticket is correct about the wildly excessive vertical padding between all of the left and right sidebar and TOC list items. Use Vector 2010 as a model for efficient use of space. Once the font size has been reduced, you can shrink the amount of horizontal space that all of the sidebar elements require. That should help mollify the thousands of people dissatisfied by the narrow band of content on even "full-width" pages.

I have attached a screen shot that shows much more reasonable sidebar font size and padding. With these settings, I am able to use 835 out of 1235 horizontal pixels for content. (In Vector 2010, the content ratio was 1040 out of 1235, which I can almost get back when I hide the page tools sidebar.) Keep on refining, and this skin will be pretty good.

{F36456396}

I believe that this is blocking T302073 from being completed.

@Sj thank you so much for all of this feedback (and your continued feedback elsewhere).

As you may have already seen:

  • We're working on some updates to the menus now which address some of your concerns (T327718, T328720).
  • We're continuing to work on the general spacing and alignment of the layout, as well as the styling of the pinned menus to help better differentiate them from the content (T259240).
  • We're also working on the table of contents, which hopefully addresses some of your other concerns (T317818, T319315, T328045).

Thanks for the links Alex. Appreciated; I realize phab works best with compact issues and isn't a great place for umbrella topics.

In T327732#8596036, @Sj wrote:

Thanks for the links Alex. Appreciated; I realize phab works best with compact issues and isn't a great place for umbrella topics.

Right, it's tricky sometimes. The discussion we've been having over on T324877: Style the page tools and main menu dropdown feature has been super helpful, and I worried that closing it would miscommunicate that the discussion was over. But because it was a development task associated with a discrete piece of work (i.e. had a certain amount of "points", belonged to a "sprint", etc.), and that work had been completed, there was pressure to close it (from like a work process, sanity/clarity perspective).

I think what we could do for discussion-based tasks like this is add "[Design spike]" to the beginning of their titles, and maybe also include the word review or discuss, e.g. [Design spike] Discuss spacing and positioning of menus. And then as we decide on work that needs to be done, we can create specific development sub-tasks.

ovasileva triaged this task as Medium priority.Mar 15 2023, 4:46 PM
ovasileva moved this task from Not ready to estimate to Groomed on the Web-Team-Backlog board.

Thanks (belatedly) for the idea of tagging umbrella discussions of what to do as [design spike]s so they're not triaged as tasks, and can have subtasks.

ovasileva claimed this task.
ovasileva subscribed.

@Sj - resolving this ticket as we'll be exploring these themes in T333927: [Design spike] Refine visual styling of ToC, Tools and Main menus instead, as well as through the Zebra #9 prototype. Let us know if there's anything in that ticket that we're missing