On Mon, Mar 10, 2014 at 3:41 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:
> Did a bug get open for this? If not can a a bug be opened since unless
> I'm mistaken it doesn't seem to show any public data?
> We could use the desktop experience as the basis for a solution...
> Let's get this conversation off mobile-tech if we can :)
> On Mon, Mar 10, 2014 at 3:30 PM, Arthur Richards
> <arichards(a)wikimedia.org> wrote:
> > Sounds like we just need to figure out what the experience ought to be in
> > the revdelete case and implement it. How common of an occurrence is this?
> > On Fri, Feb 28, 2014 at 4:55 PM, Max Semenik <msemenik(a)wikimedia.org>
> >> Okay, it's a bit not that scary: RevDelete still works, however this
> >> results in diffs simply disappearing for people who are not permitted
> to see
> >> the hidden content while people people who are permitted always see it
> >> though they should explicitly request to view it. Congratulations, we've
> >> been slapped again for redoing parts of core ourselves.
> >> On Sat, Mar 1, 2014 at 4:27 AM, Jon Robson <jrobson(a)wikimedia.org>
> >>> Please do not share or create a bug for this yet- discovered this
> >>> troublesome bug right now. A brief conversation with Max suggests this
> >>> could be problematic.
> >>> In this diff
> >>> supposedly 2,719 BYTES ADDED - however I don't see any green text.
> >>> Likewise in this diff:
> >>> https://en.m.wikipedia.org/wiki/Special:MobileDiff/597595271 there is
> >>> text deleted but nothing is shown.
> >>> According to Max these are revdeleted revisions...
> >>> If you visit
> >>> You'll see message "You cannot view this diff because one or both of
> >>> the revisions have been removed from the public archives. Details can
> >>> be found in the deletion log for this page."
> >>> We should probably do the same on mobile?
> >>> Max: Is this something we need to fix asap/lightning deploy? I can't
> >>> see any sensitive data when comparing mobile view with desktop view.
> > --
> > Arthur Richards
> > Software Engineer, Mobile
> > [[User:Awjrichards]]
> > IRC: awjr
> > +1-415-839-6885 x6687
Software Engineer, Mobile
Heads up: the automation tests that take banner screenshots and examine
links for proper interstitial format for Wikipedia Zero access are
temporarily disabled in order to migrate servers from one data center to
The core banner and interstitial warning functionality for W0 has been
relatively stable, but wanted to give a heads up just in case.
Mobile is experimenting with showing a small banner at the top of the main
page that prompts logged in editors to help a page in need of new links:
I think this is _great_ and started playing with it on the train with
nothing to do.
Two improvements need to be made though:
1) It's difficult to know what to link to. I wrap words which I feel should
be existing wiki pages but I pretty much have to guess or open a new window
to check those. Some kind of search interface or link validation
tool/corrector would be useful.
2) Since red links are turned off in the editor preview it can be tricky to
know whether I caused a typo or linked correctly if new to wiki text. This
is a bad first time user experience. Some kind of validation step or
feedback when I create red links in the editor itself would be useful. We
should at very least enable red links in the editor preview.
On a side note:
I really think we should give more priority to enabling new page creation
on enwiki to help those sort of experiences before continuing down this
path of encouraging new editors. People could start drafts, start pages
with photos. This seems like a really useful focus of time.
I had a chat with paper scrunching Moiz in person. To reiterate what I said
there - as stated in my first email "I wanted to discuss whether this is a
good idea?" To be clear I was never saying it was a bad idea. My original
mail was just curious to the motivating factors to why we are doing it and
what we are achieving and most specifically for me whether mobile web
should be experimenting with it too. We should definitely try this out and
see what happens.
Max has identified that this happens already on Russian Wikipedia and Amir
that this happens on Hebrew and Polish and I didn't know that. There is
also a widely used gadget. Those are interesting data points.
Steven has identified a problem you have with what summaries get canned.
This is now a shared problem.
This is why we discuss these things to understand them and end up building
the right and the best thing.
Please keep us up to date with designs. Maybe a volunteer might be
interested in knocking this up for mobile web..?
I'd love to see any other findings you've made.
To wrap this conversation up can you share the link to the relevant trello
card (I couldnt find it) or wherever is the best place to find your most up
to date designs for this so if a volunteer/future me wants to work on this
they can do so?
On 11 Mar 2014 06:43, "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il>
2014-03-11 1:00 GMT+02:00 Max Semenik <maxsem.wiki(a)gmail.com>:
> On 11.03.2014, 1:32 Jon wrote:
> > The interface showed various buttons that when clicked would populate
> > the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
> > I wanted to discuss whether this is a good idea?
> Russian Wikipedia was doing that for ages to everyone's satisfaction.
> The only problem is where to cram them in, but that's solvable.
Hebrew and Polish Wikipedias are doing it for ages, too, and probably some
In fact, numerous people complained that VisualEditor breaks this feature.
Editors don't care whether it's a local custom gadget or something else -
for all they care, it's a feature and VE breaks it.
Anyway, it would be a lovely feature to productize and make available for
all languages, for both mobile and desktop interfaces. The code is
basically there - just take the gadget from one of the Wikipedias that
currently use it and package it as an extension.
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
The app team showed a demo to the mobile web team today of the latest
editing experience for the new Wikipedia app that is being worked on.
The mobile app editing experience was very consistent with mobile web
which is a great thing, that said it had one significant difference -
canned edit summaries.
The interface showed various buttons that when clicked would populate
the edit summary input. e.g. "Fixed typos/grammar" or "Added links")
I wanted to discuss whether this is a good idea?
If the goal is to give ideas to users on what they can do to edit, we
should be doing that at the start of the workflow in my opinion - tell
a new user what they can, give them a better idea using the article
If the goal is to make the users editing experience easier (which it
should be), personally I think it would be more useful to have an
autocomplete that allows an editor to recycle older edit summaries.
PS. Is there a link to a wiki page for these designs, so other people
can see what I'm talking about?
On Tue, Mar 11, 2014 at 6:18 AM, quiddity <pandiculation(a)gmail.com> wrote:
> There are 3 existing types of automated elements in edit summaries:
> 1) If you click  on a section heading (rather than for the whole
> page), it will automatically insert this in the wikimarkup-mode edit-summary
> /* section title */
> which transforms into this in watchlists/RecentChanges/etc:
> (→section title: )
> 2) the 4 types of fully automatic editsummary (list here), eg.
> (←Blanked the page)
> 3) the "Tags" that gets appended after the edit-summary, eg.
> (Tag: VisualEditor)
Indeed, and all three will happen automatically with the Mobile app
too. I'm unsure what is making Moiz feel the need to crush paper.
Yuvi Panda T
I've been seeing some buzz the last few days about Spritz reader - an
engine for facilitating seriously fast e-reading, and is suitable for
really tiny displays. I don't think the engine is open source, but I
suspect this is going to be a really disruptive technology. There's an app
using the engine that will be bundled with the upcoming S5.
Definitely worth learning about and trying out, especially if you have any
interest around developing for tiny displays, like wearable devices:
Software Engineer, Mobile