(Now forking this from the "Changes in colors of user interface" thread.)
Hi Adam,
Thanks for your email.
I don't think that our interface evolves particularly rapidly, our interface makes me feel like it's 2003 again. I'd like to have our interface's usability and our workflows be much easier for our users, both in terms of learning how to use our tools and in terms of providing guidance about how to adhere to community policies and norms. However, editing Wikipedia and its sister sites is often much more complex than posting an update to Facebook, and WMF lacks the design and engineering resources of big tech companies, so I think that we're likely to lag behind Facebook and Google for usability for the foreseeable future.
The issue which I am attempting to address is not a UI change itself (good or bad) but rather communication about proposed and upcoming UI changes. Like many other help resources, the videos and their accompanying materials (such as a quick-reference card that you mentioned) can be updated with varying degrees of ease and cost. If people know about changes well in advance, this will make updating those resources a much smoother experience both for the maintainers and for the people who rely on those resources for information.
My proposal would be that proposed UI changes which affect large proportions of the user base should be announced 3 months in advance. This would provide plenty of opportunity for discussion, synchronization, and testing of proposed changes. These announcements could be neatly organized in Tech News, and Tech News could be sent to this mailing list as well as posted to individuals' personal talk pages and individual wikis' village pumps. This would likely make Tech News be a lengthier publication than it is today, but I would find notifications like these to be highly valuable and I think that other community members would too. English Wikipedia for awhile had a wiki-specific list of proposed changes (largely focused on policy, but also related to technical matters and community organization) that ran in the Signpost; what I envision for Tech News would be similar except with a longer time horizon and aimed at technical and design audiences.
What do you think?
Pine
On Wed, Dec 14, 2016 at 2:07 AM, Adam Wight awight@wikimedia.org wrote:
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 Thu, Dec 15, 2016 at 6:51 PM, Pine W wiki.pine@gmail.com wrote:
My proposal would be that proposed UI changes which affect large proportions of the user base should be announced 3 months in advance. This would provide plenty of opportunity for discussion, synchronization, and testing of proposed changes.
A much finer definition is needed here. "Proposed UI changes which affect large proportions of the user base", to my mind, includes basically any UI change that affects any public user page, e.g., public Special Pages, article pages, etc. It does not include any specification about the significance of the change. (I understand this is intentional based on your replies in the previous thread.)
I am still of the opinion that small UI changes, regardless of how many users will be affected by the change, should not require a three-month holding pattern while they are discussed. The amount of developer time and productivity lost far outweighs the other consequences. Something like minor shade changes to existing colors, slight movements or alignments of specific containers, minor padding or margin adjustments, etc., are not significant, even if the change is on an article page, which would affect every millions of users. Something like a major color shade change, or a major refactoring of the design of a popular page, is of course another story.
My motivation for this is simple: I don't think software UI changes should ever be based on community consensus, nor do I think Wikipedia users (or rather, the subset of users that take interest in a Tech News announcement or the like) are a suitable group of individuals for making decisions regarding software development. Hell, not even the entire software development team of MediaWiki (volunteer or WMF) should be making such a decision. There's a reason why we have a UI standards group, composed of experts who know at least a thing or two about UI design. Does that mean these changes should occur opaquely without any communication? No, but the opposite extreme of forcing a three-month comment period is possibly even worse.
I do understand that there is a significant business requirement when it comes to announcing significant changes, i.e., those beyond the shred of a definition of what I consider a minor change. Be it community backlash and a resulting decline in community engagement by users who consider the volunteer software development team to be their mortal enemy, or instructional videos that will become outdated and need funding to recreate (which I don't view as a blocker for UI changes, but merely a consideration that should be acknowledged before making cost decisions of UI changes), there are some valid reasons why community notice should be given for a change. But it certainly should not be for *every* change. There should be a case-by-case decision of whether the given change would have a valid requirement for prior notice.
*-- * Regards,
*Tyler Romeo* 0x405d34a7c86b42df https://parent5446.nyc
On Fri, Dec 16, 2016 at 6:50 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Thu, Dec 15, 2016 at 6:51 PM, Pine W wiki.pine@gmail.com wrote:
My proposal would be that proposed UI changes which affect large proportions of the user base should be announced 3 months in advance. This would provide plenty of opportunity for discussion, synchronization, and testing of proposed changes.
A much finer definition is needed here. "Proposed UI changes which affect large proportions of the user base", to my mind, includes basically any UI change that affects any public user page, e.g., public Special Pages, article pages, etc. It does not include any specification about the significance of the change. (I understand this is intentional based on your replies in the previous thread.)
uh, in this discussion i have two hearts in the breast, fully supportive of both opinions here. i am wondering if the same could not be reachted with a different, less discussion intensive style, more solved by technology? with user interfaces i'd love, as a consumer, to have something like linux does: continuous features included all the time, not too many discussions in a rolling version (which may be compared to the usual new kernel coming out), and a version which stays stable (compared to the long term support). personally i would opt for the brand new beta version, not wanting to wait that somebody discusses a feature which i can barely imagine how it may look like. an easy switch back and forth gives imo a better indication if its going the right direction.
rupert
On Thu, Dec 15, 2016 at 3:51 PM, Pine W wiki.pine@gmail.com wrote:
My proposal would be that proposed UI changes which affect large proportions of the user base should be announced 3 months in advance.
So here is a fun experiment: * choose an activity you do a lot (say, editing Wikipedia pages) * write a detailed list of everything you intend to do in March * in that month, avoid doing anything that you did not think to put on that list I think you will gain some insights about the cost of trying to organize things far ahead if you do actually try it out.
On Fri, 16 Dec 2016, at 04:18 PM, Gergo Tisza wrote:
- write a detailed list of everything you intend to do in March
- in that month, avoid doing anything that you did not think to put on
that list I think you will gain some insights about the cost of trying to organize things far ahead if you do actually try it out.
Wow, this really reminds me of the 6 months I once spent under the Personal Software Process! https://en.wikipedia.org/wiki/Personal_software_process It did actually make me feel really productive, but then I'm pretty into stationery and printed forms and things.
On Fri, Dec 16, 2016 at 12:51 AM, Pine W wiki.pine@gmail.com wrote:
The issue which I am attempting to address is not a UI change itself (good or bad) but rather communication about proposed and upcoming UI changes.
Communication of proposals and changes is a problem indeed. Not just for UX, the problem is common to other areas of development. We are trying to define the good practices in the Technical Collaboration Guideline, at Milestone communication https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication .
This is how I personally think that the technical solution should work, taking UI as an example.
* A UX review checkpoint exists, consisting of a wiki page in MediaWiki.org where current and past proposals reviewed are logged. Users can see which proposals are currently under review (with deadlines optionally) and which ones have been resolved and when.
* Each proposal lives in its own URL (a wiki page, a Phabricator task) where rationale, updates, and discussion happens.
* Anyone can subscribe to the UX Reviews newsletter https://www.mediawiki.org/wiki/Extension:Newsletter. Teams initiating or resolving a proposal will announce the move in the newsletter. Users subscribe to this newsletter will receive updates related exclusively to UX reviews, no more, no less.
Imagine the same approach for new projects/features, security reviews, new betas, release plans... This is a good way to scale communications without drowning central spaces like Tech News, wikitech-ambassadors or your nearest Village Pump. This is also a good way to attract specialized contributors and help them shine where they can contribute best (i.e. design students or professionals happy to volunteer) as opposed to trying to convince them to follow Tech News, wikitech-ambassadors or your nearest Village Pump.
This idea doesn't define whether a change of color shade merits a review or whether the review should last three months, but it helps creating focused spaces where productive collaboration may happen sooner and more often without everybody dying out of exasperation or exhaustion.
On Fri, Dec 16, 2016 at 2:16 PM, Quim Gil qgil@wikimedia.org wrote:
Imagine the same approach for new projects/features, security reviews, new betas, release plans... This is a good way to scale communications without drowning central spaces like Tech News, wikitech-ambassadors or your nearest Village Pump.
This. Many Village Pumps on smaller Wikimedia wikis are already dominated by untranslated announcements from the WMF. I find it hard to believe newcomers will be convinced that's a place for them to discuss, rather than a graveyard for announcements in a foreign language they might or might not understand. Tech News depends on volunteer translators who make sure we can reach out with with updates in ~20 languages. This is possible partly because the amount of updates they have to translate every week is limited. The vast majority of Wikimedians – focused on editing their home wikis – have limited time and energy to keep up with what's happening in the bigger Wikimedia world; the solution to this is not to turn up the volume everywhere.
(This, too, is not to define whether something mertis review or not, but a general comment on communicating technical changes in the Wikimedia world.)
//Johan Jönsson --
Quim,
I like your line of thought here.
The Newsletter extension could be useful in all kind of ways, and I was glad to see that it's apparently still in active development.
It would be helpful for me to have proposals shown in the newsletter divided by approximate time horizon (next week, next month, next quarter, etc), as well as their status (proposed but not in development, in development, stalled, ready for review by (insert team here), deploying soon, under discussion, deployment complete on X wikis and deploying to Y soon, etc.)
What would it take to get a newsletter like that launched, when might it happen, and who should coordinate and publish it?
Pine
On Fri, Dec 16, 2016 at 5:16 AM, Quim Gil qgil@wikimedia.org wrote:
On Fri, Dec 16, 2016 at 12:51 AM, Pine W wiki.pine@gmail.com wrote:
The issue which I am attempting to address is not a UI change itself (good or bad) but rather communication about proposed and upcoming UI changes.
Communication of proposals and changes is a problem indeed. Not just for UX, the problem is common to other areas of development. We are trying to define the good practices in the Technical Collaboration Guideline, at Milestone communication https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication .
This is how I personally think that the technical solution should work, taking UI as an example.
- A UX review checkpoint exists, consisting of a wiki page in MediaWiki.org
where current and past proposals reviewed are logged. Users can see which proposals are currently under review (with deadlines optionally) and which ones have been resolved and when.
- Each proposal lives in its own URL (a wiki page, a Phabricator task)
where rationale, updates, and discussion happens.
- Anyone can subscribe to the UX Reviews newsletter
https://www.mediawiki.org/wiki/Extension:Newsletter. Teams initiating or resolving a proposal will announce the move in the newsletter. Users subscribe to this newsletter will receive updates related exclusively to UX reviews, no more, no less.
Imagine the same approach for new projects/features, security reviews, new betas, release plans... This is a good way to scale communications without drowning central spaces like Tech News, wikitech-ambassadors or your nearest Village Pump. This is also a good way to attract specialized contributors and help them shine where they can contribute best (i.e. design students or professionals happy to volunteer) as opposed to trying to convince them to follow Tech News, wikitech-ambassadors or your nearest Village Pump.
This idea doesn't define whether a change of color shade merits a review or whether the review should last three months, but it helps creating focused spaces where productive collaboration may happen sooner and more often without everybody dying out of exasperation or exhaustion.
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Dec 17, 2016 at 4:38 AM, Pine W wiki.pine@gmail.com wrote:
The Newsletter extension could be useful in all kind of ways, and I was glad to see that it's apparently still in active development.
Oh yes, check https://phabricator.wikimedia.org/project/profile/888/
It would be helpful for me to have proposals shown in the newsletter
divided by approximate time horizon (next week, next month, next quarter, etc), as well as their status (proposed but not in development, in development, stalled, ready for review by (insert team here), deploying soon, under discussion, deployment complete on X wikis and deploying to Y soon, etc.)
If that UX Review checkpoint would be created (something that needs to be decided by the Product teams who would maintain it)...
... that information would be available in the UX review checkpoint (a regular wiki page, updated as reviews come and go).
The UX Review newsletters would consist on something a lot lighter:
* A title, i.e. "New WikiEtc design concept looking for reviews" * A URL where the news would be explained and discussed.
These newsletters would arrive to users via Echo and/or email notifications -- their choice via their Preferences.
In other words, there is no need to "write a newsletter". The Newsletter extension just collects and advertises existing pages.
What would it take to get a newsletter like that launched, when might
it happen, and who should coordinate and publish it?
As a promoter of the Newsletter extension, I feel co-responsible (with Tony Thomas, lead developer and a lot more) for deploying it in Wikimedia (getting there, it has been available in the Beta cluster for a while now). If you are interested about this event, please subscribe to https://phabricator.wikimedia.org/T110170
Once the extension is deployed, if the idea of checkpoints has been found interesting indeed, we could start with a pilot. Note that setting up the checkpoint and the newsletter is relatively easy. The complex part is to define a reliable process followed by everyone. This is why I would put the words "experimental" and "pilot" upfront.
Hi Quim,
Would it be possible to set up a 60-minute Hangouts or Zoom meeting to discuss this set of issues (UX change communications, possibly aided by the newsletter extension and/or a wiki page with some kind of UX checkpoint)? If so, perhaps you and I could have an off-list discussion to find a time that works for both of us, and after that we can send a public meeting announcement to invite other people who also might like to participate. I'd suggest that we have this meeting after January 2nd.
Thanks,
Pine
On Mon, Dec 19, 2016 at 2:13 AM, Quim Gil qgil@wikimedia.org wrote:
On Sat, Dec 17, 2016 at 4:38 AM, Pine W wiki.pine@gmail.com wrote:
The Newsletter extension could be useful in all kind of ways, and I was glad to see that it's apparently still in active development.
Oh yes, check https://phabricator.wikimedia.org/project/profile/888/
It would be helpful for me to have proposals shown in the newsletter
divided by approximate time horizon (next week, next month, next quarter, etc), as well as their status (proposed but not in development, in development, stalled, ready for review by (insert team here), deploying soon, under discussion, deployment complete on X wikis and deploying to Y soon, etc.)
If that UX Review checkpoint would be created (something that needs to be decided by the Product teams who would maintain it)...
... that information would be available in the UX review checkpoint (a regular wiki page, updated as reviews come and go).
The UX Review newsletters would consist on something a lot lighter:
- A title, i.e. "New WikiEtc design concept looking for reviews"
- A URL where the news would be explained and discussed.
These newsletters would arrive to users via Echo and/or email notifications -- their choice via their Preferences.
In other words, there is no need to "write a newsletter". The Newsletter extension just collects and advertises existing pages.
What would it take to get a newsletter like that launched, when might
it happen, and who should coordinate and publish it?
As a promoter of the Newsletter extension, I feel co-responsible (with Tony Thomas, lead developer and a lot more) for deploying it in Wikimedia (getting there, it has been available in the Beta cluster for a while now). If you are interested about this event, please subscribe to https://phabricator.wikimedia.org/T110170
Once the extension is deployed, if the idea of checkpoints has been found interesting indeed, we could start with a pilot. Note that setting up the checkpoint and the newsletter is relatively easy. The complex part is to define a reliable process followed by everyone. This is why I would put the words "experimental" and "pilot" upfront.
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Dec 20, 2016 at 5:01 AM, Pine W wiki.pine@gmail.com wrote:
Hi Quim,
Would it be possible to set up a 60-minute Hangouts or Zoom meeting to discuss this set of issues (UX change communications, possibly aided by the newsletter extension and/or a wiki page with some kind of UX checkpoint)? If so, perhaps you and I could have an off-list discussion to find a time that works for both of us, and after that we can send a public meeting announcement to invite other people who also might like to participate. I'd suggest that we have this meeting after January 2nd.
Pine, thank you for this invitation, but I am only a Technical Collaboration Guideline messenger here.
Since the Wikimedia Developer Summit is around the corner and there are some related Unconference sessions being proposed there, and since we are working on better support for remote participation... I'd rather focus everybody's attention on the proposed sessions, so they get the push they deserve (they have been pretty quiet so far):
* UX Guidelines working session and, potentially, presentation https://phabricator.wikimedia.org/T149459 * Discuss creating a UI/UX design hub on mediawiki or meta https://phabricator.wikimedia.org/T117482 * Technical Collaboration Guideline: A Collaboration https://phabricator.wikimedia.org/T148878
Hi Quim,
If it's possible to have a remote unconference session about this topic as a part of the WDS, I'd be game for that.
I'm very interested in having a much better system for communication about UX changes than seems to exist today, but I need to be cautious about taking on this topic as a project for me to lead or organize over the long term, because I have a lot of issues on my agenda already, and I've told people that I'm not going to take on big new projects until I finish the ones that I've already started. So while I want to see big improvements in this area, I can't be the person to lead the process(es). What would it take to get the topic of communication improvements for UX changes onto the agenda of someone who has the resources to lead related projects in the medium term (say, 3-9 months)?
Pine
On Mon, Dec 19, 2016 at 11:55 PM, Quim Gil qgil@wikimedia.org wrote:
On Tue, Dec 20, 2016 at 5:01 AM, Pine W wiki.pine@gmail.com wrote:
Hi Quim,
Would it be possible to set up a 60-minute Hangouts or Zoom meeting to discuss this set of issues (UX change communications, possibly aided by
the
newsletter extension and/or a wiki page with some kind of UX checkpoint)? If so, perhaps you and I could have an off-list discussion to find a time that works for both of us, and after that we can send a public meeting announcement to invite other people who also might like to participate.
I'd
suggest that we have this meeting after January 2nd.
Pine, thank you for this invitation, but I am only a Technical Collaboration Guideline messenger here.
Since the Wikimedia Developer Summit is around the corner and there are some related Unconference sessions being proposed there, and since we are working on better support for remote participation... I'd rather focus everybody's attention on the proposed sessions, so they get the push they deserve (they have been pretty quiet so far):
- UX Guidelines working session and, potentially, presentation
https://phabricator.wikimedia.org/T149459
- Discuss creating a UI/UX design hub on mediawiki or meta
https://phabricator.wikimedia.org/T117482
- Technical Collaboration Guideline: A Collaboration
https://phabricator.wikimedia.org/T148878
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org