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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l