Hi Volker,
Thanks very much for your explanation. I hope that I have explained adequately that the difficulty that I see here isn't with the change itself, but rather with communication and consultation.
An issue that I'm still trying to wrap my head around is that it's impossible for me (and I imagine for anyone) to track all proposed, planned, and recently-executed changes that impact the UI, and in my situation I need to have a way of knowing information that could affect my wide-ranging project without spending hours wading through Phabricator and reading quarterly plans and reports on a frequent basis.
I agree with Strainu on a number of points, including that all UI changes that affect millions of pages should be publicized widely and be the subject of consultation in advance.
I believe that changes which affect a smaller number of pages, but are predicted to have noteworthy visibility to a subset of users such as all users of a particular tool or workflow, should also be widely communicated in advance. It seems to me that a good communication tool for both of these kinds of changes is Tech News. I'd be interested if you or others have comments about that idea.
Thanks,
Pine
On Tue, Dec 13, 2016 at 8:32 AM, Volker E. volker.e@wikimedia.org wrote:
Hi, my name is Volker, I’m part of the Editing department on the Design team and I’m leading the UI Standardization efforts at the Foundation.
I would like to address Pine's original response about community involvement – when I've started my employment at the Foundation one of the first things I've identified was a shortcoming in several user interface elements' colors to provide sufficient contrast [1] for people with visual impairments. We then started the work by reaching out to community members, several of those were active on accessibility related conversations. Based on the expertise of myself, other designers at the Foundation, developers' and community members' feedback we came up with the current color palette [2]. We've been proceeding as sensitive as possible in the follow-up changes, making the interface better for a specific group of people and certain use cases (think interaction in sunlight on mobile devices for example) without negatively affecting any other group or use case at all. The first, widely visible change was featured in the Tech News. [3]
A consistently applied, harmonious (and limited) color palette is important for recognition and a good user experience. Sometimes context wins over consistency, therefore designers in collaboration with myself have decided to provide “just” a base palette which should be sufficient for the majority of interface needs – while some of the interface challenges [4] might need to feature colors outside of this palette in order to be solved, with further contributions of community members. Clearly, we also might learn about important issues that have not yet been solved, and need to be addressed in the palette.
For such issues and for staying up-to-date on general activities, please feel free to subscribe to the UI Standardization overview [5] and Kanban [6] workboards or to file a task tagged with "UI Standardization". Our current work has also been visible in the weekly Scrum of Scrum notes lately, although I had to skip the last two notes for capacity and travel reasons. Additionally we're planning an Unconference session on the already accomplished work of the user interface guidelines – including the color palette – at the upcoming Wikimedia Developer Summit [7].
Your feedback is not only welcome, but important to evolve our interface in the right manner.
Regards, Volker
[4]: Example: https://phabricator.wikimedia.org/T151938 – Add Yellow70 to the color palette [5]: https://phabricator.wikimedia.org/tag/ui-standardization/ [6]: https://phabricator.wikimedia.org/tag/ui-standardization-kanban/ [7]: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit
On Mon, Dec 12, 2016 at 10:40 AM, Neil P. Quinn nquinn@wikimedia.org wrote:
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).
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
-- Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF, product analyst Wikimedia Foundation _______________________________________________ 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