User talk:Volker E. (WMF)/Flow

Hi Volker,

I'd like to better understand the dangers of changes like [changing icons].

1. Why is it 2 weeks to be safe removing the old icons?
2. In what circumstance can a page cached from the previous deployed version be served?
3. How can the 2 icons edit vice-versa? (phab:T244444#6025519).

Think you could help with answering my question here?

On -> https://www.mediawiki.org/w/index.php?diff=1775428&oldid=1775375&title=Manual:Coding_conventions/CSS, when you say:

With CSS3 developers have a plethora of accepted color values for CSS properties like background-color, color, border-color et al.

what is the meaning of et al. for an easy translation. Thanks -- Christian 🇫🇷 FR (talk) 20:45, 4 February 2024 (UTC)

@Wladek92 Thanks for pointing this out, I've changed the phrasing for a simpler understanding. Let me know if you've got any other questions more…

hi thanks, but top of file .... has disappeared ; so that languages no longer appear. Link between /fr /xx... seem no longer be subpages of root page /CSS since the /fr can be modified now directly (prohibited!) instead of using ext Translate.

Can you have a look ? thkx. -- Christian 🇫🇷 FR (talk) 08:33, 7 February 2024 (UTC)

Not sure, what has happened wrong here. Sorry. @Volker E. (WMF)

WVUI is replaced by Codex, design system for Wikimedia.

Hi. First, sorry if this wasn't the best way to contact you, or if you aren't the best person to contact - I wasn't sure how to contact the team working on WVUI and since you are one of the developers I figured I could ask you or you could tell me who to ask.

In the GlobalWatchlist extension (Extension:GlobalWatchlist) there is currently a basic Vue version of the display, to be used instead of the one build on jQuery/OOUI. The Vue version is not enabled for production yet, and one of the reasons is because we don't have a good loading component (the indeterminate progress bar that is shown while the entries are being fetched). In the OOUI version this is a OO.ui.ProgressBarWidget[1]. I was wondering if there were plans to add a similar component to the WVUI library? There is already such a component in the "Wikibase Vue components" library[2] but that library is not used in MediaWiki core or made available to extensions as far as I know.

If there are no such plans already, would the WVUI team consider it? If not, I guess GlobalWatchlist can always just create its own (perhaps based on the Wikibase version) but since I think this type of component might get reused elsewhere I would think it makes more sense to add it to WVUI (in phab:T272885 where existing components in various extensions and libraries were identified, ContentTranslation already has a similar progress bar).

Thanks, --DannyS712 (talk) 23:06, 9 July 2021 (UTC)

[1] Can be seen at eg https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#Progress-bar-indeterminate

[2] https://doc.wikimedia.org/wikibase-vuejs-components/master/ui/?path=/story/indeterminateprogressbar--default

Hi @DannyS712, thanks for that question. Yes, indeed, we plan to add a progress indicator component to the future standard Vue library. See Design inventory task for current breakdown of components https://phabricator.wikimedia.org/T277047. One caveat currently is, that Wikimedia Foundation has to still agree on library standards and the standard library as different product teams and Wikimedia Deutschland have started prototypical implementations and we're setting out to find the biggest common denominator. Design System Team is set out to find this agreement first weeks of August here.

Until then we will and be open to add and help adding further prototypical implementations of components to WVUI, under the premise that we might transfer those components to another repo if WVUI would not be the selected future library (that's not our plan though).

Hope this helps, –Volker E. (WMF) (talk) 15:20, 10 July 2021 (UTC)

Thanks for the info - if you aren't going to have agreements on the design until August, when would you expect the component to be added to WVUI at the earliest? Just wondering - I'll probably create it in GlobalWatchlist beforehand either way, just wondering. If I do create it in GlobalWatchlist it'll only be until one is available in the shared library.

It's fine to propose them to be added (write a patch) to WVUI right now. Under the premise, that we would maybe need to move them over to the future standard Vue.js library in case it's decided against WVUI.

In that case, I'll probably sent a patch soon (I'll file a related ticket too so it can be tracked).

Don't want to start an off-topic discussion on Phabricator (phab:T212808) so let us continue this discussion here (link on your page in Phabricator led me here).

To be quite honest, between May 2017 and November 2018 I didn't have admin rights (click), so I cannot tell myself. But there's been this discussion on plwiki, which hints that the problem with our local gadget was caused by the OOUI change and hasn't been really fixed ever since. To clarify: I am not claiming that that OOUI change caused the TypeError I mention in phab ticket, just that our local gadget stopped working.

And I am not a fan of OOUI at all. Wherever I could, I have disabled any sorts of fancy looking "improvements", which, for me personally are downgrades. I have disabled this on RecentChanges, Watchlist and Search. I would disable it anywhere else as well, but I unfortunately cannot. There should be an option in Preferences to turn off OOUI look and just use plain html forms, as it was before. I am one of those veteran editors; I've been here (in and out admittedly) for 15 years (10 on this account) and I got used to the "old look". As one of plwiki's technicans I am not against changes so to say, I am against changes that are completely unnecessary. OOUI forms are taking more space on the screen than their plain html "counterparts". These widgets are also taking some time to load, which really pisses me off.

All I ask for is, give me the ability to choose. Best wishes for this New Year, tufor

great talking to you to, buddy

Hi @Tufor, thanks for your honest input here. I've had a very busy week with the still ongoing OOUI v0.30.1 release and a lot of other things https://gerrit.wikimedia.org/r/q/owner:volker.e%2540wikimedia.org+status:merged I would like to better understand your take on the interface change. But need some more time for a better reply. Best, Volker

See also Topic:Vjtg7wks66lx080h.

Hi! You referred to no Phabricator task in 1fd66a67edc, so I’m writing here. You provided no real explanation why the :only-child rules are necessary, but their result can be seen here—the <ul> has no margin, so the bullet points get out of the box. Why are these rules worth it?

Thanks @Tacsipacsi, that is actually a bug. But not in Vector style, but in huwiki's https://hu.wikipedia.org/w/index.php?title=MediaWiki:Common.css. Remove the padding property there and the styling is fine.

…and in Commons’ (see this example), and in enwiki’s, and so on. I think this is the point where you have the responsibility to fix the layout on these wikis, preferably without breaking any other layout (e.g. giving a huge padding to the box may break other cases, where there’s no list in the box). And your code breaks even on MediaWiki.org:

• a
• b

Here the bullet points get out of the red-bordered inner box, as .messagebox :only-child may mean div.messagebox > div > ul:only-child as well (actually something like this happens in the above Commons example, as the list is in a <div> within the table cell), not only div.messagebox > ul:only-child (and it may mean many other things way down in the DOM tree)—using unqualified generic ancestor selectors is almost never a good idea!

I agree that unqualified generic selectors should be used carefully. Going to the Commons example, it's again a MediaWikiːCommon.css override, similar to huwiki. If removed the box overflow is goneː https://phabricator.wikimedia.org/F31553033 In the same way MediaWikiːCommon.css overrides should be used very sparelyǃ As they are a maintenance burden, they are hard to update with new findings on internationalization or accessibility. The reason for the ːonly-child was excessive padding due to more generic selectors. Lists in messages are an edge case that we've been taken into account with our default padding, but the overrides are kicking them out of the box. Having the list bullets outside of the red box is not a breakage for me, it's acceptable or even recommended by some typographers, see https://betterwebtype.com/articles/2018/10/15/rhythm-in-web-typography/

To be precise: these are not overrides. These are consistent styles that have existed on-wiki and worked well for 14 years before appearing in MediaWiki core source code. (The huwiki and Commons versions are 1-2 years younger, simply because the first versions of their common.css’s are of that age.) So we got back to that you intervened in how these classes work after almost one and a half decade. (The red border was just an example. It’s still weird for me, even after reading the article, but I can accept some people like it that way. However, there are cases where it’s not a question that it’s simply wrong. For example hu:Sablon:Vitafejléc’s right pane fortunately has a paragraph above the list, otherwise it would look terrible with the bullet points appearing at the left pane’s right side.)

I'm not interested in a blame game, my work is focused on having consistent experience for users of all our projects. If you refer to https://phabricator.wikimedia.org/T127405 or https://phabricator.wikimedia.org/T228022 it's obvious that message box visual treatment was all over the place making it harder for user to orient. The ːonly-child selector targets to reduce whitespace in case block-level elements are the only children of the messagebox. The „consistent“ styles haven't worked for 14 years, if we have a look at a mobile (iPhone 6/7/8) representation. https://phabricator.wikimedia.org/F31606008 Tables are not meant to be used for layouts, they mostly work well only under the assumption of a minimum width. And the new selector is only uncovering more table layout inflexibility. I could imagine to add precision to the selector (like excluding table.messagebox) for a short-term solution, but it doesn't make the current layout any more future-proof. It only extends the semi-broken status quo.

Yes, that’s the first template of that I mentioned here that is actually really broken on mobile (but wouldn’t be very hard to fix the mobile layout, although working around your changes may take a bit more time). My subpage uses a plain <div>, which is as mobile-friendly as possible, while the Commons template uses a table, but with only a small icon, which causes a less-than-ideal, but still readable output (tested with the iPhone 6/7/8 user agent in Firefox’s responsive design mode). I don’t know what you mean by “uncovering more table layout inflexibility” (especially regarding my original example, which has not a single table), as the new selector simply messes up the current style. Doesn’t create a new consistent style, as it overrides only parts of the styles, while keeps other parts intact (I’m speaking about enwiki, huwiki and Commons, not mediawiki.org). Of course anything can break with such inconsistent changes. Excluding tables doesn’t fix the layout for non-table message boxes, so that’s not even a short-term solution.

Hello, I have questions:

• Will you make an update of the Vector skin to remove the awful blue bar between sidebar and page content, the blue of the of the source editor, all non-flat icons, gradients and other ?
• Will the Design team make a graphic chart like the material design of Google ?
• Could the Design team propose new logos for sister projects with the blue red and green (Especially for Wikispecies' logo wich looks so old) ? ( I made some tries but it's missed)

Thanks.

Hi Archi38,

trying to respond as clearly as possible and pointing out the different dependencies, but first of all explain what's the best process to raise those.

You might want to join Phabricator (We manage our projects, tasks and bugs on Phabricator.) and repost your questions as laid out on our site. There it gets more attention and usually the right respondents in comparison to a talk page like this.

Log in to Phabricator with your MediaWiki login credentials to be involved in the design quests. Please tag your tasks with "Design".

Regarding your questions:

• Vector has come quite a way for a few years now, it's addressing a lot of needs collected over time in one place. And besides some of the things are historically “grown”, we try our best (with limited resources) to go with modern best practices for all kinds of users (right-to-left languages, keyboard-only users, users with visual impairments and so on). So some of the things you're mentioning we might be aware of, some of them we might have chosen for a good reason even if the reason might not be fully clear upfront to everybody. Again, Phabricator is a good place to start a conversation on shortcomings from your point of view and why you think that they are not optimal as they are. On the other hand you always have the option as logged-in user to customize your user experience with help of user stylesheets or JavaScript modifications.
• First I need to ask further: What would you expect from such a graphic chart to help your work?
• The Design team could propose new logos, but currently (again: limited resources) we don't have it planned as one of our priorities for the upcoming months. I will forward your logo page to the Communications team, so that they are aware of the critique and the work taken.

Best! V

Thank you,

• I'll use the Phabricator. But it is not written if we can make concensus on it or not.
• For the graphic chart, it would be something really complete about all on-wiki content, pages formatting, template design, Mediawiki: messages design, ect.
• Thank you to show them my (horrible) work ! I think it's really important to bring the 3 colors to all the logos, especially for Wikipedia wich is the most-known project, because people could clearly identify Wikimedia's projects.

@Archi38, re: logo color, this issue has been discussed in the past, for example in the Wiktionary logo votes in ~2006. It was determined then, that having all the logos use the same color schemes, would be confusing; see example at w:de:Benutzer:Julian~dewiki#Test on logos. See also, these discussions (m:Discussion_on_the_logo_votes#The_Color_Complication and m:Talk:Wiktionary/logo/archive-vote-4#Changing_colors), in particular this comment: "the only thing we can do is to ensure that newly chosen logos harmonize [with] the others but don't look all the same". See also m:Logo#Logo_guidelines "It must be substantially different from the other project logos but still harmonize with the others.". HTH.

(Sidenote: There's a not-completely-serious compilation of these types of alternate logos, compiled at m:Red, green, and blue, which might amuse you. My volunteer account has added your designs, there.).

I still think that it would be better ^^. And thank you for adding them in red green and blue, I've already seen the page. Thank you for all !