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