Jonathan's comment made me smile. To be honest, it's something that crossed my mind too. I mean...the Wikipedia community can have endless arguments about the use of the Oxford comma. We are masters at arguing over what colour the bikeshed should be. There are definitely times where developer actions have caused sufficient harm that the Wikimedia community is up in arms; this is not an organization where "move fast and break things" works very well. Unfortunately, those relatively rare occurrences are what people remember all the time. We don't remember that these same teams have worked out systems so that we no longer have a situation where every time an upgrade is loaded, it breaks the big projects. We don't remember that multiple-hour-long downtimes were commonplace. We don't remember that, in fact, a very significant amount of editing is done on the mobile site. (There used to be a report about that but I've no idea where to find it now.) It's the human condition to remember situations that have made us unhappy or even angry, while situations that have little obvious impact are completely forgotten. Bottom line, the developers have made tens of thousands of improvements to the site that rarely, if ever, get noted or even recognized. We only remember the times when they've done something that really caused problems.
A lot of the challenges that are faced by designers and developers have to do with inconsistent or narrow feedback from the editorial community, not to mention diametrically opposed requests to change the same thing in different ways. It's one thing to say that X is really awful. It's another thing to work with a cross-section of the community (i.e. hundreds of people, if not thousands across several projects) to figure out what improvements to X should look like, and gain consensus on those desired improvements. For every person who complains about X being awful, there are often an equal or greater number of people saying "don't touch X! I rely on it being exactly as it is!"
It's important and valuable to start these discussions, but let's not start off with "this group isn't doing its job the way I think they should". Let's start with "how can I influence the community to identify what needs to be improved, and get agreements that the developers can count on in order to proceed."
And yes, I know full well how very hard this is, for everyone involved. It's not a criticism of anyone participating in this thread.
Risker/Anne
On Thu, 14 Oct 2021 at 17:35, Jonathan Morgan jonnymorgan.esq@gmail.com wrote:
It's not an issue of "WMF can't hire enough designers" or "WMF can't hire good designers".
I worked for WMF in a design-adjacent role for the better part of a decade. WMF has *excellent *designers, and in sufficient numbers to build a modern user interface on desktop--one that *looks* modern and also prioritizes the needs of Wikipedia's readers (editors can always load up an old skin if they don't like the new one).
The mobile site and Wikipedia apps have a much more modern look-and-feel and are clearly focused on making Wikipedia "work" for its largest set of users: readers. If the desktop site lags on the design side, that may be because when WMF has tried to make UI changes to the desktop site in the past, or even just proposed them, they've received loud and angry push back from members of a second (smaller, but equally important) set of users: editors.
WMF, understandably, tries to avoid angering editors (believe it or not).
At the software company I work for now, if we make a change that annoys our users--pretty much all of whom are "power users" with needs every bit as complex and idiosyncratic as your average Admin--we hear about it. But no one threatens to disable that change across the platform. And it's relatively rare for a user to accuse us of being stupid or lazy or malicious--at least, its rare on for that to happen on public mailing lists or in our own forums.
That doesn't mean the stakes are any lower: if we make the software worse, we probably lose customers. But we have the autonomy to make the changes in the first place, see what happens, and then build from there or fix our mistakes or even roll things back if we need to.
WMF product teams work in an environment where their competence and good faith are frequently, and publicly, called into question. An environment where one set of end users (editors) has a great deal of both *soft* and *hard* power to block changes, even when those changes are intended for--and indeed, primarily affect--a different set of end users (readers).
Speaking as someone who worked inside of that environment, I can say that it can feel like even targeted, clearly motivated and well-justified changes aimed at improving the reader experience aren't worth the cost.
There are plenty of other factors at play, but I'm sure I've already said enough to anger plenty of you, so I'll leave it there.
I no longer work for WMF and my opinions are my own.
Cheers, Jonathan Morgan User:Jtmorgan formerly, User:Jmorgan_(WMF)
On Thu, Oct 14, 2021 at 11:34 AM Galder Gonzalez Larrañaga < galder158@hotmail.com> wrote:
Dear all, Today I learned that, despite having $100 million in the Endowment fund, we can't have a design team big enough to make our websites not look like they're stuck in 2001. I don't know if anyone is behind the wheel, but the car is expensive.
Sincerely, Galder
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org