[Wikitech-l] Commons app (Android) update - v1.41

[Josephine Lim]

Hi all,


We're excited to announce that we've rolled out several updates and
bugfixes for the Commons Android app[1] over the past couple of months.
Some of the major ones include:

- Automatic addition of geocoding template if uploaded image is geotagged
- Category suggestions based on the title entered for the image
- New, more detailed tutorial to educate new contributors on what types of
images should or should not be uploaded (special thanks to Pine for sharing
his Commons educational script which was used as the basis for this)
- Check for whether or not the file already exists on Commons, to prevent
upload of duplicates

Additionally, the kind folks at translatewiki.net are helping us set up a
translation project for our app, so hopefully localization should improve
in the near future.

Thank you all for your support and encouragement thus far! Feedback, bug
reports, and suggestions are always welcome on our GitHub page[2]. :)


[1]: https://play.google.com/store/apps/details?id=fr.free.nrw.commons
[2]: https://github.com/commons-app/apps-android-commons/issues/


-- 
Regards,
Josephine
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Notes on creating a RTL-accessible tool in MediaWiki

[Tim Landscheidt]

Leszek Manicki  wrote:

> When developing the Revision Slider extension [1] earlier this year, we (at
> Wikimedia Germany) have learned quite some things about making extensions
> and gadgets accessible for RTL language users. We have just published the
> write up [2] summarizing what we've discovered.
> We hope people developing new and existing tools, and in general developers
> sensitive to RTL accessibility issues will find these notes interesting
> and/or helpful.

> […]

Very interesting read, thanks.  I think, like other reports
about WMDE software development, it should be published as a
blog post as well.  They reach a wider audience and also in-
herently convey that they are snapshots taken at a particu-
lar time, so there is no pressure to either constantly up-
date them or slap an "{{outdated}}" on them.

I really like those "lessons learned" posts, whether from
professional developers or GSoC students, so please keep
them coming.

Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Arbitrary Wikidata querying

[Daniel Kinzler]

Very well put, Stas, thank you!

Am 13.12.2016 um 07:23 schrieb Stas Malyshev:
> Hi!
> 
>> If I wanted to make a page on the English Wikipedia using wikitext called
>> "List of United States presidents" that dynamically embeds information
>> from  and
>>  and other similar items, is this
>> currently possible? I consider this to be arbitrary Wikidata querying, but
>> if that's not the correct term, please let me know what to call it.
> 
> So this is kind of can of worms which we I guess eventually have to
> open, but very carefully. So I want to state my _current_ opinion on the
> matters - please note, it can change at any time due to changing
> circumstances, persuasion, experience, revelation, etc.
> 
> 1. Technically, anything that can access a web-service and speak JSON,
> can talk to SPARQL server. So, in theory, making some way to do this,
> *in theory*, would not be very hard. But - please keep reading.
> 
> 2. I am very apprehensive about having direct link between any wiki
> pages and SPARQL server without heavy caching and rate limiting in
> between. We don't have super-strong setup there and I'm afraid making
> such link would just knock our setup over, especially if people start
> putting queries into frequently-used templates.
> 
> 3. We have number of bot setups (Listeria etc.) which can auto-update
> lists from SPARQL periodically. This works reasonably well (excepting
> occasional timeout on tricky queries, etc.) and does not require
> requesting the info too frequently.
> 
> 4. If we want more direct page-to-SPARQL-to-page interface, we need to
> think about storing/caching data, and not for 5 minutes like it's cached
> now but for much longer time, probably in storage other than varnish.
> Ideally, that storage would be more of a persistent store than a cache -
> i.e. it would always (or nearly always) be available but periodically
> updated. Kind of like bots mentioned above but more generic. I don't
> have any more design for it beyond that but that's I think the direction
> we should be looking into.
> 
>> A more advanced form of this Wikidata querying would be dynamically
>> generating a list of presidents of the United States by finding every
>> Wikidata item where position held includes "President of the United
>> States". Is this currently possible on-wiki or via wikitext?
> 
> No, and there are tricky parts there. Consider
> https://www.wikidata.org/wiki/Q735712. Yes, Lex Luthor held the office
> of the President of the USA. In a fictional universe, of course. But the
> naive query - every
> Wikidata item where position held includes "President of the United
> States" - would return Lex Luthor as the president as legitimate as
> Abraham Lincoln. In fact, there are 79 US presidents judging by
> "position held" alone. So clearly, there need to be some limits. And
> those limits would be on case-by-case basis.
> 
>> If either of these querying capabilities are possible, how do I do them?
>> I don't understand how to query Wikidata in a useful way and I find this
>> frustrating. Since 2012, we've been putting a lot of data into Wikidata,
>> but I want to programmatically extract some of this data and use it in my
>> Wikipedia editing. How do I do this?
> 
> Right now the best way is use one of the list-maintaining bots I think.
> Unless you're talking about pulling a small set of values, in which case
> Lua/templates are probably the best venue.
> 
>> If these querying capabilities are not currently possible, when might they
>> be? I understand that cache invalidation is difficult and that this will
>> need a sensible editing user interface, but I don't care about all of
>> that, I just want to be able to query data out of this large data store.
> 
> We're working on it (mostly thinking right now, but correct design is
> 80% of the work, so...). Visualizations already have query capabilities
> (mainly because they have strong caching model embedded and because
> there are not too many of them and you need to create them so we can
> watch the load carefully). Other pages can gain them - probably via some
> kind of Lua functionality - as soon as we figure out what's the right
> way to do it, hopefully somewhere within the next year (no promise, but
> hopefully).
> 


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Analytics] Readership metrics for the timespan until December 4, 2016

[Olga Vasileva]

Thanks Zareen, it's great to see so much in-depth data!  Also, it answers
so many questions and curiosities from the past few months.

- Olga

On Wed, Dec 14, 2016 at 1:15 PM Caitlin Cogdill 
wrote:

> Yes, thanks so much for sharing this! It's fascinating and encouraging to
> see the November impressions bump.
>
> On Wed, Dec 14, 2016 at 11:12 AM, Toby Negrin 
> wrote:
>
> Thank you so much for this Zareen! It's really great to see this report --
> so much interesting data to think about!
>
> -Toby
>
> On Mon, Dec 12, 2016 at 5:45 PM, Zareen Farooqui 
> wrote:
>
> Hi all,
>
> This resumes the usual look
>  at
> our most important readership metrics. This time we can report that daily
> pageviews are up 4.8% (since the last report), with an interesting recent
> peak which meant that November’s pageviews surpassed those of November 2015
> (coincidentally also) by 4.8%, after October had already seen a 2.1%
> year-over-year increase. The iOS Wikipedia app saw increased downloads,
> while the Android app’s install base has stopped its previous downward
> trend.
>
> As laid out earlier
> ,
> the main purpose is to raise awareness about how these metrics are
> developing, call out the impact of any unusual events, and facilitate
> thinking about core metrics in general. As always; feedback and discussion
> welcome. Week-over-week and month-over-month changes are now being recorded on
> the Product page
>  at
> MediaWiki.org. This edition of the report covers a timespan of eighteen
> weeks.
>
> Some other recent items of interest, in case they didn’t already catch
> your attention:
>
>-
>
>The WMF Reading team published its quarterly review presentation
>
> 
>for Q1 2016-17 (July-September), which includes lots of traffic and usage
>data.
>-
>
>At the Foundation’s August metrics meeting
>
> ,
>the Reading team gave an update on longer-term traffic trends since 2013.
>(TL;DR: Overall pageviews have been flat to slightly declining, mobile has
>been steadily rising but recently slowed down, desktop has declining during
>these three years. However, total pageviews have been slightly increasing
>year-over-year in the last few months.) See the chart below, updated with
>data until November:
>
> [image: Wikimedia monthly pageviews (desktop+mobile), 2013-2016 (version
> December 2016).png]
>
> In particular, as mentioned, the number of total pageview saw
> year-over-year increases of +2.1% for October and +4.8% in November, in
> contrast to e.g. the -10.5% we had for May 2015-May 2016.
>
> Now to the usual data. (All numbers below are averages for August
> 1-December 4, 2016 unless otherwise noted.)
>
> Pageviews
>
> Total: 529 million/day (+4.76% from the previous report timeframe, with
> corrected numbers for anomalously high traffic on some main pages
> )
>
>
> Context (April 2015-December 2016):
>
>
>
> See also the Vital Signs dashboard
> 
>
> (Small caveats: iOS app’s pageviews were undercounted by about 1.6
> million/day from mid September to early November due to a bug
> .)
>
> Overall pageviews increased steadily during the timespan of this report
> aside from the week ending October 30th (right before Halloween) and the
> end of November. There appears to be a peak in pageviews in November.
>
> To facilitate our understanding of which traffic movements are seasonal
> and which may indicate lasting changes, here is a chart overlaying the
> total pageview numbers back to May 2013 (the earliest time for which we
> have data according to the current pageview definition):
>
> The blue line indicates a non-seasonal rise peaking around November 12. We
> checked whether this peak came from a particular country and were able to
> exclude that possibility.
>
> Wikimedia Daily Pageviews from US
>
>
> Pageviews in US do not show any drastic changes (even around the time of
> the US elections).
>
>
> Wikimedia Daily Pageviews from Mexico
>
>
> In Mexico, there seems to been a huge drop starting October 27th (perhaps
> some sort of local outage).
>
>
> Wikimedia Daily Pageviews from Ecuador
>
>
> Ecuador shows a huge spike on October 30th, followed by a drop for several
> days.
>
> Desktop: 54.1% ​(previous report: ​54.1%)
>
> Mobile web: 44.8% ​(previous report: 44.6%)
>
> Apps: 1.1% ​(previous report: ​1.3%) (missing some iOS pageviews, cf.
> 

[Wikitech-l] Final Call for Comments on the Content Model Storage RFC

[Daniel Kinzler]

Hi all!

This is a Final Call for Comments on the RFC on Content Model Storage [1][2]. If
no new and serious objections are raised within a week, the Architecture
Committee will approve this RFC and drive its implementation.

The RFC on Content Model Storage was originally approved in 2015, but was then
postponed in favor of another RFC, which proposes to create a separate content
meta-data table [3] as part of the move towards multi-content revisions (MCR) 
[4].

However, MCR in turn got stuck on database performance concerns. So we now
propose to go ahead with implementing the original RFC. The idea is to assign a
number to every content model (and content format), and then use these numbers
to refer to the models and formats in the database, instead of repeating the
same string millions of times (which is my fault btw, sorry about that).

Since the original RFC was already approved, and the situation does not seem to
have changed since then, we see no need for another round of discussions. If
nobody raises any new and serious objections within a week, this should be good
to go.


Cheers,
Daniel


[1] https://phabricator.wikimedia.org/T105652
[2] https://www.mediawiki.org/wiki/Requests_for_comment/Content_model_storage
[3] https://phabricator.wikimedia.org/T142980
[4]
https://www.mediawiki.org/wiki/Multi-Content_Revisions/Content_Meta-Data#Database_Schema

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Analytics] Readership metrics for the timespan until December 4, 2016

[Toby Negrin]

Thank you so much for this Zareen! It's really great to see this report --
so much interesting data to think about!

-Toby

On Mon, Dec 12, 2016 at 5:45 PM, Zareen Farooqui  wrote:

> Hi all,
>
> This resumes the usual look
>  at
> our most important readership metrics. This time we can report that daily
> pageviews are up 4.8% (since the last report), with an interesting recent
> peak which meant that November’s pageviews surpassed those of November 2015
> (coincidentally also) by 4.8%, after October had already seen a 2.1%
> year-over-year increase. The iOS Wikipedia app saw increased downloads,
> while the Android app’s install base has stopped its previous downward
> trend.
>
> As laid out earlier
> ,
> the main purpose is to raise awareness about how these metrics are
> developing, call out the impact of any unusual events, and facilitate
> thinking about core metrics in general. As always; feedback and discussion
> welcome. Week-over-week and month-over-month changes are now being recorded on
> the Product page
>  at
> MediaWiki.org. This edition of the report covers a timespan of eighteen
> weeks.
>
> Some other recent items of interest, in case they didn’t already catch
> your attention:
>
>-
>
>The WMF Reading team published its quarterly review presentation
>
> 
>for Q1 2016-17 (July-September), which includes lots of traffic and usage
>data.
>-
>
>At the Foundation’s August metrics meeting
>
> ,
>the Reading team gave an update on longer-term traffic trends since 2013.
>(TL;DR: Overall pageviews have been flat to slightly declining, mobile has
>been steadily rising but recently slowed down, desktop has declining during
>these three years. However, total pageviews have been slightly increasing
>year-over-year in the last few months.) See the chart below, updated with
>data until November:
>
> [image: Wikimedia monthly pageviews (desktop+mobile), 2013-2016 (version
> December 2016).png]
>
> In particular, as mentioned, the number of total pageview saw
> year-over-year increases of +2.1% for October and +4.8% in November, in
> contrast to e.g. the -10.5% we had for May 2015-May 2016.
>
> Now to the usual data. (All numbers below are averages for August
> 1-December 4, 2016 unless otherwise noted.)
>
> Pageviews
>
> Total: 529 million/day (+4.76% from the previous report timeframe, with
> corrected numbers for anomalously high traffic on some main pages
> )
>
>
> Context (April 2015-December 2016):
>
>
>
> See also the Vital Signs dashboard
> 
>
> (Small caveats: iOS app’s pageviews were undercounted by about 1.6
> million/day from mid September to early November due to a bug
> .)
>
> Overall pageviews increased steadily during the timespan of this report
> aside from the week ending October 30th (right before Halloween) and the
> end of November. There appears to be a peak in pageviews in November.
>
> To facilitate our understanding of which traffic movements are seasonal
> and which may indicate lasting changes, here is a chart overlaying the
> total pageview numbers back to May 2013 (the earliest time for which we
> have data according to the current pageview definition):
>
> The blue line indicates a non-seasonal rise peaking around November 12. We
> checked whether this peak came from a particular country and were able to
> exclude that possibility.
>
> Wikimedia Daily Pageviews from US
>
>
> Pageviews in US do not show any drastic changes (even around the time of
> the US elections).
>
>
> Wikimedia Daily Pageviews from Mexico
>
>
> In Mexico, there seems to been a huge drop starting October 27th (perhaps
> some sort of local outage).
>
>
> Wikimedia Daily Pageviews from Ecuador
>
>
> Ecuador shows a huge spike on October 30th, followed by a drop for several
> days.
>
> Desktop: 54.1% ​(previous report: ​54.1%)
>
> Mobile web: 44.8% ​(previous report: 44.6%)
>
> Apps: 1.1% ​(previous report: ​1.3%) (missing some iOS pageviews, cf.
> above)
>
> Context (December 2015 - December 2016):
>
> Overall mobile percentage is similar to the last report, but we did see a
> small increase (besides one week in August) until late September.  As a
> reminder, mobile already has a solid majority in terms of unique devices,
> cf. below.
>
>
>
> Global North ratio: 75.3% of total pageviews (previous report: 75.5%)
>
> Context (January - December 2016):
>
>
>
> There is a slight 

[Wikitech-l] 2016-12-14 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-12-14

= 2016-12-14 =

== Product ==
=== Reading ===


 iOS native app 
* Last Week
** Finished work on 5.3.2, shipped to beta (Dynamic text size, data layer
update, performance enhancements)
https://phabricator.wikimedia.org/project/view/2281/
* This week
** Monitor 5.3.2 beta & regression testsing, fix any issues, release 5.3.2
on Thursday or Friday
** Start work on 5.4 (Nearby, Login updates)
https://phabricator.wikimedia.org/project/view/2326/

 Android native app 
* Last week:
** Bug fixes for new release
** Continuing Q2 goals for Wikidata descriptions
** New prod release v2.4.183
** Initial survey
** Internal test automation discussions; now over 300 unit tests in CI
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** More Q2 goals for Wikidata descriptions (polish)

 Mobile Content Service (MCS) 
* Board: https://phabricator.wikimedia.org/project/board/1323/query/open/
* Deployed:
** Updated announcements endpoint to shorten survey for Android app
(getting lots of responses)
** Caching announcement responses
* To be deployed:
** Emitted etags have double quotes now.
https://phabricator.wikimedia.org/T150886

 Reading Web 
* Current sprint: https://phabricator.wikimedia.org/project/view/2362/
* Last week:
** Create importable test pages that can be used to test various Reading
Web related changes https://phabricator.wikimedia.org/T137527
** Hovercards rewrite finish up
** Continue working on returning page images from the lead section only
* Until we meet next time:
** Make hovercards preferences available on the settings page
** PagePreviews reading depth


 Reading Infrastructure 
* API 18n patches go live this week! announcement:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-December/000121.html
* starting work on TemplateStyles
* blocked:
** WMDE on the last i18n patch before we can move to hard deprecation:
https://gerrit.wikimedia.org/r/#/c/321464/
** could use some advice from Performance on dealing with huge JS data
blobs: *https://phabricator.wikimedia.org/T32574#2836570*

** MediaViewer tests failing, mw.language tests seem to be the cause:
https://phabricator.wikimedia.org/T152476
* not blocking

=== Community Tech ===
* Blockers: None
* Blocked: Nope
* Updates:
** Created a special page report for looking at page assessment data:
https://en.wikipedia.org/wiki/Special:PageAssessments?project=History
*** Note that pagination is broken at the moment and the fix will be
deployed soon
** Converted a bunch more wikis to numeric and uca collation:
https://phabricator.wikimedia.org/T149002
** Continued work on supporting Programs Dashboard
** Bug fixes on CopyPatrol
** Work in progress for deploying Copypatrol for Czech wikipedia
** Community Wishlist Survey ended with 265 proposals and loads of exciting
proposals.

=== Editing ===
 Collaboration 
* Updates
** https://www.mediawiki.org/wiki/Collaboration/Deployment_planning
** Edit Review Improvements
*** New RecentChanges filters
*** Drop inconsistent filters
** Echo
*** Fixed unread notification count caching
*** Switched to extension.json
** FlaggedRevs (Collaboration team is taking more active involvement here
in support of deferred changes (
https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes) project)
*** Various fixes
** ORES
*** Various fixes

 Language 
* Blocked:
** Performance: https://phabricator.wikimedia.org/T152180 - This is
Unbreak Now for ULS, but need moreinfo on it. Language team can't reproduce
it.
** CI/Jenkins: https://phabricator.wikimedia.org/T153038 -
mwext-qunit-jessie test fails on unrelated change(s).
** In ContentTranslation, there's a significantly larger number of
badtoken errors in saving articles lately. Did anybody notice this for
editing in general?

 Parsing 
* Linter extension is now in beta cluster (ex:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:LintErrors )
* Services, VE, and Parsing teams collectively decided to postpone
deployment of splitting data-mw attribute from the HTML for later when it
has higher urgency since Mobile Content Service is already doing this split
on their own and no other Parsoid client wants it, and VE doesn't like it
right now.
* We are still trying to figure out whether we want to use HTML5Depurate
(Java) or a PHP version for our pilot deployment of a Tidy replacement.
* Work ongoing to parse and render language variants in Parsoid (which
includes some fixes to the PHP parser's language variant parsing as well).
Close to being finished.

=== Discovery ===
* No blockers
* Continuing work on crosswiki search and refactoring Special:Search. Load
tests OK, now doing relevancy tests.
* Refactoring query parsing to allow extensions to add search keywords
* Improved handling of characters containing diacritics or accents
* Released tabular and map data 

[Wikitech-l] Notes on creating a RTL-accessible tool in MediaWiki

[Leszek Manicki]

Hi all!

When developing the Revision Slider extension [1] earlier this year, we (at
Wikimedia Germany) have learned quite some things about making extensions
and gadgets accessible for RTL language users. We have just published the
write up [2] summarizing what we've discovered.
We hope people developing new and existing tools, and in general developers
sensitive to RTL accessibility issues will find these notes interesting
and/or helpful.

Any comments are welcome!

[1] https://www.mediawiki.org/wiki/Extension:RevisionSlider
[2]
https://www.mediawiki.org/wiki/Extension:RevisionSlider/Developing_a_RTL-accessible_feature_in_MediaWiki_-_what_we%27ve_learned_while_creating_the_RevisionSlider

Best,
-- 
Leszek Manicki
Software Developer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Adam Wight]

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  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  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  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 

Re: [Wikitech-l] Changes in colors of user interface

[Pine W]

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  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  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 

Re: [Wikitech-l] Changes in colors of user interface

[Pine W]

Hi Volker,

Thanks very much for your explanation. I hope that I have explained
adequately that the difficulty that I see here isn't with the change
itself, but rather with communication and consultation.

An issue that I'm still trying to wrap my head around is that it's
impossible for me (and I imagine for anyone) to track all proposed,
planned, and recently-executed changes that impact the UI, and in my
situation I need to have a way of knowing information that could
affect my wide-ranging project without spending hours wading through
Phabricator and reading quarterly plans and reports on a frequent
basis.

I agree with Strainu on a number of points, including that all UI
changes that affect millions of pages should be publicized widely and
be the subject of consultation in advance.

I believe that changes which affect a smaller number of pages, but are
predicted to have noteworthy visibility to a subset of users such as
all users of a particular tool or workflow, should also be widely
communicated in advance. It seems to me that a good communication tool
for both of these kinds of changes is Tech News. I'd be interested if
you or others have comments about that idea.

Thanks,

Pine



On Tue, Dec 13, 2016 at 8:32 AM, Volker E.  wrote:
> Hi,
> my name is Volker, I’m part of the Editing department on the Design
> team and I’m leading the UI Standardization efforts at the Foundation.
>
> I would like to address Pine's original response about community
> involvement – when I've started my employment at the Foundation one of
> the first things I've identified was a shortcoming in several user
> interface elements' colors to provide sufficient contrast [1] for
> people with visual impairments. We then started the work by reaching
> out to community members, several of those were active on
> accessibility related conversations. Based on the expertise of myself,
> other designers at the Foundation, developers' and community members'
> feedback we came up with the current color palette [2].
> We've been proceeding as sensitive as possible in the follow-up
> changes, making the interface better for a specific group of people
> and certain use cases (think interaction in sunlight on mobile devices
> for example) without negatively affecting any other group or use case
> at all.
> The first, widely visible change was featured in the Tech News. [3]
>
> A consistently applied, harmonious (and limited) color palette is
> important for recognition and a good user experience. Sometimes
> context wins over consistency, therefore designers in collaboration
> with myself have decided to provide “just” a base palette which should
> be sufficient for the majority of interface needs – while some of the
> interface challenges [4] might need to feature colors outside of this
> palette in order to be solved, with further contributions of community
> members.
> Clearly, we also might learn about important issues that have not yet
> been solved, and need to be addressed in the palette.
>
> For such issues and for staying up-to-date on general activities,
> please feel free to subscribe to the UI Standardization overview [5]
> and Kanban [6] workboards or to file a task tagged with "UI
> Standardization".
> Our current work has also been visible in the weekly Scrum of Scrum
> notes lately, although I had to skip the last two notes for capacity
> and travel reasons.
> Additionally we're planning an Unconference session on the already
> accomplished work of the user interface guidelines – including the
> color palette – at the upcoming Wikimedia Developer Summit [7].
>
> Your feedback is not only welcome, but important to evolve our
> interface in the right manner.
>
> Regards,
> Volker
>
> [1]: 
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
> [2]: https://phabricator.wikimedia.org/M82
> [3]: https://meta.wikimedia.org/wiki/Tech/News/2016/41
> [4]: Example: https://phabricator.wikimedia.org/T151938 – Add Yellow70
> to the color palette
> [5]: https://phabricator.wikimedia.org/tag/ui-standardization/
> [6]: https://phabricator.wikimedia.org/tag/ui-standardization-kanban/
> [7]: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit
>
>
> On Mon, Dec 12, 2016 at 10:40 AM, Neil P. Quinn  wrote:
>> Strainu and Pine:
>>
>> If developers learn they can't trust you to distinguish reasonable
>> expectations from unreasonable ones (this falls into the "ludicrously
>> unreasonable" category, by the way), don't be surprised if they ultimately
>> start to doubt even your legitimate complaints.
>>
>> There are very important discussions to be had about how software
>> development works in the Wikimedia movement. This is absolutely not one of
>> them.
>>
>> On Mon, Dec 12, 2016 at 1:48 AM, Strainu  wrote:
>>
>>> 2016-12-12 10:21 GMT+02:00 Quim Gil :
>>> > Hi, let me check this incident under the light of the Technical
>>> 

Re: [Wikitech-l] Changes in colors of user interface

[K. Peachey]

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  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 

Re: [Wikitech-l] Google Code-in 2016: We need your tasks!; 2nd week achievements

[Tony Thomas]

Thank you Andre for mentioning Newsletter extension here. For the numbers,
we have 15 tasks completed as of 14 days, and we have 1 more left with a
student working on it. Andre asked me to share how GCI works for our
project, in an attempt to *push* more maintainers in this list to add in
and mentor more GCI tasks. Its a fact that Wikimedia is running out of
tasks, and lets hope this mail goes through well.

Some general pointers, which I think works out:

   1. Come out with simple *independent* tasks for your project - which has
   a proper description for a complete newcomer of what needs to be done. This
   can start usually with a line like 'This tasks requiures $extension to be
   installed'.
   2. Never underestimate the students - from what I see from their
   patchsets, the students who I had to deal with are really good, and
   understand the software pretty easily. Good luck to get those there.
   3. If you *cannot* find tasks for the project, think about dropping an
   email to *any* Google Summer of Code/Outreachy intern who has worked
   *previously* with your project. This works great, and we had huge help
   coming around from them. Even though a lot of mails were sent, personal
   email from the maintainer can mean much more, I would say.
   4. If you know any non developers who can test your application brining
   in more design and software bugs - they are your best chance. If your
   extension/project is in a design review phase - each and every *sensible*
   comment can be made a GCI task! We had our extension hosted in labs -
   http://newsletter-test.wmflabs.org/ - and we had people like Quim Gil
   ready to test things out, bringing in more bugs = yay!
   5. If you have some *partial* bug fix already in Gerrit, and you
are too *lazy
   *to finish it - a task with the name 'To complete Gerrit change:
   ' also makes sense, and is allowed by GCI rules.
   6. In any case, you can always follow
   https://www.mediawiki.org/wiki/Google_Code-in_2016/Mentors, and forward
   this to people who you think might be able to help out on things!

Hope this helps.

Thanks,
Tony Thomas 
Home  | Blog  |
ThinkFOSS 


On Tue, Dec 13, 2016 at 6:49 PM, Andre Klapper 
wrote:

> We are soon going to run out of Google Code-in tasks.
> Please mentor small and easy tasks!
> https://www.mediawiki.org/wiki/Google_Code-in_2016
> Contact us if you need help or have questions!
>
> Some GCI achievements of the last week (week 2 out of 7):
>  * Newsletter extension again received numerous patches
>  * Proposals for a redesign of the Romanian Wikipedia's main page
>  * MobileFrontend hooks documentation got updated
>  * One Wikispeech logo proposal (student still needs to upload to
>Commons)
>  * A long CREDIT showcase video got split into 'one video per topic'
>parts on Commons
>  * Deprecated "Article::getContent()" calls got replaced in several
>MediaWiki extensions
>  * Wikidata user docs were analyzed and improvements proposed
>  * In WikiEduDashboard, .erb html templates were converted to .haml
>  * The RelatedArticles extension received a design fix for the footer
>  * Updated screencast videos in the Phabricator help on mw.org
>  * More screenshots on extension pages (Echo, Poem, TemplateSandbox, …)
>  * Soon in the pageview API: Monthly request stats per article title!
>  * …and many many more.
>
> Congratulations to all our students and thanks to all our mentors!
>
> Thanks,
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Pine W]

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, 

[Wikitech-l] +2 nomination for Fomafix in mediawiki/

[Legoktm]

Hi,

I've filed , nominating
Fomafix for +2 in mediawiki/ repositories.

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l