Reminder: This is a wiki! Edit and refactor at will.

Project: designing a new default skin for MediaWiki and Wikipedia.
Team: UX, accessibility, other? Founded : ? Past efforts : ? size : ? cf. past work by individuals on individual skins (bountied, encouraged)
Chats: Vector 2010; Minerva; Timeless; Vector 2022

Chats

Structured discussions about skin affordances, usability, needs, surveying measures of use. A mix of phab, mw/meta consults, office hours

What is the vision for the skin ecosystem? For the default skin(s)?

Options include: finding a good compromise; featuring + highlighting user choice across a few select modes; highlighting customizability. Related confounding question: how can anons interact with skins, what is the anon experience meant to be like?

Discussions

Goals: Stated (current team); Related (past efforts: V2010, Timeless); Wishlists (dark mode, easier mobile editing, easier comms uniformity w/ all readers/editors, across all sites)

Linked efforts: Talk refresh; main page redesigns; newcomer pipelines; editor pipelines; shift in primary access tools [pc/tablet/phone/other]; Dark mode

Technicality

Caching a second option
- Cached rollback option: For controversial changes, there should be a [loggable] way for everyone (logged in or not) to turn it back, particularly during a usability testing phase. A single cache cluster for each of before/after versions of the default skin, for instance.
Skin flexibility (css upgrades)
- General preferences: A range of simple prefs that could be encoded as changes in css stylenames can be implemented with client-side prefs: either a client-side cookie or localstorage.
Content width and column width debates

Design philosophy

What could sidebars be for?

Include: Comments, footnotes, references

Include: images, tables, other embeds

How do we ascertain positive change?

Continuous surveys, thoughtfully done (as of late '22: not currently in place anywhere)

Geometry

Right and left sidebars should start at the same vertical point.

Dropdowns should be in the top nav, possibly a second nav-line, or inline to expand/collapse as with TOCs.

Mix-and-match at any point on the screen is very confusing, esp for muscle memory and across languages.

'Icons and symbols

The problem with mystery ≡ symbols is they are ambiguous, and there are many of them.

Confusing: Current V22 has three: Watchlist, Main menu, TOC.

Menus can share an icon w/ different colors or symbols; TOC should be different + is used much more; Watchlist different again (sharing with RC or contribs, if anything, due to similar concept and interface on the linked page).

Icons or links that don't move away from the page / refresh the page should be clearly identified (say with a caret pointing to some direction to indicate an open/collapse toggle). Otherwise one accidentally loses the page, loses an edit in progress, &c.

Confusing: the Main Menu icon has no such indicator when closed. It has a unique double-carat, w/ no other symbol, when open. Both should have a persistent icon with open/closed caret, for similarity w/ others.

Confusing: the TOC icon has no such indicator when closed.

Persistent core interface

TOC and Main Menu should have persistent icons, regardless of their expanded/collapsed state. A little TOC link next to the title should always take you to the top of the TOC; ditto a little main menu icon. That avoids having an interface that's constantly reconfiguring itself. Even if it sometimes just causes a "look here" flash rather than moving the screen to show you what's already on display.

Devil's advocacy

alternates to avoid split b/t skin designers and layout designers

support / bounty / encourage good design ideas
engage layout designers as more than advisers; include in release flow [catch regressions]
clean up design-dev flow

How would current skin ideas work for different audiences?

Reader experience (and how they become one-time / occasional editors)
- Intensive: Researcher experience

Spot editor experience (and how they find tools)
- Intensive: active community experience (and how they use 100-section boards and talks)

Layout curator experience (and how this supports different page layouts + templates)

Tool/gadget dev experience

Working with prior art and related efforts

How does this interact w/ past Timeless designs, goals, dev?

How do these changes interact w/ other efforts to work with sidebars: for notices, comments, footnotes?)

How does this interact w/ other high profile features: dark mode, messaging anons, skin-library refactoring?

Challenges with the V22 rollout

Pages: nuance missing re: which pages render poorly. rollout itself not taken overly seriously; major templates remain broken; no mechanism for rollback; no mechanism for editor choice or reader choice to override problematic features per page.

Stats: confusing, numerous but not thorough, sometimes misread. (mixing definitions, vagueness in what's being measured and how often, excess detail in places and not enough in others)

Surveys: seemed rushed, had self-acknowledged flaws, were not repeated to improve understanding; unclear how often they will be run; subject to confirmation bias. ~35 canvassed opposes to the rollback RfC; ignoring those, 2:1 support for rolling back. someone from the F should acknowledge that in prefacing their roadmap updates. new data gathering should be careful to have cleaner higher-powered tests of sentiment and use.

Working together: response time little different around rollout than the rest of the year. issues can go weeks without response. no community devs who can comment / review patches. some high-pri issues go years without resolution. some issues once clearly recognized[1] go without a clear path forward for editors reporting and trying to fix them. meta-documentation about the rollout done by same team that's overwhelmed w/ technical fixes [rather than comms/community network of enthusiasts... were there enthusiasts available?]

Challenges responding constructively to past unsolicited redesigns

Well summarized by Yash here.

Yash
Points to past efforts (Kvasnikov, Dribbble, Prototypr) and past data gathering (surveys)

Challenges with rolling out a dark/night mode

There's an existing dark-mode gadget that works reasonably well. Produced by a collab of staff, community devs who have spent some time w/ staff, community js scripters. One of the lead designers here, who was an excellent liaison + representative of community inputs, has since left WM.
The gadget works well enough there are well-defined problems with it that bear resolving. E.g. an index of images that should be treated specially, and a better solution for tables w/ internal formatting.
The new mode is extremely incomplete (pre-alpha) on rollout for community beta-testing: it only tackles the main namespace, handles no talk + almost no special pages. Does not handle any special cases, including the dozens found on even casual use, and including styles defined in the skin: from pop-up notifications about the skin (one-time alerts, watchlist modal for duration), to notifs, to the interlanguage modal, to history and any ?action= pages. Some of these are simply left in light mode, some (like the messages showing you where a menu has just been hidden) actively fail by having light text on light background. Errors on the w:en main page include an image caption, the Wiktionary logo, and excessively intense background color.
It supports basic editing (but not the edit toolbar), but not source editing, review-changes, or the save-edit dialogue. Source editing, rather than being light mode, is simply broken: highlight colors are too dark to be visible in the black-background editor
The new mode is still brittle, getting some old problems right while getting a wide range of new cases wrong. Each case renders some svg's right and some wrong. (compare Color and Axon; and the main pg Wikt logo).
The new mode is designed to be fussy: its option is embedded into the new hard-for-community-to-influence modal for core design features [font size, screen width, dark mode] which are being maintained exclusively by staff. When on a namespace or special page, it is simply grayed out saying "not available for this page"... like no dark mode ever.
The new mode makes things higher-contrast at borders (from light gray to total white), mixing a range of new potential features around a11y which have some tradeoffs. Here a consensus around comfort and style developed by the designers of the gadget and years of use is simply changed w/o justification.
Related, there are two levels of naming confusion. Docs use [dark | night] [mode | theme] interchangeably; but these are often different (dark modes make backgrounds dark and flip colors; night modes make all colors warmer and reduce eye strain). In something like an OS you can apply either or both. I haven't see any major app or site that struggles with having/naming a dark mode the way we did. The current beta dark-mode added high-contrast, sometimes also an option (but less-used than a gentle dark mode), and we don't offer a night mode at all (which makes sense to me -- that befits the viewing device/hardware).

design chats

User:Sj/Design chats/Skins