Matthias mentioned in the Flow retrospective this morning that we need to
do some i18n work, if we want to deploy on the French WP Forum des
Looking at the upcoming release on ee-flow with French set as my language
in preferences, it looks like all of the messages are correctly translated
into French. (Attached are screenshots showing the Flow board, the topic
page, the notifications panel and the topic dropdown menu.)
What i18n work needs to get done here?
There are four spikes in the Sprint G column -- adding Flow topics to site
search, in-board search, Hide/undo/rollback and Special page to
Developers: Put your names on the spike cards that you're interested in
Yesterday -- meeting about Compact Personal Bar.
Working on notification style for created new topic & taking out board link
-- question for one of them.
Posted a patch for mobile -- querying Echo database directly instead of API.
Worked on E-1 bug - Watch star on Topic page
Bug 69879 -- the card is about two different things, S says that he'll help
to split them out.
Working on G-3 --- Mobile/no-JS reply & edit
Working on G-4 spike for design of the new modal dialog box.
Is there another team working on it? VE has a dialog, but Shahyar wants to
get a pure css version working.
Question about Shahyar's progressive enhancement patch for the "Regression
with cancel button" card. Put the Gerrit patch on the card?
Yesterday - templating discussion about getting templating into core, no
final decision yet.
Matthias reviewed the preview shouldn't be indented bug -- but not the unit
test. Can someone code review the test?
Same for i18n of seconds ago (use moment.js) -- in code review.
Will send a meeting summary about the templating meeting.
Today -- shepherding preview patches. James said he will help with Echo QA.
Sprint F work going out today to Mediawiki.org:
-- Echo notifications panel split between "Messages" (Flow) and "Alerts"
(everything else), Messages tab only visible if the user has had Flow
-- Notifications panel has up to 25 unread notifications, with a scroll
-- Updated notification style for Messages that highlights the topic
-- Messages notifications have read/unread state. They're marked read
when the user clicks on the notification and visits the topic page, plus a
"mark all as read" link and an x on individual items to mark uninteresting
items as read. (Alerts items keep the current functionality.)
-- Subscribe to a Flow board gives notifications when new topics are
-- New, clearer preview warning and IP edit warning
Sprint G starts today!
Today: code review.
At Jon's request - tests for one of the patches, cleaned up some existing
Found that links tables are linking to nonexistent images, fixed that.
Yesterday -- working on a few bugs
Problems spitting out IRC lines
Links table issues, bad data in the database in en WP -- relative titles --
manually fixed it.
This morning -- Echo notifications -- primary & secondary links need the
same link, to show highlights. We can probably swat deploy that tonight.
Yesterday -- new topic header bug. Discovered some issues w preview code,
written some new unit tests
Fixed indent on preview.
Today -- Jon & Shahyar meeting with Editing and Mobile teams, synching up.
Code review yesterday -- rebasing some patches, including IE tests
Yesterday -- Vagrant is working now, more or less.
Today -- finish up patches for E-1 bugs -- subscribe to board tooltip,
watch star on Topic page
Update on Design research for Flow:
Abbey is back from Wikimania & vacation, hooray. At Wikimania, she
conducted some user tests on four different projects, including Flow. This
includes some Q&A survey responses, and some live user tests captured on
She's just back today, and is deep in MediaViewer Land for at least the
rest of this week. Once she's got MV more settled, then she can work on
processing the test results for the other projects. We'll probably get a
mix of raw data and analysis.
There's going to be a second person in the Design research team -- Daisy,
who currently works in the Legal dept on the 6th floor. She'll be moving
down to the 3rd floor and starting with the research team as soon as they
backfill her current position. It's hard to say how long that will be,
because hiring is always unpredictable and takes forever.
So -- we're definitely planning to start setting up regular user testing
for Flow, but it'll take another minute for the research team to be ready
for it. We're going to keep muddling through to the best of our ability
until then. :)
That proposal could be considered in the long term, but right now we have
plenty of people who seek and get help on IRC, and we can make incremental
improvements to their experience faster than we can build a new tool from
scratch. Few newbies fail hard at IRC. The basics are similar to texting
and private instant messaging software. Let's improve the newbie user
On Aug 11, 2014 1:48 PM, "Nathan" <nawrich(a)gmail.com> wrote:
> Newbies are going to fail hard at IRC. Pretty much all of the questions Seb
> poses for a built-in newbie chat still exist with a built-in Freenode
> interface, with the addition of a complicated and often difficult (not to
> mention culturally... unique) environment. Much better to think along the
> lines of the Teahouse, but live. You can jump into a chat queue, and people
> who want to help chat with you, and you can close the chat whenever you
> want, and you can't contact people outside of the queue using chat.
> Wikitech-l mailing list
Following up on a conversation on the gendergap email list, I am discussing
with Freenode the possibility of changing the default web client to one
that is friendlier and has a less technical feel, primarily for the benefit
of new users who access #wikipedia-en-help by clicking on a link. The
likely candidate for a new IRC client is Kiwi. If Freenode wants to
maintain their current default web client we can still use Kiwi if we run
it on Wikimedia pages. Would WMF or the volunteer dev community be willing
to implement this? If so, is filing a Bugzilla bug the best way to get the
wheels of progress to turn?
I agree that this discussion is happening among a small group of
exprerienced people, and research with newbies about their preferred
communication tools would be valuable.
However, I feel that Kiwi offers a friendlier experience than we have now,
is an incremental improvement to the user experience, and poses little risk
of making the new user experience more challenging. There might be
technical challenges, and I hope we will hear about any of those from the
devs either on Freenode's side or Wikimedia's side. If anyone has
alternative suggestions to Kiwi or knows reasons to stick with the status
quo, I hope they will speak up.
I appreciate how you are thinking about this issue from the point of view
of the people we would like to help. In this case I feel the risk is low so
an extensive user study is not needed. However if you still feel
differently I would welcome hearing your views. Please let me know if I
have addressed your concerns.
On Aug 11, 2014 12:02 AM, "Kerry Raymond" <kerry.raymond(a)gmail.com> wrote:
> Pine, with respect, I think you are looking at this in terms of “how do
> we shoehorn these users into our way of doing things” instead of asking
> “what should the user experience be like?”.
> In the scenario we are discussing, we have a new user (or even not-so-new
> user) sitting in front of a Wikipedia edit window presumably feeling dazed
> and confused by some aspect of it (or all of it). So they click the
> friendly “get help” button (or whatever it is) and we take them to
> IRC-plus-or-minus-Kiwi with which they probably have no experience. I feel
> it will just reinforce the sensation of “I don’t understand any of this”
> and make it less likely they will seek help and more likely that they will
> cease editing. So much of Wikipedia is built for by developers for
> developers (or at least designed by experienced users for experienced
> users) and this seems to be an entirely unconscious process.
> I know WMF employs at least one user experience person. I think that
> person should be doing the user studies (or whatever it is that they do) to
> find out what might work best. Anyone taking part in this conversation in
> this mailing list is presumably an existing editor of some experience; we
> are probably not the people to decide how best to deliver help to the new
> user. If there is one thing the existing “community” should not decide, it
> is the new user experience, or else we condemn ourselves to a user
> experience that only works for the kinds of editors we currently have (a
> community that has a massive gendergap and a declining active editor base).
> *From:* gendergap-bounces(a)lists.wikimedia.org [mailto:
> gendergap-bounces(a)lists.wikimedia.org] *On Behalf Of *Pine W
> *Sent:* Monday, 11 August 2014 3:18 PM
> *To:* ee(a)lists.wikimedia.org; Addressing gender equity and exploring ways
> to increase theparticipation of women within Wikimedia projects.;
> *Subject:* [Gendergap] IRC web client for Wikipedia help
> Following up on a conversation on the gendergap email list, I am
> discussing with Freenode the possibility of changing the default web client
> to one that is friendlier and has a less technical feel, primarily for the
> benefit of new users who access #wikipedia-en-help by clicking on a link.
> The likely candidate for a new IRC client is Kiwi. If Freenode wants to
> maintain their current default web client we can still use Kiwi if we run
> it on Wikimedia pages. Would WMF or the volunteer dev community be willing
> to implement this? If so, is filing a Bugzilla bug the best way to get the
> wheels of progress to turn?
> Gendergap mailing list
I would like to encourage those of us who may have missed Lila's keynote
speech at Wikimania to listen to it.  In her speech, Lila takes a long
view of Wikimedia's history and future. She talks about incremental and
disruptive changes that are happening socially and technologically such as
the shift toward mobile and wearable computing, and the use of technology
in the developing world. She also talks about modes of contribution, and
changes inside the Wikimedia projects that would encourage more people to
Thanks very much, Lila. I look forward to seeing how the trends and
opportunities that you describe are addressed in our new strategic plan.