I've been away from OOUI/VisualEditor codebase for some time and I'm
hitting my head against a wall trying to get anywhere with what seems
like a small task.
Firstly I'm having issues getting citations working at all on my
vagrant instance -
http://imgur.com/WZmEWXj is how they look when I load VE
despite looking like http://imgur.com/dGA3sLw before I hit edit.
(I gave up trying to develop this on my local instance)
That aside, I figured I could easily add a 'reference' command to the
bottom of the menu that would load the ReferencesDialog which contains
the 'use existing reference' button.
I figured it would be good to make this button open the
ReferenceDialog and then explore a way of refactoring that so that
'use existing reference' could be used outside it or at the very least
a reference dialogue could be opened and straight away switched to use
existing reference.
With this quest defined, I went into the code to work out how to do this.
I looked at ve.ui.MWReferenceDialog.js and got the command name
'reference' and added it to the list like so:
'include': [ { 'group': 'cite' }, 'reference' ]
Magically a button appeared so i got excited and clicked it, hoping I
would see a reference dialog of some kind.
Sadly this caused things to explode, and I'm unable to debug this in
any coherent fashion to work this out.
I've now been stuck for the past 2 hours and since I'm on GMT hours
I've been unable to find help on irc. I'm turning to you guys to work
out how I can take this further or if I'm going down the wrong rabbit
hole.
Help needed.
I see Juliusz is on IRC so I'm hoping he'll be able to help.
This is a summary of my discussion with Maryana on mobile instrumentation needs:
Registration tagging
The ServerSideAccountCreation log only knows about mobile vs desktop registrations. Down the line we should modify it to tag new accounts by source {desktop, mobile web, mobile app, other}. For now, we can just use the existing log and extract the source by combining the userAgent and displayMobile fields. There are comments on the Schema:MobileWikiAppCreateAccount talk page that require feedback from the mobile team, if we intend to use this log for signups on apps.
Revision tagging
We propose the creation of a new “app” tag in MediaWiki on top of the current “mobile edit” tag, which we will keep for backward-compatibility. This will give us an easy way of counting all mobile edits combined or app-only edits. Detailed breakdown of edit volume/quality by app platform or version will be done via EventLogging instrumentation.
App instrumentation
Platform-specific logs such as Schema:MobileWikiAppEdit are an ok interim solution but we should revamp the original plans for a consolidated edit funnel instrumentation to be able to compare edit funnel events across different platforms and interfaces. Given that this data is not product/feature specific, it’s likely an Analytics responsibility to implement it.
Tablet edits
We still don’t have a consistent way of identifying and counting edits made on tablets (on our desktop or mobile site), but we can get some initial estimates by using UA data from the last 30 days.
Mobile dashboards
We will review the existing mobile dashboards to figure out which ones should be eventually migrated to Vital Signs.
Dario
According to http://mobile-reportcard.wmflabs.org/graphs/ui-daily
clicks to the home page in the left navigation menu have been dropping
since Thursday 1st May. On Mon Apr 21 a search bar was put at the top
of all search pages. This would have hit mediawiki.org late Thursday
24th and then all wikis by Thursday 1st May. This suggests that most
people were visiting the home link as a way to get back to the search
bar, so this seems like it has been a successful move.
The history link has proved popular and lots of people are clicking on
it. The user profile link is also proving popular.
Special:MobileOptions is interesting to look at
Looking at the graph it seems a lot of people visit the options page
and enter beta mode or disable images
http://mobile-reportcard.wmflabs.org/graphs/mobile-options
The fact the lines follow a simple trend suggests that opting into
beta and turning off images are done at the same time in many of these
cases. I wonder how many of these people actually wanted to turn off
images and how many people were just playing around?
Hey everyone.
Last night I did some user testing of the editing workflow on both the
Android and iOS apps. I had four new users and one experienced editor
participating. The test was that I gave people the app on [[Main Page]] on
testwiki, and said "There's an error on the bird article. Can you go and
fix it?".
The full unabridged notes I took are available on this
etherpad<http://etherpad.wikimedia.org/p/AppUserTesting>,
but here's my summary.
1. *Search: *Most people know straight away where the search bar is and
what it does, although the actual functionality on iOS is a little clunky.
2. *Editing: *Everyone immediately knew that the pencil icon would let
them edit. They all knew how to fix the typo, and that they should press
the save icon afterwards to save.
3. *Preview: *In response to the preview, two of the four new users said
"I'm done!" and handed the device back to me, unaware that their edit
hadn't saved and they were only looking at a preview. The one experienced
editor also expected it to save rather than present her with a preview, but
she recognised that it was a preview.
4. *Edit summary box: *Three of the four new users missed the edit
summary box. When I pointed it out to them, one said to me "I wish when I
pressed save, it had told me to fill in the edit summary box". The
experienced editor found the suggested edit summaries in iOS incredibly
confusing, but when I pointed out the edit summary box to the new users
they found them really helpful.
5. *Call to action to sign in and save: *The immediate reaction of all
four new users to the CTA was to press "Save anonymously", with them not
even reading the text to explain the difference. Only the experienced
editor wanted to sign in and save.
I've got to dash to a meeting, so I'll follow-up later with what I think
the take-home messages are.
Thanks!
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
We already have a bunch of classes with names prefixed with 'MF', 'Mobile'
or even 'MobileFrontend' - maybe it's time to finally put all our stuff
into a namespace and simplify a lot of names?
--
Best regards,
Max Semenik ([[User:MaxSem]])
I'm doing some user testing for the apps, mostly on new users but also on
one experienced editor. See me do my usertesting live on this etherpad:
http://etherpad.wikimedia.org/p/AppUserTesting
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
I finally got this working by also copying
http://pastebin.com/FsK7TBZ9 into Template:Cite_book
Forwarding to mobile-l in case it helps anyone else.
I used vagrant [1] which made this a lot easier after a failed attempt
on my local instance.
[1] https://www.mediawiki.org/wiki/MediaWiki-Vagrant
On Fri, May 16, 2014 at 2:08 AM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:
> Hey Jon,
> There are two ways you can get citations working locally. Apparently there
> is a Vagrant config you can use, or you can set it up manually:
> 1. Install the TemplateData extension and set it up according to the
> installation instructions on Mediawiki.org
> 2. Install the Scribunto extension and set it up according to the
> installation instructions on Mediawiki.org
> 3. Copy the main citation module from en.wiki to your local wiki:
> https://en.wikipedia.org/wiki/Module:Citation/CS1
> 4. Create some citation templates. The easiest way to do this is to copy the
> code from en.wiki, but delete everything in the noinclude sections
> (otherwise you'll be in template dependancy hell)
> 5. Add templateData data to your template pages. See the TemplateData
> documentation on Mediawiki.org
> 6. Set up your cite group definition on your local wiki at
> MediaWiki:Visualeditor-cite-tool-definition.json, for example:
> [
> { "name": "web", "icon": "ref-cite-web", "template": "Cite web" },
> { "name": "book", "icon": "ref-cite-book", "template": "Cite book" },
> { "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
> { "name": "journal", "icon": "ref-cite-journal", "template": "Cite
> journal" }
> ]
>
> Good luck!
>
> Ryan
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
Hey everyone,
Howie and I were chatting today about the users we're expecting on Apps. We
suspect that the nature of the app will attract a different user base from
Web and perhaps also Desktop, and that may mean we need to tailor the
features that go into the app to that user base. We'd like some data to
test that hypothesis
Right now the tagging system just tags all edits are made on mobile, and
there's no way to distinguish between apps and web. We'd like to change
that.
Splitting the tags would allow us to identify users that edit just on apps
and figure out if they are actually different. All in all, there's
potential for creating some really awesome data to analyse.
My preferred solution is for us to have three tags for Mobile: Mobile Web,
iOS App, and Android app. That way, we can generate usage statistics really
easily for both iOS and Android independently of each other, and also
compare those to each other.
There is also the possibility of tagging all edits as mobile using the
current tag, then additionally tagging edits as iOS and Android
respectively. That makes the numbers between Web and Apps harder to
compare, so I prefer the first option.
Thoughts, guys?
Thanks,
Dan
--
Dan Garry
Associate Product Manager for Platform and Mobile Apps
Wikimedia Foundation
Hello!
The Android App has a 'Reading History' feature that is akin to
browsing history on browsers. It lists the pages you have read and
allows you to go back to them in the future. It is stored only on your
device, and not sent anywhere.
There was a 'feature' that cleared out old history items after 30
days. From talking to users this was unexpected and inconsistent with
what they would expect from browsing history. Since there is a clear
all button, they expect the history to stay till they explicitly clear
all of it.
I've prepared a patch https://gerrit.wikimedia.org/r/#/c/133966/ that
strips this feature out and makes it behave more in line with user
expectations. These records don't take up too much space anyway, so it
should have minimal impact.
--
Yuvi Panda T
http://yuvi.in/blog