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