Page MenuHomePhabricator

Aim for workflow equivalence for MediaWiki on desktop and mobile web
Open, Needs TriagePublic

Description

As mobile usage continues to increase, the strategy of putting some features only on desktop web and others only on mobile web will become a worse and worse user experience; users will expect things to be consistently available on mobile.

We should aim for workflow equivalence (not necessarily exact 1:1 feature equivalence) where a platform blocker does not prevent something from working in one or the other place. In many cases we can ship the same JS/CSS modules and make sure they work on both mobile and desktop skins/layouts, though some cases will still require some target-specific adjustments.

This doesn't necessarily mean always running the same code or using the same skin, though when suitable it's a good practice. (cf "responsive" and "mobile first" buzzwords :)

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusAssignedTask
OpenNone
OpenNone
DuplicateNone
OpenNone
DeclinedNone
DeclinedNone
OpenNone
DuplicateNone
DeclinedNone
OpenNone
DeclinedNone
DeclinedNone
OpenNone
OpenNone
StalledNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Openbrion
ResolvedTheDJ
OpenNone
OpenNone
DuplicateNone
OpenNone
DeclinedNone
Resolved Jdlrobson
DuplicateNone
OpenNone
OpenNone
OpenNone
ResolvedNemo_bis
ResolvedMaryana
Resolvedovasileva
InvalidNone
Resolved Jdlrobson
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
DuplicateNone
DuplicateNone
DuplicateNone
OpenNone

Event Timeline

brion created this task.Feb 15 2017, 1:33 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 15 2017, 1:33 PM
brion added subtasks: T61207: Thanks given via mobile are not shown on desktop history page, T98491: TimedMediaHandler user experience is poor on mobile, T65504: Consolidate code for MediaViewer across desktop and mobile (tracking), T58817: Watchlist features available on desktop that aren't on mobile yet (tracking), T127268: Dismantle ResourceLoader's "targets" system, T67078: Allow feedback for mobile beta features like Desktop, T99003: (3) Fix up Special:Upload in mobile and desktop Minerva, T67983: toaster overlay for watchlisting is inconsistent between mobile and desktop, T89219: "Last modified..." text differs between desktop and mobile, T69799: Mobile watchlist should follow the same Show/Hide preferences as the desktop watchlist, T148047: Desktop MediaWiki should be able to lazy load images, T113844: Make the mobile edit conflict screen nicer to use, T144571: Mobile Media Viewer violates user settings, T124168: Show Navbox templates in mobile skins, T123694: Allow mobile web edits to be marked as minor, T133085: Graphs are not mobile friendly, T120755: Mobile-friendly framework for multi-column portal and project pages, T72787: Tooltip notifications not implemented with mobile in mind, T122305: [EPIC] Make Special:Contributions in core mobile friendly, T148049: Make APISandbox useable on mobile, T49858: Enable jquery.tablesorter on mobile, T144299: Dashboards working on mobile , T62565: TMH totally broken on mobile, T152841: Nowrap template not working on mobile site, T95878: [Story] Make Wikidata editable on mobile web, T94998: Make Share-a-fact available on desktop, T72142: Make minerva a presentable desktop skin (tracking), T145409: Have recently viewed articles section on desktop mediawiki and ideally sync with mobile app, T149487: MobileFrontend talk overlay URL's are being shared and do not resolve on desktop site.Feb 15 2017, 1:45 PM
brion updated the task description. (Show Details)Feb 15 2017, 4:47 PM
TheDJ added a subscriber: TheDJ.Feb 15 2017, 5:34 PM

While I generally agree with this goal I would like to note two things:

1: Feature equivalence does not mean implementation/usage equivalence
2: There is a space/need for a -lite version of our website

Personally the biggest problem I see right now:
We've been stuck in Vector. Our editors require a high density UI, which is mostly opposed to the needs of readers. We need to devise how we tackle this conversion of UI requirements as our incoming users 'level up'. For instance, I'd love to make Minerva a desktop skin, but we will also have to make it an editor's skin, if we don't want to totally surprise users once they start editing.

And that last point is much more difficult than any of the tasks listed here.

Jdlrobson added a subscriber: Jdlrobson.EditedFeb 15 2017, 7:16 PM

Just to note this is an infinite amount of work and the bottleneck is design and listening to designers IMO.

I'd like to point out this task will never be completed just like the "imporve documentation" one :)... Especially when the majority of new things built tend not to be tested on mobile till the last minute. We're forever playing catch up... It's definitely a worthy goal to aim for though.

Making a truly responsive site is not easy. It's not simply a case of slapping some media queries on existing experiences... It shouldn't be an afterthought... Ever. If you want true feature parity then we should never be hiding things with display:none (currently this appears to be the norm) and we should not be cluttering interfaces with links or cramming lots of them together. If we truly care about mobile we should be rethinking our designs from the start with mobile in mind.

A few truly honest questions that I don't know the answer for:

  • How can we get people thinking about mobile devices and testing on Minerva just as much as they do with Vector while building software/editing templates?
  • How can we lead big changes in the html of legacy code where html markup is hard to change? For instance, the watchlist is a great case study. Any change to watchlist desktop HTML leads to upsetting our desktop community, but it is too cluttered for a mobile user... hence why the watchlist was begrudgingly rebuilt in the MobileFrontend extension.

Compare: fully functional desktop Minerva Watchlist with mobile Minerva watchlist

@TheDJ if you want to help Minerva a desktop skin (exposing it as a desktop preference), it's not that far away from being usable (and hidden from preferences) I'd love to sit down with you and work on this. I'll be in Vienna if we want to run a hack session there :) We could also get Vector mobile off the ground and make it possible to change the mobile skin in preferences. A lot of the work is done: https://en.wikipedia.org/wiki/San_Francisco?useskin=minerva
.... but to work there are a lot of MobileFrontend concepts that need to be upstreamed or reworked for core, namely preference and languages: https://en.m.wikipedia.org/wiki/Special:MobileLanguages/San_Francisco and https://en.m.wikipedia.org/wiki/Special:Preferences

ashley added a subscriber: ashley.Feb 15 2017, 8:14 PM
Dvorapa added a subscriber: Dvorapa.Mar 8 2017, 6:04 AM
Izno added a subscriber: Izno.Apr 4 2017, 5:21 PM
pmiazga added a subscriber: pmiazga.Sep 5 2017, 1:30 PM

This task as worded still continues to trouble me as although the goal is admirable it's unrealistic. We should be striving for "workflow equivalence" not "1:1 feature equivalence". I think that's what you meant reading through the task, but I worry the description is ambiguous and open to interpretation.

Certain complex interfaces are just not going to work on mobile as is e.g. VisualEditor. We should be able to give a good experience, but we can't have the same expectations of how VisualEditor will have feature equivalence to desktop. Maybe the toolbar has less features for example.

While it's nice to think all MediaWiki's features will work on mobile, from my experience that's just not plausible. Striving for same workflows e.g. I can edit! I can see recent changes! I can view diffs! should be what we are aiming for.

MobileFrontend currently adds mobile versions of desktop experiences, which I think goes some way to solve this without rocking the boat - I just wish MediaWiki was architected better to allow this with clear separation between views and models. For example the code for the mobile watchlist should simply take a model and render it. If we want workflow equivalence, making the code in core that powers are pages more malleable would be where I would start, not CSS/JS.

brion renamed this task from Aim for 1:1 feature equivalence for MediaWiki on desktop and mobile web to Aim for workflow equivalence for MediaWiki on desktop and mobile web.Feb 1 2018, 6:31 PM
brion updated the task description. (Show Details)
brion added a comment.Feb 1 2018, 6:35 PM

@Jdlrobson good point -- I've changed the wording.

In general it should always be possible to do things, even if "hard" things are an extra hop and job.

(A negative example which drives me nuts on GitHub -- I can't add an emoji response to an issue or pull request comment on mobile. I have to switch to Desktop view to do it, even though I can add a text comment on the mobile interface with no difficulty. This to me is an example of a case where it would have been easy to provide the feature on mobile as well; giving me an "out" through desktop mode was better than _nothing_ but only slightly. Putting it in the mobile interface front and center would have been easy for the devs and the users. Putting it in the mobile interface behind a menu would have been also easy for the devs, and at least semi-usable by the users.)

Krinkle added a subscriber: Krinkle.Oct 4 2018, 9:34 PM

Added subtask for T206250 because the way wgCategories is removed in MobileFrontend is unsupported by core and may stop working at any time (only additions are allowed, not removals or modifications), and because the removal of such public API is bound to have caused or will be causing interoperability bugs.

It's a change from over two years ago, but really this kind of disabling of public APIs should not have been done in isolation.