Page MenuHomePhabricator

Preparing for a multi-device world plenary at 2015 MediaWiki Developer Summit
Closed, ResolvedPublic

Description

https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule
Monday 26, 10:30am

@Tfinc is the owner of the Mobile theme at the MediaWiki-Developer-Summit-2015. He is also in charge of organizing the Mobile plenary session, or find someone to organize it.

meeting notes: http://etherpad.wikimedia.org/p/MWDS2015_multi-device_world

Event Timeline

Qgil assigned this task to Tfinc.
Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil changed Security from none to None.
Qgil subscribed.

Current feeling is to have the tech leads from mobile web @kaldari and apps @Dbrant @Mhurd present on at least 1 and at most 2 products/features that they've shipped over the last 6 months to highlight what's possible on mobile and what is difficult and/or impossible to do. It would be interesting to have @Maryana and @Deskana weigh in on those too. I'm going to be eager to paint the narrative of opportunity and highlight where we can do better. Especially along API's, services, etc.

We spent some time earlier this week brainstorming some potential sessions to get us started

http://etherpad.wikimedia.org/p/Mobile-WMDS

Picking this back up now that were all back.

Tech leads: @kaldari @Dbrant @Mhurd @Jdlrobson

We have a 45min plenary that were going to be creating here. I'd like to have your list of topics by Thur of this week to review and be able to run the by Damon on Friday. Each topic should take up 10-20 if your presenting with someone else or 10-15 if your on your own. Out of these we'll need to think about the potential breakout sessions we brainstormed last month [1] and get them on the MediaWiki Developers Summit Schedule [2]

No need to create slides at this point (or at all if your demoing), keep them at high level bullet points so that we can validate with Damon and move forward.

If there are others that want to jump in on the planning of this then please let me know.

[1] - http://etherpad.wikimedia.org/p/Mobile-WMDS
[2] - https://docs.google.com/spreadsheets/d/15pMDR_h84KUTQK7IR95etVJyJBYC5nVxoG9k_9danV0

MZMcBride renamed this task from Mobile plenary session at #MWDS15 to Mobile plenary session at 2015 MediaWiki Developer Summit.Jan 6 2015, 10:15 PM

Early thoughts:
"Think outside the wikitext"(play on think outside the box) In addition to demoing the obvious Wikigrok, in the plenary I would like to propose demoing the Wikidata infobox editing/lead photos in alpha [1]. Although we currently have no plans to productise this and this is an experimentation project, I think it would be a useful thought exercise to imagine a world where we start breaking down wikitext and reducing our dependency on {{template markup}} and explore other ways to edit that are not via the traditional wikitext model.

I'm not sure what the reaction to this will be. For instance if infoboxes were generated from Wikidata and not within the markup how would our existing community react to that? But I'd hope it might polarise the crowd and lead to some interesting conversations going out of it.

I think essentially the role of mobile is to break down the complicated wikitext markup language that we have built over the last 10 years and encourage our projects to dogfood Wikidata more and make wikitext easy for newbies to understnd again. Microedits are proving successful in mobile and we need to find better ways to support that. @GWicke and I have talked about how Parsoid can help do things such as insert citations in place of 'citation needed' text and I'm hoping we can have a session around Parsoid/Mobile in one of the later sessions to continue this theme.

[1] http://en.m.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein?wikidataid=Q937&mobileaction=alpha

What are we aiming to achieve in this Mobile plenary session? You will have all the Summit attendees in one room, right after the opening. Which are the key messages you want to push? What do you want from them?

explore other ways to edit that are not via the traditional wikitext model.
(...)
I think essentially the role of mobile is to break down the complicated wikitext markup language that we have built over the last 10 years and encourage our projects to dogfood Wikidata more and make wikitext easy for newbies to understand again.

I wonder how this 'role of mobile' you are describing fits with the role of VisualEditor and the Editing plans altogether. CCing JamesF.

I think we need to have a large group alignment conversation about our engineering strategy around mobile, and what the organization as a whole should be doing. I repeatedly hear skepticism about the fall of desktop and rise of mobile as a reason to drop what we're doing and have everything be about mobile. It's not so much skepticism about the fact that it's happening (though there is a little misplaced skepticism there), but cynicism about what that fact is being used to justify.

The temptation on this session would be to "go with what we know", which is lots of presentations and demos. These will be utterly unconvincing and unengaging to mobile strategy skeptics. I think it likely needs to be a conversation rather than a presentation in order to win over skeptics, but exactly what this looks like is a bit unclear to me.

I think we need to have a large group alignment conversation about our engineering strategy around mobile, and what the organization as a whole should be doing. I repeatedly hear skepticism about the fall of desktop and rise of mobile as a reason to drop what we're doing and have everything be about mobile. It's not so much skepticism about the fact that it's happening (though there is a little misplaced skepticism there), but cynicism about what that fact is being used to justify.

The temptation on this session would be to "go with what we know", which is lots of presentations and demos. These will be utterly unconvincing and unengaging to mobile strategy skeptics. I think it likely needs to be a conversation rather than a presentation in order to win over skeptics, but exactly what this looks like is a bit unclear to me.

It sounds like these "mobile skeptics" you're alluding to assume that WMF has already formulated some big mobile master plan (and perhaps cynically believe it involves ditching desktop development altogether...?), but the reality is that our mobile teams and projects are still very new/emergent, we're still in the exploratory phase with a lot of our work, and there are still many ideas floating around for the directions mobile could go in the future. So I think a "group alignment conversation" is a bit premature. It might be better just to provide a space to talk openly about all these possible future directions (mobile as a service! mobile as the one skin to rule them all! mobile as the shiny new unicorn!, etc.), without necessarily forcing any sort of consensus on the process or making it seem like any of these things are going to happen tomorrow ;)

We should definitely have at least one presentation about microcontributions via Wikidata. This would probably show off WikiGrok and possibly the experimental infobox and description editing. I would really like to have Jon's ForiegnApi code (https://gerrit.wikimedia.org/r/#/c/182134/) implemented as a core mediawiki module before then so that people can hack with it in the break-out sessions (on both desktop and mobile). Other possible things to demo include the experimental lead section styling in alpha and the mobile Media Viewer.

It sounds like these "mobile skeptics" you're alluding to assume that WMF has already formulated some big mobile master plan (and perhaps cynically believe it involves ditching desktop development altogether...?), but the reality is that our mobile teams and projects are still very new/emergent, we're still in the exploratory phase with a lot of our work, and there are still many ideas floating around for the directions mobile could go in the future.

I'm not sure where you get new/emergent from. MobileFrontend is not new. And there was a completely separate mobile site before it and a completely separate mobile site before that, so we're talking about many years of experience here.

A lot of mobile development has come about as the result of either stripping everything away and slowly and painfully re-implementing it (category links at the bottom of the page is a small example of this) or the result of trying to inject features into mobile first as a means of bypassing what would likely be outright rejection, for better or worse, on desktop (Special:UserProfile and the last edit strapline at the top of the page are two examples of this).

So, scare quotes or not, yeah, there needs to be a discussion about what mobile development has looked like and what it should look like going forward. The cold hard truth is that writing an encyclopedia (or a dictionary or a whatever) on the desktop site continues to be a pretty agonizing process. It's basically currently impossible to do serious editing on a mobile device and may remain so indefinitely, again for better or worse. The best we can probably hope for is optimizing micro-contributions, as kaldari says, and reunifying the desktop and mobile experiences, work on which has thankfully finally started.

It sounds like these "mobile skeptics" you're alluding to assume that WMF has already formulated some big mobile master plan (and perhaps cynically believe it involves ditching desktop development altogether...?),

@Maryana, I have heard in meetings the murmurings of putting desktop on hold. Not from you, and I don't think the suggestion has truly taken root in our planning process, but I believe it's well worth spelling out (or discussing) in a plenary a very general sense of the size and shape of our investment in desktop vs mobile user interface in the next year or two. I'll grant you that there's no master plan, but I've also heard many intelligent and compelling hunches about what the right strategy is.

We will probably need to state the (only seemingly obvious) point that it's not a zero sum game where more mobile investment == less desktop investment. For example, while our work on Wikidata querying (T85159) was motivated by a mobile use case, there is absolutely nothing mobile specific about the service. In fact, the heart of our strategy almost certainly needs to be minimizing the cases where we are making zero sum tradeoffs.

However, there are going to be cases where it is zero sum. Good user interface is messy like that. We need to have a frank conversation about how much to invest in which area.

but the reality is that our mobile teams and projects are still very new/emergent, we're still in the exploratory phase with a lot of our work, and there are still many ideas floating around for the directions mobile could go in the future.

I don't think this part needs a great deal of consensus building. It needs some, because we have a lot of people working on it, and so one could argue we could scale back a little, but that's not the most urgent aspect that requires a big group conversation, and that's not what I was thinking of.

So I think a "group alignment conversation" is a bit premature. It might be better just to provide a space to talk openly about all these possible future directions (mobile as a service! mobile as the one skin to rule them all! mobile as the shiny new unicorn!, etc.), without necessarily forcing any sort of consensus on the process or making it seem like any of these things are going to happen tomorrow ;)

Sure, there are limits to what we can accomplish in one session or even over the course of two days. Just having the open conversation might be enough. And, we don't have to "force" consensus in any way. However, I think we should inject some amount of urgency and relevance to the conversation, and aspire to actually get something done by having the conversation.

BTW, as long as we're using quotes here, I am going to have to point out that I did say "mobile strategy skeptics" and not "mobile skeptics" :-)

Qgil triaged this task as Medium priority.Jan 8 2015, 12:17 PM

@Maryana, I have heard in meetings the murmurings of putting desktop on hold. Not from you, and I don't think the suggestion has truly taken root in our planning process, but I believe it's well worth spelling out (or discussing) in a plenary a very general sense of the size and shape of our investment in desktop vs mobile user interface in the next year or two. I'll grant you that there's no master plan, but I've also heard many intelligent and compelling hunches about what the right strategy is.

We will probably need to state the (only seemingly obvious) point that it's not a zero sum game where more mobile investment == less desktop investment. For example, while our work on Wikidata querying (T85159) was motivated by a mobile use case, there is absolutely nothing mobile specific about the service. In fact, the heart of our strategy almost certainly needs to be minimizing the cases where we are making zero sum tradeoffs.

Investments into creating a service-oriented architecture for our projects is another example of this choice often not being zero-sum; the mobile apps as pure API consumers benefit greatly from having cleanly defined services, but in actuality this benefits any API consumer, and there are plenty of API consumers on desktop! And, although the discussion about front-end standardisation is of prime importance to mobile web and desktop, it's irrelevant for the mobile apps as they use the front-end frameworks and design patterns that come with the iOS and Android SDKs and platforms. So, even that isn't as zero-sum as it appears! :-)

On the topic of service-oriented architecture, Rob raised the astute point that although service-oriented architecture may seem obvious to us at the WMF, it may not be obvious to others. Our developer community is very decentralised, and one of the disadvantages of a decentralised community is that a bit harder to get people to rally around a totally new concept and way of doing things, such as SOA. And since there is clearly a big belief that service-oriented architecture is the future, the developer summit is a prime opportunity to speak to this decentralised community and evangelise service-oriented architecture to them. Is @GWicke planning anything such as this for the summit?

@Deskana, we'll have a plenary and several other sessions about SOA at the summit. See T85154 and T86028.

I'm not sure yet whether there will be a dedicated evangelization session, but there should be an evangelizing effect in any case.

Apps! Try all the things!

Native apps provide a unique opportunity to showcase Wikipedia media and data, in boundary pushing, even beautiful ways.

With "lead image styling" we've mixed article title, main image and Wikidata descriptions seamlessly at the top of the article.

With search results, saved pages, recent and nearby items we've incorporated Wikidata descriptions.

With native article image galleries, users get instant access to a liquid smooth image browsing interface.

With nearby we've leveraged location awareness and native performance to guide readers to article geodata coordinates.

APIs for search, nearby and article data were enhanced to return Wikidata descriptions so we didn't have to make separate requests. Other API clients can now do this as well.

Challenges & Opportunities.

One challenge we encountered with lead image styling was intelligent cropping for constrained lead image presentation. It can be difficult, given widely varying image dimensions, to determine what the "focal area" of an image is so we don't crop through it. Happily, apps can performantly determine certain image focal areas, so we don't crop a notable person's face noticeably in half.

However, there are edge cases. But we see these challenges as opportunities. If apps could hit a "commons data" endpoint for images, they could report back apps-detected image focal areas, and apps interfaces for users to curate focal area data would be trivial to implement as well. Then any consumer of commons images could easily perform intelligent cropping.

Thoughts so far:
The goal of the native Mobile Apps is to bring the contents of Wikipedia as close as possible to the user's fingertips. This means:

  1. Integrating more tightly with the OS on the user's device (notifications, widgets, location-based things, etc). This would require things like server-side APIs/infrastructure for push notifications.
  2. Presenting content in ways that the user "expects" to see, based on other patterns and behaviors in the mobile OS. In this vein, Wikipedia content has to become more "parceled" into factoids for consumption on mobile. (Thus, an ever-growing dependency on Wikidata)

We've started to tackle some of #2, with our implementation of Lead Images, as well as the Gallery feature (not to mention Wikidata descriptions throughout the app).
We could begin by demoing our work on lead images, and the associated successes and challenges that came out of it. We'll show a few articles where the lead image looks excellent and really transforms the first-glance experience of the article. We'll also show some articles where the lead image is "suboptimal", which would lead to a discussion about face detection for proper alignment of the image, a possible microcontribution for the proper cropping/alignment of the image (or indeed which image to use as the lead image), etc.

Here's a quick outline for a presentation on WikiGrok:

Motivation:

  • Give readers an easy way to make contributions on mobile
  • Help build Wikidata for the semantic future
  • Experiment with game-like contribution methods

History:

  • Magnus's Wikidata Game
  • Consulted Magnus at Wikimania 2014 and built prototypes
  • First working versions October 2014 (A and B versions)
  • Rewrote backend to be scalable
  • Removed dependency on Magnus's Wikidata query API
  • Test for logged in users (December 2014)
  • Test for anonymous readers (January 2014)
  • WikiGrok Roulette (January 2014)

Future:

  • Pick an interface version
  • Push data to WikiGrok
  • Add new campaigns
  • Use to verify existing data or data from other databases
  • New Wikidata query engine for asking better questions
  • Desktop version?
  • More gamification?

Personally I want people to come out of the session with the mind to explore the limitations of our existing software when it comes to editing and challenges these issues.

From Mobile Web perspective, summarising what @kaldari and I have said I can see the tdlr as

  • People have less time and need new ways to contribute especially on mobile
  • We are exploring new was such as Wikigrok and infoboxes (we could refer to mobile uploads and how that showed a thirst to edit but wasn't the right fit)
  • Editing does not have to be editing a big chunk of text e.g. wikitext/VisualEditor full edit page
  • Take away: How can we do more of this? How can we break down our current editing model using things like wikidata and Parsoid? Let's spend the summit exploring that.
Tfinc renamed this task from Mobile plenary session at 2015 MediaWiki Developer Summit to Plenary: Preparing for a multi-device world.Jan 12 2015, 9:48 PM
Tfinc renamed this task from Plenary: Preparing for a multi-device world to Preparing for a multi-device world plenary at 2015 MediaWiki Developer Summit.
Tfinc updated the task description. (Show Details)

Good discussion today about the plenary and focusing it on the challenges of preparing for a multi device world and what technological blockers/opportunities we have. We've done a quick pass on what we'd like to highlight:

  • Desktop <-> Mobile convergence
    • Highlight success/challenges of building for both
  • Building mobile-relevant applications
    • Wikirgrok, infoboxes, etc
  • WikiData
    • How recent mobile app work can enable new desktop workflows
  • Editing/Micro Contributions (Gabriel/JonR)
  • What's slowing us down?
    • API availability

Which may change as the week goes on. Over the next days we'll prepare a short plenary on this, room for discussion, and the the relevant breakout sessions.

notes: http://etherpad.wikimedia.org/p/DevSummitMain

Currently you have 45 minutes for this plenary session, and right after you have another 45' slot in the main room for a non-plenary session to be defined. If you want to pre-schedule this second session, we need urgently a task describing it. Or perhaps you want to extend this topic, having a short break after the first 45' leading to a discussion among those staying in the room?

Please update the description with the achievements of this session. Thank you in advance.

Is there a reason this task is still open?

Is there a reason this task is still open?

Let's find out.