Re: [WikimediaMobile] big improvements to the MobileFrontend browser test repo

[Joaquin Oltra Hernandez]

Thanks for all the work Chris.

Not long ago I followed all instructions here
https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Running_tests
but I can't get all the tests to pass so I'm not sure if there is something
else to configure or enable, so I figured I'd ask before starting to look
into the individual tests.

Here you can see vagrant roles, final output of the tests and env variables
https://gist.github.com/joakin/eae3b086dd5a0c498669

I'm running the tests with phantomjs by default for convenience and speed,
but I've tried Firefox and I've gotten similar results.

Anything I've missed that I should do? I'd really love to get them green to
rely on them more often and avoid regressions.

















On Thu, Dec 4, 2014 at 11:43 PM, Chris McMahon 
wrote:

>
> Hi mobile folk,
>
> After 48 patches merged, I have updated all the browser tests in the
> MobileFrontend repo to conform to RSpec3 syntax. Along the way I did a few
> other things:
>
> * removed every sleep() statement except one necessary to get around a bug
> in Chrome
> * consolidated the lines within each step in each test to be as succinct
> as possible
> * handled and removed a number of FIXME comments
> * removed a significant amount of dead/unused/irrelevant code
> * made the Feature description of each test step consistent with what each
> step actually accomplishes
> * removed all the instances where "Then" steps were re-used as Given or
> When (they are conceptually different)
>
> On the style front:
>
> * all the steps are now in alphabetical order according to
> Given/When/Then, and all the GWT specifications in the .feature files
> conform to their corresponding implementations in steps files.
> * in the Features, every Then step contains the word "should", in the
> steps files, every Then step contains an RSpec assertion
> * no Given or When steps contain either the word "should" or an RSpec
> assertion
>
> This all should make working in the browser test repo significantly easier
> and more straightforward, as well as making far better use of the most
> modern implementation of RSpec.
>
> For my next trick I am going to make the browser test repo conform as
> closely as possible to rubocop style rules, but the heavy lifting with
> regard to technical debt in the browser test repos is mostly handled.
>
> Let me know if you have any questions or if you would like a tour...
>
> -Chris
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Analysis of the hamburger icon

[Amir E. Aharoni]

The similarity in the numbers is indeed striking, but I don't think that it
says much about the perception of the hamburger icon. I suspect that for
most readers the language button is more useful than *any* of the actions
in the hamburger menu - home, random, nearby, watchlist, settings, log in.
To confirm it, I'd love to see the the numbers for these other actions.

Also, as Nemo asks, it would be useful to see pages without language links
separated, and to also see page length taken into account somehow - on a
short page it is easier to see the languages button (less or no scrolling),
and there's more motivation to tap it (the hope to read more in another
language).
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] big improvements to the MobileFrontend browser test repo

[Chris McMahon]

On Fri, Dec 5, 2014 at 2:23 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:
>
> Here you can see vagrant roles, final output of the tests and env
> variables https://gist.github.com/joakin/eae3b086dd5a0c498669
>
> I'm running the tests with phantomjs by default for convenience and speed,
> but I've tried Firefox and I've gotten similar results.
>
> Anything I've missed that I should do? I'd really love to get them green
> to rely on them more often and avoid regressions.
>

Sure, I see a few issues right off, even without looking at how these
failed.

* Uploads has been disabled in the MobileFrontend for a long time. That
feature may or may not be re-enabled in the future. That test is simply not
valid, but I have kept it in the repo at the request of the Mobile team.
You can see in the tags in special_upload.feature and
uploads_copyvio.feature that those tests have no target environments and do
not run in the build.

For the rest, these tests have been designed to work primarily in beta
labs.  If you set your env vars to

export MEDIAWIKI_URL=http://en.m.wikipedia.beta.wmflabs.org/wiki/

export MEDIAWIKI_API_URL=http://en.wikipedia.beta.wmflabs.org/w/api.php

export MEDIAWIKI_USER=Selenium_user

export MEDIAWIKI_PASSWORD=(password)

export BROWSER=firefox
or equivalent, I bet the suite would pass (except for the uploads tests).

* Do you have the API URL set correctly? That would be a source of failure.
* Do you have VisualEditor in place? If not, the VE tests will fail.
* The language tests rely on having the page available in another language
wiki, and the db records to show it.
* Do you have Nearby enabled?  Search? etc?

Each test failure will display a detailed message describing what condition
the test expected and what condition violated that expectation.  I think if
you look at the detailed failure message it will tell you exactly why the
test failed in your environment.

-Chris
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Analysis of the hamburger icon

[Jon Robson]

You can see this in comparison to other features.

Yes it is indeed more useful than items in the menu but as you can see in
the graph the features are near identical in terms of clicks tracked.
However what striked me as odd was that the number of clicks varied
drastically depending on the language (although correlated for all
languages they are not collerated per language).

Yes this could mean other things such as languages are more important in
the given language and thus it is more useful (maybe the language is
incomplete) and tied to what you and Nemo suggested it is more prevalent on
the screen. Yet i cant help but wonder if it also might hint at something
to do with the icons effectiveness especially when I look at well developed
wiki's such as Chinese and Japanese when compared to English.

By the way, we don't have that much fine grained information with regards
to shat type of pages they clicked these features on.

It might be useful to try a different logo on one of the projects e.g.
Japanese and see how this gets impacted by the change. If there is no
drastic change we could probably conclude that indeed my comparison sucks
:) We can certainly use clicks as a guideline of whether the icon is
getting more effective.

I'm ccing analytics in case they have any views on this.
On Dec 5, 2014 2:26 AM, "Amir E. Aharoni" 
wrote:

> The similarity in the numbers is indeed striking, but I don't think that
> it says much about the perception of the hamburger icon. I suspect that for
> most readers the language button is more useful than *any* of the actions
> in the hamburger menu - home, random, nearby, watchlist, settings, log in.
> To confirm it, I'd love to see the the numbers for these other actions.
>
> Also, as Nemo asks, it would be useful to see pages without language links
> separated, and to also see page length taken into account somehow - on a
> short page it is easier to see the languages button (less or no scrolling),
> and there's more motivation to tap it (the hope to read more in another
> language).
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] big improvements to the MobileFrontend browser test repo

[Chris McMahon]

On Fri, Dec 5, 2014 at 8:17 AM, Chris McMahon 
wrote:

>
>
> On Fri, Dec 5, 2014 at 2:23 AM, Joaquin Oltra Hernandez <
> jhernan...@wikimedia.org> wrote:
>>
>> Here you can see vagrant roles, final output of the tests and env
>> variables https://gist.github.com/joakin/eae3b086dd5a0c498669
>>
>
I was thinking some more about this.  Try running the tests in Firefox,
with enviroment variables set properly, using these tags:

bundle exec cucumber --tags @firefox --tags @en.m.wikipedia.beta.wmflabs.org

and see what the results are.  If you have any failures let us know.

-Chris
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] [Apps] Simplified search? It's possible!

[Dan Garry]

Hi everyone,

*tl;dr: The Mobile Apps Team is going to trial seamlessly surfacing full
text search results instead of prefixsearch results in cases where
prefixsearch does not give satisfactory results.*

The Mobile Apps Team has received a lot of feedback that our search feature
isn't the best. Our latest metrics confirm this; around 19% of queries give
the user no results. Our working hypothesis is that this is because we use
prefixsearch on article titles, which is very insensitive to typos and
free-form text.

To help with this, we implemented full-text search. The user has two
options for searching, prefixsearch and full text. You can see this example
 to see what these options look like.

However, the way we present the two options to users is suboptimal. There's
no clear mental model for when one should be used compared to the other.
The design team recommended that we simply present whichever result set is
better for any given query. But how do we decide which result set is
better? To validate this course of action, we audited which of the two
options, prefixsearch or full text search, was better for a set of queries.
The results are here

.

The takehomes of our audit:

   - In cases where there are very few prefixsearch results (less than
   around 5), the full text results are just as good or better than the
   prefixsearch results. Often, this is because the "did you mean"
   functionality of the full text API helps the user out.
   - In cases where there are a good number of prefixsearch results, the
   prefixsearch results tend to be better than the fulltext results.

Here's what we're going to try:

   - Remove the buttons from the UI.
   - By default, use prefixsearch for searches.
   - If there are fewer than 5 prefixsearch results, show fulltext search
   results instead.

Metrics for success:

   - Higher search clickthrough (users finding what they need more)
   - Fewer number of queries give 0 results (users served more results)
   - Fewer number of queries per search session (users finding what they
   need faster)

The advantage of this experiment is that it's safe to fail: there is no
actual UX change, so if we decide our solution isn't good enough, then we
can rollout the fallback of surfacing the buttons without users thinking
we're just endlessly tweaking the UI.

Please do get in touch if you have any questions!

Thanks,
Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Mediawiki-i18n] Analysis of the hamburger icon

[Federico Leva (Nemo)]

Jon Robson, 05/12/2014 17:56:

It might be useful to try a different logo on one of the projects e.g.
Japanese and see how this gets impacted by the change. If there is no
drastic change we could probably conclude that indeed my comparison
sucks :) We can certainly use clicks as a guideline of whether the icon
is getting more effective.


I think you should probably also consider whether a click on the icon is 
followed by a click on a menu item, to exclude most unintentional 
clicks. But yes, I agree it would be very interesting to try out some 
alternatives and see those numbers.


Nemo

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Simplified search? It's possible!

[Tomasz Finc]

I've very excited about this. Where can we see updated search metrics
that don't require manual reports? I want to make sure that everyone
can see these.

--tomasz

On Fri, Dec 5, 2014 at 1:19 PM, Dan Garry  wrote:
> Hi everyone,
>
> tl;dr: The Mobile Apps Team is going to trial seamlessly surfacing full text
> search results instead of prefixsearch results in cases where prefixsearch
> does not give satisfactory results.
>
> The Mobile Apps Team has received a lot of feedback that our search feature
> isn't the best. Our latest metrics confirm this; around 19% of queries give
> the user no results. Our working hypothesis is that this is because we use
> prefixsearch on article titles, which is very insensitive to typos and
> free-form text.
>
> To help with this, we implemented full-text search. The user has two options
> for searching, prefixsearch and full text. You can see this example to see
> what these options look like.
>
> However, the way we present the two options to users is suboptimal. There's
> no clear mental model for when one should be used compared to the other. The
> design team recommended that we simply present whichever result set is
> better for any given query. But how do we decide which result set is better?
> To validate this course of action, we audited which of the two options,
> prefixsearch or full text search, was better for a set of queries. The
> results are here.
>
> The takehomes of our audit:
>
> In cases where there are very few prefixsearch results (less than around 5),
> the full text results are just as good or better than the prefixsearch
> results. Often, this is because the "did you mean" functionality of the full
> text API helps the user out.
> In cases where there are a good number of prefixsearch results, the
> prefixsearch results tend to be better than the fulltext results.
>
> Here's what we're going to try:
>
> Remove the buttons from the UI.
> By default, use prefixsearch for searches.
> If there are fewer than 5 prefixsearch results, show fulltext search results
> instead.
>
> Metrics for success:
>
> Higher search clickthrough (users finding what they need more)
> Fewer number of queries give 0 results (users served more results)
> Fewer number of queries per search session (users finding what they need
> faster)
>
> The advantage of this experiment is that it's safe to fail: there is no
> actual UX change, so if we decide our solution isn't good enough, then we
> can rollout the fallback of surfacing the buttons without users thinking
> we're just endlessly tweaking the UI.
>
> Please do get in touch if you have any questions!
>
> Thanks,
> Dan
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Simplified search? It's possible!

[Monte Hurd]

"If there are fewer than 5 prefixsearch results, show fulltext search results 
instead."

To be clear, in this case the full text results would append after the 5 prefix 
results. 



> On Dec 5, 2014, at 1:19 PM, Dan Garry  wrote:
> 
> Hi everyone,
> 
> tl;dr: The Mobile Apps Team is going to trial seamlessly surfacing full text 
> search results instead of prefixsearch results in cases where prefixsearch 
> does not give satisfactory results.
> 
> The Mobile Apps Team has received a lot of feedback that our search feature 
> isn't the best. Our latest metrics confirm this; around 19% of queries give 
> the user no results. Our working hypothesis is that this is because we use 
> prefixsearch on article titles, which is very insensitive to typos and 
> free-form text.
> 
> To help with this, we implemented full-text search. The user has two options 
> for searching, prefixsearch and full text. You can see this example to see 
> what these options look like.
> 
> However, the way we present the two options to users is suboptimal. There's 
> no clear mental model for when one should be used compared to the other. The 
> design team recommended that we simply present whichever result set is better 
> for any given query. But how do we decide which result set is better? To 
> validate this course of action, we audited which of the two options, 
> prefixsearch or full text search, was better for a set of queries. The 
> results are here.
> 
> The takehomes of our audit:
> In cases where there are very few prefixsearch results (less than around 5), 
> the full text results are just as good or better than the prefixsearch 
> results. Often, this is because the "did you mean" functionality of the full 
> text API helps the user out.
> In cases where there are a good number of prefixsearch results, the 
> prefixsearch results tend to be better than the fulltext results.
> Here's what we're going to try:
> Remove the buttons from the UI.
> By default, use prefixsearch for searches.
> If there are fewer than 5 prefixsearch results, show fulltext search results 
> instead.
> Metrics for success:
> Higher search clickthrough (users finding what they need more)
> Fewer number of queries give 0 results (users served more results)
> Fewer number of queries per search session (users finding what they need 
> faster)
> The advantage of this experiment is that it's safe to fail: there is no 
> actual UX change, so if we decide our solution isn't good enough, then we can 
> rollout the fallback of surfacing the buttons without users thinking we're 
> just endlessly tweaking the UI.
> 
> Please do get in touch if you have any questions!
> 
> Thanks,
> Dan
> 
> -- 
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] iOS Wikipedia app 4.0.6 going into the Apple queue

[Brion Vibber]

Ok, it's made its way through review and should appear in the store &
updates shortly.

-- brion

On Tue, Dec 2, 2014 at 5:07 PM, Brion Vibber  wrote:

> Ok I had a slight fight with iTunes Connect where it was rejecting the
> format of our app icon, which is now resolved. (Apparently you must now
> submit your large app icon without an alpha channel, even if it's opaque,
> and the SVG->PNG conversion from Inkscape creates an alpha channel by
> default. "Lol" as the kids say.)
>
> It's now *really* in the queue, "Waiting For Review".
>
> Now back to merging up the refactorings!
>
> -- brion
>
> On Tue, Dec 2, 2014 at 4:46 PM, Dan Garry  wrote:
>
>> This is a bug fix release to fix the really bad freezing bug we've
>> encountered recently, which is why we're releasing outside of our normal
>> schedule and why the release is a bit bare, feature-wise. We're doing our
>> final testing alongside the Apple review process.
>>
>> Thanks Monte and Brion for your work on this!
>>
>> Dan
>>
>> On 2 December 2014 at 16:40, Brion Vibber  wrote:
>>
>>> Per usual caveat, expect to take a couple days at least to work its way
>>> through review.
>>>
>>>
>>> Numerous small fixes, most notably:
>>>
>>> * fix for horrible hanging bug on certain large articles on iOS 7
>>> * recently-used search list
>>> * translation updates
>>>
>>> The fulltext search mode in the latest betas is not included as it needs
>>> some performance and UI work still. Coming soon!
>>>
>>> -- brion
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>>
>>
>>
>> --
>> Dan Garry
>> Associate Product Manager, Mobile Apps
>> Wikimedia Foundation
>>
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Simplified search? It's possible!

[Dan Garry]

On 5 December 2014 at 13:36, Monte Hurd  wrote:
>
> To be clear, in this case the full text results would append after the 5
> prefix results.
>

Actually, why do we need to do that? I thought the audit showed pretty
clearly that this wasn't necessary. :-)

Try a few queries and see; in almost every case, either the prefix results
are in included in the full text search results, or they're actually really
irrelevant.

Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Simplified search? It's possible!

[Florian Schmidt]

Hello,

that sounds really great! Nice to see big improvements to app search in the 
last and future time :)

Is there a tracking bug/card for this to follow what’s going on?

Kind regards
Florian

Von: mobile-l-boun...@lists.wikimedia.org 
[mailto:mobile-l-boun...@lists.wikimedia.org] Im Auftrag von Dan Garry
Gesendet: Freitag, 5. Dezember 2014 22:20
An: mobile-l
Betreff: [WikimediaMobile] [Apps] Simplified search? It's possible!

Hi everyone,

tl;dr: The Mobile Apps Team is going to trial seamlessly surfacing full text 
search results instead of prefixsearch results in cases where prefixsearch does 
not give satisfactory results.

The Mobile Apps Team has received a lot of feedback that our search feature 
isn't the best. Our latest metrics confirm this; around 19% of queries give the 
user no results. Our working hypothesis is that this is because we use 
prefixsearch on article titles, which is very insensitive to typos and 
free-form text.

To help with this, we implemented full-text search. The user has two options 
for searching, prefixsearch and full text. You can see this example to see what 
these options look like.

However, the way we present the two options to users is suboptimal. There's no 
clear mental model for when one should be used compared to the other. The 
design team recommended that we simply present whichever result set is better 
for any given query. But how do we decide which result set is better? To 
validate this course of action, we audited which of the two options, 
prefixsearch or full text search, was better for a set of queries. The results 
are here.

The takehomes of our audit:
• In cases where there are very few prefixsearch results (less than around 5), 
the full text results are just as good or better than the prefixsearch results. 
Often, this is because the "did you mean" functionality of the full text API 
helps the user out.
• In cases where there are a good number of prefixsearch results, the 
prefixsearch results tend to be better than the fulltext results.
Here's what we're going to try:
• Remove the buttons from the UI.
• By default, use prefixsearch for searches.
• If there are fewer than 5 prefixsearch results, show fulltext search results 
instead.
Metrics for success:
• Higher search clickthrough (users finding what they need more)
• Fewer number of queries give 0 results (users served more results)
• Fewer number of queries per search session (users finding what they need 
faster)
The advantage of this experiment is that it's safe to fail: there is no actual 
UX change, so if we decide our solution isn't good enough, then we can rollout 
the fallback of surfacing the buttons without users thinking we're just 
endlessly tweaking the UI.

Please do get in touch if you have any questions!

Thanks,
Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] iOS Wikipedia app 4.0.6 going into the Apple queue

[Monte Hurd]

Oh! Nice! 


> On Dec 5, 2014, at 1:45 PM, Brion Vibber  wrote:
> 
> Ok, it's made its way through review and should appear in the store & updates 
> shortly.
> 
> -- brion
> 
>> On Tue, Dec 2, 2014 at 5:07 PM, Brion Vibber  wrote:
>> Ok I had a slight fight with iTunes Connect where it was rejecting the 
>> format of our app icon, which is now resolved. (Apparently you must now 
>> submit your large app icon without an alpha channel, even if it's opaque, 
>> and the SVG->PNG conversion from Inkscape creates an alpha channel by 
>> default. "Lol" as the kids say.)
>> 
>> It's now *really* in the queue, "Waiting For Review".
>> 
>> Now back to merging up the refactorings!
>> 
>> -- brion
>> 
>>> On Tue, Dec 2, 2014 at 4:46 PM, Dan Garry  wrote:
>>> This is a bug fix release to fix the really bad freezing bug we've 
>>> encountered recently, which is why we're releasing outside of our normal 
>>> schedule and why the release is a bit bare, feature-wise. We're doing our 
>>> final testing alongside the Apple review process.
>>> 
>>> Thanks Monte and Brion for your work on this!
>>> 
>>> Dan
>>> 
 On 2 December 2014 at 16:40, Brion Vibber  wrote:
 Per usual caveat, expect to take a couple days at least to work its way 
 through review.
 
 
 Numerous small fixes, most notably:
 
 * fix for horrible hanging bug on certain large articles on iOS 7
 * recently-used search list
 * translation updates
 
 The fulltext search mode in the latest betas is not included as it needs 
 some performance and UI work still. Coming soon!
 
 -- brion
 
 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>> 
>>> 
>>> 
>>> -- 
>>> Dan Garry
>>> Associate Product Manager, Mobile Apps
>>> Wikimedia Foundation
> 
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Thumbnail filename URL extraction rules

[Brion Vibber]

Per request in meeting, thought I'd stick it on the public list for
references. :)

As I recall there should be three possible URL formats for images embedded
in  tags in wiki pages or returned as thumbnails via the API:

http(s)?://
upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
^ original-size images

http(s)?://
upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)
?
^ thumbnails

http(s)?://
upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
 ^ this last is used in cases where the filename is very very long and we
can't actually prepend all the options to the filename (happens mostly in
South Asian languages where UTF-8 is 3 bytes per letter)

* project: 'wikipedia' in all cases we need to handle; local files on
Wiktionary etc will have it separate but we don't use these.
* subdomain: language 'en' etc for Wikipedias, subproject for special-case
wikis like Commons/'commons'
* hash1: first digit of md5 hash of the filename (you don't need to use
this here, consider it opaque)
* hash2: first 2 digits of md5 hash of the filename
* base-filename: the base filename -- you want this! This is the raw
filename for files served at original size; thumbnails will use it as a
directory component.
* render-extension: files other than PNG, GIF, and JPEG are rendered to one
of those, usually PNG. So you'll see things like ".svg.png" at times -- but
never ".png.png". These only appear on thumbnails.
* size: thumbnails are always given with the pixel size.
* possible-other-options: Note that other options may include a page number
for PDF, DjVu, or TIFF files, or a time position for video thumbnails. To
avoid parsing that stuff out, consider using the subdirectory base name on
thumbnails if possible.

-- brion
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Thumbnail filename URL extraction rules

[Monte Hurd]

Max showed me how to get the file page url from the api. So if all we have
is the image name we can get the file page url automagically. I attached a
sample query to:
https://trello.com/c/cXEMxGb3/8-5-retrieve-file-metadata-from-commonsmetadata-api-and-display-it-in-the-panel

On Fri, Dec 5, 2014 at 3:52 PM, Brion Vibber  wrote:

> Per request in meeting, thought I'd stick it on the public list for
> references. :)
>
> As I recall there should be three possible URL formats for images embedded
> in  tags in wiki pages or returned as thumbnails via the API:
>
> http(s)?://
> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
> ^ original-size images
>
> http(s)?://
> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)
> ?
> ^ thumbnails
>
> http(s)?://
> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
>  ^ this last is used in cases where the filename is very very long and we
> can't actually prepend all the options to the filename (happens mostly in
> South Asian languages where UTF-8 is 3 bytes per letter)
>
> * project: 'wikipedia' in all cases we need to handle; local files on
> Wiktionary etc will have it separate but we don't use these.
> * subdomain: language 'en' etc for Wikipedias, subproject for special-case
> wikis like Commons/'commons'
> * hash1: first digit of md5 hash of the filename (you don't need to use
> this here, consider it opaque)
> * hash2: first 2 digits of md5 hash of the filename
> * base-filename: the base filename -- you want this! This is the raw
> filename for files served at original size; thumbnails will use it as a
> directory component.
> * render-extension: files other than PNG, GIF, and JPEG are rendered to
> one of those, usually PNG. So you'll see things like ".svg.png" at times --
> but never ".png.png". These only appear on thumbnails.
> * size: thumbnails are always given with the pixel size.
> * possible-other-options: Note that other options may include a page
> number for PDF, DjVu, or TIFF files, or a time position for video
> thumbnails. To avoid parsing that stuff out, consider using the
> subdirectory base name on thumbnails if possible.
>
> -- brion
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Thumbnail filename URL extraction rules

[Monte Hurd]

Oh, here's the query for the record:

http://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=imageinfo&format=json&iiprop=url&iiurlwidth=55&titles=File%3AWiki.png

Should see a  "descriptionurl" in the results with the file page url.

On Fri, Dec 5, 2014 at 4:23 PM, Monte Hurd  wrote:

> Max showed me how to get the file page url from the api. So if all we have
> is the image name we can get the file page url automagically. I attached a
> sample query to:
> https://trello.com/c/cXEMxGb3/8-5-retrieve-file-metadata-from-commonsmetadata-api-and-display-it-in-the-panel
>
> On Fri, Dec 5, 2014 at 3:52 PM, Brion Vibber 
> wrote:
>
>> Per request in meeting, thought I'd stick it on the public list for
>> references. :)
>>
>> As I recall there should be three possible URL formats for images
>> embedded in  tags in wiki pages or returned as thumbnails via the API:
>>
>> http(s)?://
>> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
>> ^ original-size images
>>
>> http(s)?://
>> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)
>> ?
>> ^ thumbnails
>>
>> http(s)?://
>> upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
>>  ^ this last is used in cases where the filename is very very long and we
>> can't actually prepend all the options to the filename (happens mostly in
>> South Asian languages where UTF-8 is 3 bytes per letter)
>>
>> * project: 'wikipedia' in all cases we need to handle; local files on
>> Wiktionary etc will have it separate but we don't use these.
>> * subdomain: language 'en' etc for Wikipedias, subproject for
>> special-case wikis like Commons/'commons'
>> * hash1: first digit of md5 hash of the filename (you don't need to use
>> this here, consider it opaque)
>> * hash2: first 2 digits of md5 hash of the filename
>> * base-filename: the base filename -- you want this! This is the raw
>> filename for files served at original size; thumbnails will use it as a
>> directory component.
>> * render-extension: files other than PNG, GIF, and JPEG are rendered to
>> one of those, usually PNG. So you'll see things like ".svg.png" at times --
>> but never ".png.png". These only appear on thumbnails.
>> * size: thumbnails are always given with the pixel size.
>> * possible-other-options: Note that other options may include a page
>> number for PDF, DjVu, or TIFF files, or a time position for video
>> thumbnails. To avoid parsing that stuff out, consider using the
>> subdirectory base name on thumbnails if possible.
>>
>> -- brion
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Thumbnail filename URL extraction rules

[Jon Robson]

For reference as a learning experiment in alpha, mobile web is
generating infoboxes from Wikidata.
See example @ 
https://en.m.wikipedia.org/wiki/Albert%20Einstein?mobileaction=alpha

We are interested in converting filenames into thumbnail URLs.
Basically wikidata api returns just the title. We are currently thus
using an md5 library to get to the thumbnail. It would be nice to have
a better way of doing this.

I opened a bug [1] but it's not clear what the path forward is for this...

[1] https://phabricator.wikimedia.org/T76827

On Fri, Dec 5, 2014 at 4:24 PM, Monte Hurd  wrote:
> Oh, here's the query for the record:
>
> http://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=imageinfo&format=json&iiprop=url&iiurlwidth=55&titles=File%3AWiki.png
>
> Should see a  "descriptionurl" in the results with the file page url.
>
> On Fri, Dec 5, 2014 at 4:23 PM, Monte Hurd  wrote:
>>
>> Max showed me how to get the file page url from the api. So if all we have
>> is the image name we can get the file page url automagically. I attached a
>> sample query to:
>> https://trello.com/c/cXEMxGb3/8-5-retrieve-file-metadata-from-commonsmetadata-api-and-display-it-in-the-panel
>>
>> On Fri, Dec 5, 2014 at 3:52 PM, Brion Vibber 
>> wrote:
>>>
>>> Per request in meeting, thought I'd stick it on the public list for
>>> references. :)
>>>
>>> As I recall there should be three possible URL formats for images
>>> embedded in  tags in wiki pages or returned as thumbnails via the API:
>>>
>>>
>>> http(s)?://upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
>>> ^ original-size images
>>>
>>>
>>> http(s)?://upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)?
>>> ^ thumbnails
>>>
>>>
>>> http(s)?://upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
>>>  ^ this last is used in cases where the filename is very very long and we
>>> can't actually prepend all the options to the filename (happens mostly in
>>> South Asian languages where UTF-8 is 3 bytes per letter)
>>>
>>> * project: 'wikipedia' in all cases we need to handle; local files on
>>> Wiktionary etc will have it separate but we don't use these.
>>> * subdomain: language 'en' etc for Wikipedias, subproject for
>>> special-case wikis like Commons/'commons'
>>> * hash1: first digit of md5 hash of the filename (you don't need to use
>>> this here, consider it opaque)
>>> * hash2: first 2 digits of md5 hash of the filename
>>> * base-filename: the base filename -- you want this! This is the raw
>>> filename for files served at original size; thumbnails will use it as a
>>> directory component.
>>> * render-extension: files other than PNG, GIF, and JPEG are rendered to
>>> one of those, usually PNG. So you'll see things like ".svg.png" at times --
>>> but never ".png.png". These only appear on thumbnails.
>>> * size: thumbnails are always given with the pixel size.
>>> * possible-other-options: Note that other options may include a page
>>> number for PDF, DjVu, or TIFF files, or a time position for video
>>> thumbnails. To avoid parsing that stuff out, consider using the subdirectory
>>> base name on thumbnails if possible.
>>>
>>> -- brion
>>>
>>> ___
>>> Mobile-l mailing list
>>> Mobile-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>>
>>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] How good is our search? Here's some data!

[Jon Robson]

I noticed many bilingual friends search in their native language on
English Wikipedia. It would be interesting to look closely at search
terms and see if they are mispellings, different languages or just our
search failing them.


On Wed, Dec 3, 2014 at 11:01 PM, Amir E. Aharoni
 wrote:
> Thanks.
>
> This is not directly related, but some time I'd love to see data about
> interlanguage links tapping on all media - iOS, Android, MobileFrontend.
>
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> ‪“We're living in pieces,
> I want to live in peace.” – T. Moore‬
>
> 2014-12-04 4:15 GMT+02:00 Dan Garry :
>>
>> We've now got some preliminary data in about how effective our search is
>> in mobile apps. Note that this is only half a day's data, and it's sampled
>> at 1%.
>>
>> High-level metrics:
>>
>> Number of searching sessions which end by tapping on a result: 91%
>> Percentage of queries that give 0 results: 19%
>> Mean queries per searching session: 3.8
>> Median user-perceived time taken to retrieve search results: 486ms
>> 90th percentile of user-perceived time taken: 898ms
>>
>> My quick take-homes from this:
>>
>> 91% clickthrough seems pretty good.
>> 19% of queries giving "no results" seems really bad.
>> The combination of the above two means users are generally finding what
>> they need, but that it's a struggle to do it.
>> User-perceived performance seems pretty good; 90% of our users get search
>> results within a second!
>>
>> What I think our next steps are:
>>
>> Push out our new search improvements and see how these baselines change.
>> Try to tackle the "0 results" problem, which seems to be more of a problem
>> than clickthrough.
>>
>> Spreadsheet containing my queries and processed data:
>> https://docs.google.com/a/wikimedia.org/spreadsheets/d/1syLgNygAS7Prxxg7RTIvK3vxwyVG-ZkjxtK0LSbU76w/edit
>>
>> Dan
>>
>> --
>> Dan Garry
>> Associate Product Manager, Mobile Apps
>> Wikimedia Foundation
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l