I happened to be looking at the proposed Q3 goals yesterday, currently they
say:
- Make www.wikipedia.org a portal for exploring open content on
Wikimedia sites.
- Bring more consistency to the user experience for search across
desktop, mobile web, and mobile apps.
- Enhance search results and expose users to other interesting content
by improving interwiki search integration.
My concern is that our current user satisfaction metric suggests 15% of
users are happy with the results they are getting. This is really bad. I
would prefer to see us focus on search relevance and improving the scoring
of what we already have before spending more focus on interwiki search. I
don't have anything to point to yet, but for search satisfaction to be so
low I don't think that's because we arn't surfacing content from other
wiki's, I think its because when you search for something we surface all
kinds of results that aren't nearly as relevant as other data we have in
the corpus.
I really want to see us focus on fixing what we already have and validating
the features we already support before we go whole hog on incorperating all
kinds of new data.
Erik B.
Hi,
I am excited to announce you that we now have a performance dashboard
(speed) for the wikipedia.org portal page.
Thanks to Ori and Peter from the performance team to listen to us and make
this dashboard happen in a few days only.
Some context:
Moiz and I had a quick discussion late last week with Ori. I wanted to meet
the Performance team and see what tools they are using and if we could
benefit from that to measure the performance improvements made on
www.wikipedia.org portal page. It turns out they have tools, and they are
excited in making them available to us!
They are heavily using http://www.webpagetest.org/ as their performance
tool to test static pages. And even better, the Performance Team runs a
private instance of WebPageTest at http://wpt.wmftest.org on AWS, they
collect all the metrics and display them into a great dashboard.
I met Peter this morning and he showed me the dashboard and how it works.
Peter was also very excited to collaborate to collect metrics for the
wikipedia portal and see a desire to improve this page with performance in
mind (and using their new tool for that).
As of now, the dashboard is available here:
https://grafana.wikimedia.org/dashboard/db/webpagetest
You must select: *Project -> portals *to see www.wikipedia.org metrics.
Looking forward to push the first improvements!
Hi all,
The Analysis team is excited to bring you a new feature to the search
metrics dashboard. While the dashboard users have always been able to
manually select a date range, it wasn't clear how to do that (by clicking
and dragging in the interactive graphs) and getting specific date ranges
was difficult.
To address this, we've added the ability to use a preset (e.g. last 7/30/90
days) or specify a custom range with a user-friendly calendar widget. For
an example of this, see http://discovery.wmflabs.org/metrics/#failure_rate
As with our previous release of smoothing, there is an option to set the
time frame at a global level affecting all graphs or just at individual
graph level.
Cheers,
Mikhail on behalf of Discovery's Analysts
http://accesslint.com/ is similar to the Google page evaluation
system, but it looks for accessibility issues. Should be looked at (or
something analogous!) with the portal redesign!
--
Oliver Keyes
Count Logula
Wikimedia Foundation
Now that we have the feature deployed (behind a feature flag), and have an
initial "does it do anything?" test going out today, along with an upcoming
integration with our satisfaction metrics, we need to come up with how will
will try to further move the needle forward.
For reference these are our Q2 goals:
- Run A/B test for a feature that:
- Uses a library to detect the language of a user's search query.
- Adjusts results to match that language.
- Determine from A/B test results whether this feature is fit to push to
production, with the aim to:
- Improve search user satisfaction by 10% (from 15% to 16.5%).
- Reduce zero results rate for non-automata search queries by 10%.
We brainstormed a number of possibilities here:
https://etherpad.wikimedia.org/p/LanguageSupportBrainstorming
We now need to decide which of these ideas we should prioritize. We might
want to take into consideration which of these can be pre-tested with our
relevancy lab work, such that we can prefer to work on things we think will
move the needle the most. I'm really not sure which of these to push
forward on, so let us know which you think can have the most impact, or
where the expected impact could be measured with relevancy lab with minimal
work.
Hi Discovery,
Just an FYI that the wikidata team is doing something that touches mobile
search on wikidata. The paragraph below from Lydia is the relevant one:
On Fri, Nov 6, 2015 at 2:34 PM, Lydia Pintscher <
lydia.pintscher(a)wikimedia.de> wrote:
> * The others are for fixing the search. Wikidata's page titles are the
> Q IDs. The default search on mobile uses page titles. So to find
> anything you have to type in the Q ID. This is obviously not very
> useful. It needs to work on labels like it does on the desktop site.
> To see the problem simply type some word into the search box on the
> mobile site and then try the same with typing Q1.
>
It belongs to this phab ticket: https://phabricator.wikimedia.org/T85368
Which belongs to this epic about getting wikidata to work on mobile:
https://phabricator.wikimedia.org/T78430
-J
---------- Forwarded message ----------
From: Lydia Pintscher <lydia.pintscher(a)wikimedia.de>
Date: Fri, Nov 6, 2015 at 2:37 PM
Subject: Re: [Reading-web-team] JK: Wikidata Mobile
To: Jon Katz <jkatz(a)wikimedia.org>
Cc: Jon Robson <jrobson(a)wikimedia.org>
On Fri, Nov 6, 2015 at 11:34 PM, Lydia Pintscher
<lydia.pintscher(a)wikimedia.de> wrote:
> Hey :)
>
> Bene is doing this in part as a volunteer and in part as an intern for
> us (he started earlier this week).
> The patches are parts of fixing two remaining issues we have from what
> I can tell:
> * The table of content box is bigger than the actual table of content
> entries. You can see this here for example:
> https://m.wikidata.org/wiki/Q2
> * The others are for fixing the search. Wikidata's page titles are the
> Q IDs. The default search on mobile uses page titles. So to find
> anything you have to type in the Q ID. This is obviously not very
> useful. It needs to work on labels like it does on the desktop site.
> To see the problem simply type some word into the search box on the
> mobile site and then try the same with typing Q1.
>
> Hope that helps.If you have more questions please let me know.
Oh and the relevant ticket for getting Wikidata to work nicely on
mobile is: https://phabricator.wikimedia.org/T78430 I think once the
search and the table of content are fixed I think we're done there and
I'll have Bene work on other things again. I don't plan to tackle
editing further at the moment.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
This caught my eye. I don't fully understand it, but it has the word
"search" in it, so we should probably be aware of it.
> The reading team are keen to have watchstars in more places
> other than just at the top right of the page you are viewing.
> We already supporting adding things to the watchlist in search,
Kevin Smith
Agile Coach, Wikimedia Foundation
---------- Forwarded message ----------
From: Jon Robson <jrobson(a)wikimedia.org>
Date: Wed, Nov 4, 2015 at 10:48 AM
Subject: [Wikitech-l] Rewriting the watchstar code in OOjs UI / performance
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
The reading team are keen to have watchstars in more places other than
just at the top right of the page you are viewing.
We already supporting adding things to the watchlist in search,
nearby, watchlist and gather.
We are working on a read more feature which will add a list of pages
with watchstars at the bottom of the page [1]
The code in desktop however is limited in that it is only written to
be usable by the page in question. It does various things such as use
the element id to reflect state (#ca-watch or #ca-unwatch) and runs
once on loading of the script.
We'd like to make this code more reusable so watchstars can be placed
in any interface but this comes with problems.
The model part is not too controversial but when it comes to creating
a reusable UI it becomes a little more complicated.
If we are to turn this into an OOjs UI widget, this would mean that
the OOjs UI library gets pulled in on every single page load. The OOjs
UI library, without styles or icon assets from what I can see is 226.5
kB (without gzip), (for comparisons Backbone is 69kb and React js is
559kb). This is not necessarily an issue, if all our code is built in
OOjs UI but right now we are very very far from that world, so we need
to find a strategy to getting there.
We know this is a problem. When Echo relaunched the new interface
there was a huge spike in first paint [2]. It seems the solution to
this was to render the button on the server side and defer load the
library to avoid this impact on first paint but the underlying problem
still remains - server side rendering is not an option for my team,
so to create a component the standard way we have to load this entire
library.
We have a similar problem with adopting OOJS UI in MobileFrontend. We
want to simply render/style a button on page load via JavaScript and
the library is too heavy weight for this, especially when right now we
don't have use cases for more complicated widgets such as layouts,
popups, windows, toolbars [3]... in fact we already have other
libraries that fulfill these needs that at some point will need to be
converted to oojs ui.
There's been some talk but little movement about cutting up the oojs
ui library into chunks to make it more adoptable by less complex
projects who just need buttons/inputs and other form elements. Is this
still an option? If so, how can we move this along? If not how can we
proceed?
I really think now is the time to talk about this, as adoption outside
the editing team still seems to be limited and from my point of view
this is one of the biggest barriers.
[1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Read_more
[2] https://phabricator.wikimedia.org/T112401
[3] https://www.mediawiki.org/wiki/OOjs_UI
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Stas created a "Discovery" category on mediawiki.org[1], and has associated
several pages with it. As you create, edit, or notice additional pages that
should be part of that category, please tag them as well. This should help
people find Discovery-related content without having to navigate through as
many links.
[1] https://www.mediawiki.org/wiki/Category:Discovery
Kevin Smith
Agile Coach, Wikimedia Foundation
Google Code-In (GCI) is "a contest to introduce pre-university students
(ages 13-17) to the many kinds of contributions that make free and open
source software (FOSS) development possible. Students must complete tasks,
one at a time. It is sponsored and run by Google. The Wikimedia Foundation
has participated since 2013. The Google Code-in 2015 contest runs from
December 07, 2015 to January 27, 2016"
The full mediawiki page about GCI is here[1]. The question for us is
whether it would be worth spending some time getting our phabricator tasks
flagged in ways that these students could meaningfully contribute.
The page[1] mentions both "beginner" tasks (30 minutes effort by an
experienced developer), and normal tasks (2-3 hours for someone
experienced). The normal tasks should have 2 mentors available.
Any interest?
[1] https://www.mediawiki.org/wiki/Google_Code-in_2015
Kevin Smith
Agile Coach, Wikimedia Foundation