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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
