Hey, If a community dislikes a change they can instantly override it using mediawiki:common.css. In that case, no one would forces them to change it back.

But these changes are too small to notice and even smaller to dislike. For example no one is trying to change blue to red, But we changed a certain shade of blue to another shade that you are more familiar with and seen in other places. That's why for small changes we never got negative feedback. We are doing this to give users better experience by using familiar colors. It's really hard to see any objections overall.

Best

On Fri, Dec 9, 2016 at 10:03 AM Pine W wiki.pine@gmail.com wrote:

Hi Amir,

Were these changes discussed in advance with Wikimedia communities on mailing lists, village pumps, etc? I am thinking particularly of template designers and maintainers, who may have coordinated their work with the previous color scheme. It seems to me that Wikimedians should be given plenty of notice that color changes like these are proposed, and should be given ample opportunity to comment on them before they are rolled out, but this is the first that I recall hearing of these changes. I would go so far as to say that there should be an RfC before making changes like this to community wikis.

Also, it seems to me that there should be a period of a few weeks between the commitment to make a change like this and the implementation of a change so that Wikimedians whose work is affected have an opportunity to prepare for changes.

I'm not going to push for a rollback of this change unless I hear a lot of community voices saying that this particular set of changes is a problem, but I would hope that changes like this would be communicated and discussed widely in the future and that an RfC would be undertaken before making these kinds of changes to community wikis.

Pine

On Thu, Dec 8, 2016 at 4:45 PM, Amir Ladsgroup ladsgroup@gmail.com wrote:

...

Hey, With the deployment of 1.29.0-wmf.5 which just finished on all wikis, several changes were made in user interface colors.

• Gray boxes (TOC, Wikitables, catlinks, thumbnails, elements in history

etc.) has changed from #f9f9f9 as background to #f8f9fa and #aaa as

border

...

to #a2a9b1. [1] This change is almost not noticeable but in order to keep consistency between all elements of a wiki page, change such usages in

your

...

Mediawiki:Common.css (for example for infoboxes).

• Search results border and background colors also changed and this one

is

...

also not noticeable. [2]

• "You have new message in your talk page" notification color has changed

from #f9c557 to #fc3 (yellow). [3] This change is noticeable.

These all are parts of works ongoing by WMF designers and engineers to

have

...

a standard UI [4] using standard colors picked from Wikimedia color palette. [5]

Using consistent colors helps users have better experience and strengthen branding. Also these colors have passed WCAG standard for accessibility (for color blind people). Lots have been done already. Such as content translation [6] wikipedia.org portal [7] [8], mobile frontend [9], Echo email notification [10], Deffered changes [11] ORES review tool [12], disambig icon [13] [14], WMF wiki main page [15] and a lot more.

So I recommend you to use the color palette [5] as much as possible.

I must explicitly note that I did a little and I don't think I can talk

on

...

behalf of UI-standardization team :)

[5]: Wikimedia color palette: https://phabricator.wikimedia.org/M82 [6]: https://gerrit.wikimedia.org/r/321609 [7]: https://gerrit.wikimedia.org/r/322831 [8]: https://gerrit.wikimedia.org/r/325057 [9]: https://gerrit.wikimedia.org/r/317746 [10]: https://gerrit.wikimedia.org/r/323554 [11]: https://gerrit.wikimedia.org/r/323558 [12]: https://gerrit.wikimedia.org/r/320341 [13]: https://commons.wikimedia.org/wiki/File:Disambig.svg [14]: https://commons.wikimedia.org/wiki/File:Disambig_gray.svg [15]: https://wikimediafoundation.org/wiki/Home

Best _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, 2016-12-09 at 23:56 +0200, Strainu wrote:

Totally agree. It's not a question of how small/large such a change is, it's a question of collaboration and mutual respect. Which was lacking, yet again :(

While I'm not sure if "UI Standardization" is defined as a product in WMF, I'd hope that in the future https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline will generally be helpful (which welcomes feedback).

The project's workboard can be found at https://phabricator.wikimedia.org/tag/ui-standardization/%C2%A0and it is linked from https://www.mediawiki.org/wiki/Wikimedia_User_Interface

Some communities will miss these changes completely just because they had already overridden the old values in Common.css, most likely for historical reasons. A heads-up would have allowed them to decide on whether to go with the upstream changes or stick with the current layout.

Regarding a heads-up, would it have helped to have these changes listed in https://meta.wikimedia.org/wiki/Tech/News/2016/49%C2%A0?

Cheers, andre

Hi!

https://xkcd.com/1770/ seems pretty timely!

Or this one: https://xkcd.com/1172/ :)

Hi,

On 12/09/2016 05:25 PM, Pine W wrote:

While I appreciate the attempt to be funny, I am not amused in this case. Surprise UI changes could, for example, result in thousands of dollars' worth of instructional videos becoming instantly out of sync with the real-world user experience. Also, users who may have spent considerable time perfecting their templates may be surprised to find that they need to make changes to keep the templates in sync with other changes to the UI. The problem isn't so much that the UI was changed, as that it was changed without notice and consultation. This isn't funny.

Well, I was specifically responding to Strainu's comment that "No change is to small to be disliked by one or more people!" which seemed to be in jest too.

But I think you're significantly over-exaggerating the costs of this UI change, and changes in general. MediaWiki's UI changes literally every day when localization messages are updated, reworded, or added. Special pages are re-organized to be made more intuitive, toolbars re-arranged, etc. If you're making instructional videos, colors *barely* changing seem like the least of your problems in terms of becoming out of date. The VisualEditor project has a script that automatically generates localized screenshots of the user interface so the user manual stays up to date, I don't know if any solution has been worked out for videos yet.

-- Legoktm

May I just say if the time ever comes where MediaWiki developers have to submit an RfC, coordinate with local wikis of numerous different languages, and wait weeks for community feedback and consensus for minor UI color changes, then all development would have been brought to a halt. It is that kind of bikeshedding and red-tape that often makes enterprise software development so cumbersome and loathed.

Honestly, I don't even think this change needs to be announced. If wikis are overriding their own colors using common.css, then it is their due diligence to make sure their custom unsupported code keeps up to date with the base MediaWiki software.

*-- * Regards,

*Tyler Romeo* 0x405d34a7c86b42df https://parent5446.nyc

On Fri, Dec 9, 2016 at 9:32 PM, Steven Walling steven.walling@gmail.com wrote:

Pine, please chill for once. On Fri, Dec 9, 2016 at 5:40 PM Legoktm legoktm.wikipedia@gmail.com wrote:

...

Hi,

On 12/09/2016 05:25 PM, Pine W wrote:

...

While I appreciate the attempt to be funny, I am not amused in this

case.

...

...

Surprise UI changes could, for example, result in thousands of dollars' worth of instructional videos becoming instantly out of sync with the real-world user experience. Also, users who may have spent considerable time perfecting their templates may be surprised to find that they need

to

...

make changes to keep the templates in sync with other changes to the

UI.

...

...

The problem isn't so much that the UI was changed, as that it was

changed

...

...

without notice and consultation. This isn't funny.

Well, I was specifically responding to Strainu's comment that "No change is to small to be disliked by one or more people!" which seemed to be in jest too.

But I think you're significantly over-exaggerating the costs of this UI change, and changes in general. MediaWiki's UI changes literally every day when localization messages are updated, reworded, or added. Special pages are re-organized to be made more intuitive, toolbars re-arranged, etc. If you're making instructional videos, colors *barely* changing seem like the least of your problems in terms of becoming out of date. The VisualEditor project has a script that automatically generates localized screenshots of the user interface so the user manual stays up to date, I don't know if any solution has been worked out for videos yet.

-- Legoktm

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi Amir,

While I think that you are well-intentioned, you may be underestimating the effects of small changes that are done on a large scale. I believe that color changes to the UI are not urgent changes, and there is every reason to do widespread communication about proposed changes (*not* the week that changes are rolling out, but instead two to three months in advance), to provide opportunity for discussion, and to provide a buffer time period between the finalization of the decision and the execution of the change.

Perhaps an organizational change that would be helpful here is assigning a Community Liaison to the the WMF Design team to help that team with communications and rollout plans.

Also, perhaps it would help my project if I had a meeting with someone from the WMF Design team to get a better sense of what UI changes to expect over the next 24 months. I am working on help videos for Wikimedia content wikis, and I would like those videos to reflect the real-world environment to the extent possible. Is there a particular person on the Design team that you would recommend that I contact about setting up a meeting?

Thanks,

Pine

On Fri, Dec 9, 2016 at 12:53 AM, Amir Ladsgroup ladsgroup@gmail.com wrote:

Hey, If a community dislikes a change they can instantly override it using mediawiki:common.css. In that case, no one would forces them to change it back.

But these changes are too small to notice and even smaller to dislike. For example no one is trying to change blue to red, But we changed a certain shade of blue to another shade that you are more familiar with and seen in other places. That's why for small changes we never got negative feedback. We are doing this to give users better experience by using familiar colors. It's really hard to see any objections overall.

Best

On Fri, Dec 9, 2016 at 10:03 AM Pine W wiki.pine@gmail.com wrote:

...

Hi Amir,

Were these changes discussed in advance with Wikimedia communities on mailing lists, village pumps, etc? I am thinking particularly of template designers and maintainers, who may have coordinated their work with the previous color scheme. It seems to me that Wikimedians should be given plenty of notice that color changes like these are proposed, and should

be

...

given ample opportunity to comment on them before they are rolled out,

but

...

this is the first that I recall hearing of these changes. I would go so

far

...

as to say that there should be an RfC before making changes like this to community wikis.

Also, it seems to me that there should be a period of a few weeks between the commitment to make a change like this and the implementation of a change so that Wikimedians whose work is affected have an opportunity to prepare for changes.

I'm not going to push for a rollback of this change unless I hear a lot

of

...

community voices saying that this particular set of changes is a problem, but I would hope that changes like this would be communicated and

discussed

...

widely in the future and that an RfC would be undertaken before making these kinds of changes to community wikis.

Pine

On Thu, Dec 8, 2016 at 4:45 PM, Amir Ladsgroup ladsgroup@gmail.com wrote:

...

Hey, With the deployment of 1.29.0-wmf.5 which just finished on all wikis, several changes were made in user interface colors.

• Gray boxes (TOC, Wikitables, catlinks, thumbnails, elements in

history

...

...

etc.) has changed from #f9f9f9 as background to #f8f9fa and #aaa as

border

...

to #a2a9b1. [1] This change is almost not noticeable but in order to

keep

...

...

consistency between all elements of a wiki page, change such usages in

your

...

Mediawiki:Common.css (for example for infoboxes).

• Search results border and background colors also changed and this one

is

...

also not noticeable. [2]

• "You have new message in your talk page" notification color has

changed

...

...

from #f9c557 to #fc3 (yellow). [3] This change is noticeable.

These all are parts of works ongoing by WMF designers and engineers to

have

...

a standard UI [4] using standard colors picked from Wikimedia color palette. [5]

Using consistent colors helps users have better experience and

strengthen

...

...

branding. Also these colors have passed WCAG standard for accessibility (for color blind people). Lots have been done already. Such as content translation [6] wikipedia.org portal [7] [8], mobile frontend [9],

Echo

...

...

email notification [10], Deffered changes [11] ORES review tool [12], disambig icon [13] [14], WMF wiki main page [15] and a lot more.

So I recommend you to use the color palette [5] as much as possible.

I must explicitly note that I did a little and I don't think I can talk

on

...

behalf of UI-standardization team :)

[5]: Wikimedia color palette: https://phabricator.wikimedia.org/M82 [6]: https://gerrit.wikimedia.org/r/321609 [7]: https://gerrit.wikimedia.org/r/322831 [8]: https://gerrit.wikimedia.org/r/325057 [9]: https://gerrit.wikimedia.org/r/317746 [10]: https://gerrit.wikimedia.org/r/323554 [11]: https://gerrit.wikimedia.org/r/323558 [12]: https://gerrit.wikimedia.org/r/320341 [13]: https://commons.wikimedia.org/wiki/File:Disambig.svg [14]: https://commons.wikimedia.org/wiki/File:Disambig_gray.svg [15]: https://wikimediafoundation.org/wiki/Home

Best _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

​For reference, these are the changes being discussed: https://phabricator.wikimedia.org/F5022813

1) Significantly larger changes than this are happening all the time (the OOUI-ification of old forms, for example), without anyone noticing, so it's pretty clear people are reacting to the announcement here and not the actual change.

There is nothing wrong with not paying attention to something well outside your work area, and people should not be excluded from a discussion topic just because they are new (or casual) to it, but please consider how it creates an unhealthy community dynamic when people are criticized for announcing changes which would otherwise go unnoticed. There are already too many developers who avoid this list because they find it too stressful or time-consuming. One of the costs of transparency and open coordination is that discussions can get easily overwhelmed by a bunch of random people with strong principles but relatively little idea of what's going on (that's why wikis are so strict about canvassing, for example); it's a good mental habit to ask "would I have gotten involved in this discussion eventually even if it wasn't announced in a mailing list?", and if the answer is no, consider just moving on.

2) There was once a project to create a free encyclopedia, where every change had to be discussed and agreed on with half a dozen groups of stakeholders. It was called Nupedia; it produced a hundred articles in three years, while its offshoot Wikipedia did well over a hundred thousand.

It probably does not take a thousand times longer to discuss an article with various gatekeepers than it takes to write it. But it's sufficiently demotivating that people won't even try; instead they find a project where their contributions are welcome and not buried in red tape. Software development is not magically exempt from the same coordination costs that affect article writing. Please be mindful of unintentionally creating an unwelcoming environment.

It's not fundamentally different with staff members, either. They have more time, but that time is bought with donor money, which needs to be spent responsibly. Designers spending their time videoconferencing with every interested user on whether they plan to change the shade of the new message bar to a slightly different yellow some time in the next two years is probably not what most donors have in mind when they support the movement.

3) When you are asking people to do more early planning and announcement and discussion, you are asking them to do significantly more work. It's not a free lunch; they need to cancel some tasks they would otherwise have been able to do, and spend time writing emails and getting translations and setting up discussions instead. More discussion means less features. Sometimes that's a reasonable request; sometimes not. Please consider which one it is, before asking.

This time it falls squarely into "unreasonable", I think. Exactly what would an early announcement achieve? Delay producing the videos by half a year just to make sure the brightness of the ToC border is not 5% off? Or is "discussion" an euphemism for "veto power" and we should keep our website less accessible to readers with visual impairments so that the tutorial video colors are accurate?

Documentation decays; it's a sad fact of life. Developers are acutely aware of that, since they need to produce and maintain a lot of it. No one likes it, but there is no reasonable way to prevent it. Halting software development so that documentation can stay up to date is certainly not one.

4) On a more constructive note, there *is* a reasonable way to reduce template maintenance burden: make LESS available to template editors so that variables such as "ToC border color" can be shared between MediaWiki and userland code. I filed T152832 about that.

On Sat, Dec 10, 2016 at 1:17 AM, Amir Ladsgroup ladsgroup@gmail.com wrote:

It returns permission error to me

Uh, fixed. Looks like Phabricator keeps files private as long as they are not associated to any task.

On Sat, 2016-12-10 at 19:49 +1000, K. Peachey wrote:

On 10 December 2016 at 19:07, Gergo Tisza wrote:

...

For reference, these are the changes being discussed: https://phabricator.wikimedia.org/F5022813

Is there any reason this is being discussed on a File compared to a task?

Did you click the link? There is no discussion on a (Phab) File instead of a task. Tgr only documented what's being "discussed" in this thread. Tgr could have also posted the screenshot on some random other site.

Is there any reason security has been changed on this file?

I don't understand or see where "security" (?) was changed. Or how that's even relevant to this thread.

andre

2016-12-10 11:07 GMT+02:00 Gergo Tisza gtisza@wikimedia.org:

For reference, these are the changes being discussed: https://phabricator.wikimedia.org/F5022813

1. Significantly larger changes than this are happening all the time (the

OOUI-ification of old forms, for example), without anyone noticing,

Agreed. However, these changes do not apply to millions of articles. It's a question of scale and visibility.

it's pretty clear people are reacting to the announcement here and not the actual change.

That's one way to put it. I would rather say that we reacted to yet another slip-up in communication from the Foundation. Why is it so hard for you guys to push the information to wikis?

There is nothing wrong with not paying attention to something well outside your work area, and people should not be excluded from a discussion topic just because they are new (or casual) to it, but please consider how it creates an unhealthy community dynamic when people are criticized for announcing changes which would otherwise go unnoticed.

I don't think an RFC was needed, but: 1. an announcement on this list with a phabricator number would have been nice 2. an announcement *on wiki, before the deployment* was mandatory.

The rest of your mail does not seem related to this particular change, so I'll respond separately.

2016-12-10 1:43 GMT+02:00 Andre Klapper aklapper@wikimedia.org:

Regarding a heads-up, would it have helped to have these changes listed in https://meta.wikimedia.org/wiki/Tech/News/2016/49 ?

Yes, with a follow-up in /50. Do note that the text in /50 is insufficient, you might want to add something like what Amir said: "in order to keep consistency between all elements of a wiki page, change such usages in your Mediawiki:Common.css (for example for infoboxes)." That's because not all TechNews readers can deduce action items by themselves.

HTH, Strainu

2016-12-10 12:48 GMT+02:00 Amir Ladsgroup ladsgroup@gmail.com:

I just want you to stop there

On Sat, Dec 10, 2016 at 2:07 PM Strainu strainu10@gmail.com wrote:

...

That's one way to put it. I would rather say that we reacted to yet another slip-up in communication from the Foundation. Why is it so hard for you guys to push the information to wikis?

Why is this related to WMF?

For 3 reasons: 1. While MW is open source, what gets deployed on the WMF servers is the legal and moral responsability of the Foundation. 2. The WMF has an 8-person "Community Liaisons" team that is dedicated to "inform the communities during the whole process of development of said software, and facilitate its adoption." [1] For me, that means that they should be the ones that make sure that changes that impact million of pages don't get left out, even if the developer forgets to notify anyone. 3. The average wikipedian does not seem to make the difference between volunteer developers and employees of the WMF (this is a personal opinion and I might be wrong).

Do you really want to compare this to something like MediaViewer rollout?

MediaViewer, VisualEditor and many others, yes. But not in the sense that this was as bad as those, rather that the WMF missed another good opportunity to establish trust and prepare for the next big feature.

Small, almost invisible changes are the best time to practice and experiment with notifications and to gauge the community response: how many communities actually made changes to Common.css? How many needed to make changes? For the ones that did not make the changes, was it because they did not have the knowledge or because they missed the memo? Etc, etc, etc... This way, we (the "tech abassadors"), you (developers) and them (community liaisons) can all be better prepared for the next big deployement.

Strainu

[1] https://meta.wikimedia.org/wiki/Community_Liaisons

2016-12-11 12:13 GMT+02:00 Amir Ladsgroup ladsgroup@gmail.com:

On Sat, Dec 10, 2016 at 3:19 PM Strainu strainu10@gmail.com wrote:

For 3 reasons:

1. While MW is open source, what gets deployed on the WMF servers is

the legal and moral responsability of the Foundation.

They have responsibility but it's limited.

2. The WMF has an 8-person "Community Liaisons" team that is dedicated

to "inform the communities during the whole process of development of said software, and facilitate its adoption." [1] For me, that means that they should be the ones that make sure that changes that impact million of pages don't get left out, even if the developer forgets to notify anyone.

It's not correct. community liaisons can't check every patch to see if it's going to impact users (and most patches have effect on users, even indirect). They built a protocol and told developers to inform them when they think the change is going to impact users *significantly*.

Then perhaps we need to define "significantly" to include changes that affect every single article on every single wiki we have. If that's not significant, I don't know what is. People claimed in this thread that your change was "almost invisible". But if just 1:1,000,000 pageviews causes someone to notice the change, in just a month, your change will have affected over 15,000 people. That's singnificant, IMHO.

Where is this protocol you talk about laid out?

3. The average wikipedian does not seem to make the difference between

volunteer developers and employees of the WMF (this is a personal opinion and I might be wrong).

It's horrifyingly wrong. Lots of stuff is being done by either volunteers or staff in their volunteer capacity. You need to correct this view. not to blame WMF, right?

Wrong. It's just not realistic to expect 70.000+ editors distributed in hundreds or thousands of wikis to understand free software development, deployments and versioning. For them, it's "the developers" who "break the site" and that's all they want (and need) to know. The details need to be abstracted by someone, and the WMF is the best positioned entity to do that. I think this is already addressed, though, since that's the role of the community liaisons. It's just a question of how much can those people do - I ask more from them, others want less.

Since we got to this point, I would also like to address Tyler's email from yesterday, because it shows a similar lack of understanding of how non-technical communities use MW. He talks about red-tape slowing-down development, but forgets (or does not realise) that constant tweaking to the website is in itself red-tape for smaller communities, as it takes away valuable resources from other tasks: most Wikipedias simply do not have a web developer with admin rights. Also, throwing the responsability of maintaining Common.css up to date solely on the communities without providing a minimum of heads-up and guidance ("I don't even think this change needs to be announced") might look like a smart thing to do, but in the long run it turns pitilessly against the developers, as it results in even more technical debt that they need to address when developing new features. I think the team working on global gadgets might have some interesting stories on this process :)

Best _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi, let me check this incident under the light of the Technical Collaboration Guideline https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline (draft under review, feedback welcome in the related discussion pages).

https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_c... defines when and where are communications expected.

The change discussed in this thread is a slight variation of the same colors, for accessibility reasons that haven't been contested. This is not a new product or a new feature, and it is not even a major bug. Therefore, not triggering a community announcement & review for this case was correct.

This doesn't forbid anyone to talk about this change, especially when they are one of the contributors (and a volunteer developer) happily sharing the results obtained. Sharing the news with wikitech-ambassadors was correct too.

https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Community_d... defines the steps for communities in case of disagreement.

If a change (no matter how small is perceived by their authors) causes problems to a community or an individual, they can file specific blockers explaining the problem. They can do it in the related Phabricator project https://phabricator.wikimedia.org/project/profile/24/ or wiki page https://www.mediawiki.org/wiki/Wikimedia_User_Interface.

So far there haven't been any blockers identified about the change itself, though? If you have any, please report it in the venues where they can be addressed effectively. https://phabricator.wikimedia.org/T152025 seems to be the related task.

Strainu and Pine:

If developers learn they can't trust you to distinguish reasonable expectations from unreasonable ones (this falls into the "ludicrously unreasonable" category, by the way), don't be surprised if they ultimately start to doubt even your legitimate complaints.

There are very important discussions to be had about how software development works in the Wikimedia movement. This is absolutely not one of them.

On Mon, Dec 12, 2016 at 1:48 AM, Strainu strainu10@gmail.com wrote:

2016-12-12 10:21 GMT+02:00 Quim Gil qgil@wikimedia.org:

...

Hi, let me check this incident under the light of the Technical Collaboration Guideline https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline

(draft

...

under review, feedback welcome in the related discussion pages).

https://www.mediawiki.org/wiki/Technical_Collaboration_

Guideline/Milestone_communication

...

defines when and where are communications expected.

Thank you for the pragmatic approach Quim. I launched 2 discussions there, referring to changes that require action from the communities [1] and changes affecting large number of pages [2]. Hopefully we can find a middle ground on at least some of the subjects.

Strainu

[1] https://www.mediawiki.org/wiki/Topic:Th1vs3h97d96ajaf [2] https://www.mediawiki.org/wiki/Topic:Th1wc4pu1qplo4k8

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I get the reasons for the standardization, and the (usability) reasons for the selection of the colours. For a lot of wikis, they'll be (mostly) irrelevant because of the degree of customization, either at the wiki-wide level, or on an individual use-case level; a lot of people won't even notice. I'm agnostic on the issue of colour palette, generally speaking, although that might be because I know how to get around it if I really want to.

On the other hand, those are pretty boring (bordering on awful) colours. Yeah, I know...they're chosen for usability. But they're also the same colours I'm seeing just about everywhere else on the web (although in slightly different contexts). I'm not invested at all in whatever standard colours are chosen, but I'm not persuaded that making Wikipedia look like a lot of other websites is necessarily a positive thing. It's like all the web designers are using the same textbooks. And #ac6600 is not a colour I really want to see on my screen; ask any parent to think back to those first six months, and they'll explain...

Risker/Anne

Hi Pine,

Any chance to provide information or examples of these documents that would need to be replaced if/when colours are changed?

To my knowledge, There is no where in MediaWiki core that relies on colour only to convey information to the clients/end users. The colour is used to enhance and/or supplement the information provided.

I know from personal experience, I have many times used documentation where colouring and/or other user experience elements (examples: icons, system dialog environments) have changed weather it's from in-application/services changes and redesigns or from external changes such as system user interface provided mechanisms without major impacts to the documentation that i've used.

On 14 December 2016 at 18:39, Pine W wiki.pine@gmail.com wrote:

I have delayed responding to this thread until I felt that I could do with some degree of calmness.

I view UI changes that affect millions of pages as a big deal. I realize that from a developer's perspective it may seem trivial to change a color setting. Let me try to illustrate a different perspective that might help to explain how seemingly small changes, when implemented at large scale, can have significant effects. I am going to ask for the collective patience of the people in this thread as I explain a perspective that appears to be different from a number of theirs.

Marketers spend significant amounts of time and money designing their sales pitches to the public. One of the many elements considered in these communications is the use of color. WMF Fundraising appears to be very aware of this, as Fundraising tries different color variations in their banners and in-line marketing. I believe that in either the 2012 or 2013 fundraising campaign, I heard Sue say that Fundraising had found that year that displaying the banner message with a green background resulted in a significant increase in revenue for that year's fundraising campaign. Marketers make use of color on a regular basis in their research and communications to the public, and as WMF Fundraising seems to have experienced, these changes can lead to important changes in consumer (or donor) behavior. My guess is that the folks in WMF who work on user retention and usability studies also are mindful of small changes that could be made to the UI that could lead to important changes in user behavior.

So, I believe that small UI changes that will be applied to millions of pages are not trivial matters, even if the changes are easy for a technical staffer or volunteer to implement.

With that as my starting point, let me proceed further into describing four difficulties that surprise UI changes present, particularly when done on large scales. In the examples below I am speaking about UI changes in general, not only the particular case of color changes. (Perhaps splitting this more general discussion into a separate thread would be appropriate, and if someone wants to do that I think that would be OK.)

• As described above, there may be important changes in reader or user

behavior. (I realize that WMF lacks Google's financial and human resources for extensive testing, but this still should be kept in mind when considering UI changes. As mentioned above, WMF Fundraising seems to be aware of this, and I imagine that WMF staff in other departments are as well.)

• Documentation may need to change in a large number of places, many

of which are maintained with volunteer labor, and until those changes are made users may receive incorrect information that leads to adverse effects.

• As I mentioned previously, designers and maintainers of templates

may need to update them to sync with the changes to the UI, and I imagine that these people would appreciate advance notice instead of being surprised with a change.

• Those of us who are trying to future-proof our work to the extent

possible are put in a difficult position. In my case, WMF is paying me grant funds to develop instructional videos about Wikimedia. I think that everyone involved in the project understands that changes will happen and that the videos will need to be updated at some point in the future; the way we are designing the project is intended to make it relatively easy to make changes and do translation work. However, we are trying to design the videos such that they are very well aligned with the state of the UI that Wikimedia users will encounter when the videos are launched and for at least the next several months thereafter. If we spend thousands of dollars producing video and then there is a surprise UI change that makes all of our work out of date, perhaps even before the videos are fully published, this puts us in a difficult (and potentially expensive) situation that would have been avoided if we had known about the upcoming changes. Importantly, a significant UI change that is covered only in a single segment of the video, such as a change to a particular workflow, might be easier and less costly to illustrate in the videos than a small change that makes many or all segments of the video series out of sync with the current real-world user experience. In the latter case, we'd be faced with the decision to either accept that many or all of the videos no longer reflect the user experience or potentially spend thousands of dollars to do rework. I anticipate that eventually all of the videos will be reworked, and yes someday there may be a UI change (or a collection of changes) that impacts all of the videos significantly enough that a decision is made to update all of the videos, but I'd like us to at least have all of the videos be in sync with the user experience at the time that the videos are launched and presented to to the communities and affiliates for use in education, GLAM, online help, and other initiatives and workflows.

I hope that this helps to explain my perspective.

Pine

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi Pine,

That's a really interesting question you bring up, that people develop associations between colors and exact positions on the screen, so that moving or discoloring a button will jar them out of a pleasant, easy to anticipate experience, and will invalidate some of what they learned, possibly making the videos less effective teaching tools as the interface changes.

I'm not sure what we (wearing my WMF hat) can do to help with the problem, however. Change control at the level you're talking about would mean a radical reworking of our deployment strategy. As I understand it, the alternative is to stockpile code changes and do big software releases on a longer timeline, but that's a somewhat discredited approach. If we stick to the lighter, weekly deployments then it's inevitable that the interface will be evolving rapidly.

Also, let me thank you for your work on the instructional videos! I'm sure these will make a huge difference for newbies and might even attract new editors. In an ideal world, we could write scripts to automate the UI segments you'll be filming, and could even replay them later and replace segments to publish new editions of the videos. Short of that, however, maybe you could distribute a companion quick reference card, which would be easier to keep up-to-date and would illustrate the placement and coloration of major components.

I'm happy to see so many of my colleagues in this thread, and feeling immensely proud that such a potentially explosive issue (the bigger issue of WMF deployments in the context of broader community consensus and engagement in the process) was discussed at length, yet there was nothing but an outpouring of generosity and assumption of good faith. This is when it feels good to be a Wikimedian!

I do think we should start new threads for potential ideas to improve WMF deployment communication. Amir's announcement was a wonderful model of developer citizenship, and I think the palette change itself is beyond reproach. Continuing here makes me uncomfortable really, because our focus should not be on Amir's patch or even his announcement, but on the bigger issues of two-way communication. Making sure we're targeting policy for criticism rather than people is essential to this healthy communication--otherwise some of us will feel obliged to defend the person being targeted and will struggle to be receptive to the constructive content.

Warm regards, Adam

On Wed, Dec 14, 2016 at 1:30 AM, Pine W wiki.pine@gmail.com wrote:

Hi Peachy,

As an example of a potential high-impact color change that would result in a need to change documentation, I recall a proposal to change all red links to a different color. I don't recall the user's reasoning for the proposed change, but that is one situation where I believe that color alone signifies important information to the end user.

I understand that in the example that came up in this thread we're talking about UI color harmonization rather than a move that would be as obvious a color change to users as changing red links to (for example) green links.

Does that answer your question? I was thinking about UI changes in general, particularly across millions of pages, rather than about a specific scenario of color being used intentionally to convey a certain kind of information to the user.

Pine

On Wed, Dec 14, 2016 at 1:12 AM, K. Peachey p858snake@gmail.com wrote:

...

Hi Pine,

Any chance to provide information or examples of these documents that would need to be replaced if/when colours are changed?

To my knowledge, There is no where in MediaWiki core that relies on colour only to convey information to the clients/end users. The colour is used to enhance and/or supplement the information provided.

I know from personal experience, I have many times used documentation where colouring and/or other user experience elements (examples: icons, system dialog environments) have changed weather it's from in-application/services changes and redesigns or from external changes such as system user interface provided mechanisms without major impacts to the documentation that i've used.

On 14 December 2016 at 18:39, Pine W wiki.pine@gmail.com wrote:

...

I have delayed responding to this thread until I felt that I could do with some degree of calmness.

I view UI changes that affect millions of pages as a big deal. I realize that from a developer's perspective it may seem trivial to change a color setting. Let me try to illustrate a different perspective that might help to explain how seemingly small changes, when implemented at large scale, can have significant effects. I am going to ask for the collective patience of the people in this thread as I explain a perspective that appears to be different from a number of theirs.

Marketers spend significant amounts of time and money designing their sales pitches to the public. One of the many elements considered in these communications is the use of color. WMF Fundraising appears to be very aware of this, as Fundraising tries different color variations in their banners and in-line marketing. I believe that in either the 2012 or 2013 fundraising campaign, I heard Sue say that Fundraising had found that year that displaying the banner message with a green background resulted in a significant increase in revenue for that year's fundraising campaign. Marketers make use of color on a regular basis in their research and communications to the public, and as WMF Fundraising seems to have experienced, these changes can lead to important changes in consumer (or donor) behavior. My guess is that the folks in WMF who work on user retention and usability studies also are mindful of small changes that could be made to the UI that could lead to important changes in user behavior.

So, I believe that small UI changes that will be applied to millions of pages are not trivial matters, even if the changes are easy for a technical staffer or volunteer to implement.

With that as my starting point, let me proceed further into describing four difficulties that surprise UI changes present, particularly when done on large scales. In the examples below I am speaking about UI changes in general, not only the particular case of color changes. (Perhaps splitting this more general discussion into a separate thread would be appropriate, and if someone wants to do that I think that would be OK.)

• As described above, there may be important changes in reader or user

behavior. (I realize that WMF lacks Google's financial and human resources for extensive testing, but this still should be kept in mind when considering UI changes. As mentioned above, WMF Fundraising seems to be aware of this, and I imagine that WMF staff in other departments are as well.)

• Documentation may need to change in a large number of places, many

of which are maintained with volunteer labor, and until those changes are made users may receive incorrect information that leads to adverse effects.

• As I mentioned previously, designers and maintainers of templates

may need to update them to sync with the changes to the UI, and I imagine that these people would appreciate advance notice instead of being surprised with a change.

• Those of us who are trying to future-proof our work to the extent

possible are put in a difficult position. In my case, WMF is paying me grant funds to develop instructional videos about Wikimedia. I think that everyone involved in the project understands that changes will happen and that the videos will need to be updated at some point in the future; the way we are designing the project is intended to make it relatively easy to make changes and do translation work. However, we are trying to design the videos such that they are very well aligned with the state of the UI that Wikimedia users will encounter when the videos are launched and for at least the next several months thereafter. If we spend thousands of dollars producing video and then there is a surprise UI change that makes all of our work out of date, perhaps even before the videos are fully published, this puts us in a difficult (and potentially expensive) situation that would have been avoided if we had known about the upcoming changes. Importantly, a significant UI change that is covered only in a single segment of the video, such as a change to a particular workflow, might be easier and less costly to illustrate in the videos than a small change that makes many or all segments of the video series out of sync with the current real-world user experience. In the latter case, we'd be faced with the decision to either accept that many or all of the videos no longer reflect the user experience or potentially spend thousands of dollars to do rework. I anticipate that eventually all of the videos will be reworked, and yes someday there may be a UI change (or a collection of changes) that impacts all of the videos significantly enough that a decision is made to update all of the videos, but I'd like us to at least have all of the videos be in sync with the user experience at the time that the videos are launched and presented to to the communities and affiliates for use in education, GLAM, online help, and other initiatives and workflows.

I hope that this helps to explain my perspective.

Pine

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l