Page MenuHomePhabricator

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

Assigned To
None
Authored By
brion
Feb 15 2017, 1:33 PM
Referenced Files
None
Tokens
"Love" token, awarded by CKoerner_WMF."Orange Medal" token, awarded by Krinkle."Love" token, awarded by SamanthaNguyen.

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.
StatusSubtypeAssignedTask
OpenNone
OpenNone
DuplicateNone
DeclinedNone
DeclinedNone
ResolvedJdlrobson
DuplicateNone
DeclinedNone
OpenNone
DeclinedNone
DeclinedNone
OpenNone
OpenNone
DeclinedNone
OpenJdlrobson
OpenNone
OpenNone
Resolvedovasileva
ResolvedNone
OpenNone
ResolvedJdlrobson
OpenFeatureNone
DeclinedNone
Resolved brion
ResolvedTheDJ
OpenNone
OpenNone
DuplicateNone
OpenNone
DeclinedNone
ResolvedJdlrobson
DuplicateNone
DuplicateNone
OpenNone
OpenNone
ResolvedNemo_bis
ResolvedMaryana
Resolvedovasileva
InvalidNone
ResolvedJdlrobson
DuplicateNone
OpenNone
OpenFeatureNone
ResolvedJdlrobson
DuplicateNone
ResolvedJdlrobson
DeclinedNone
DuplicateNone
DuplicateNone
DuplicateNone
Resolved ppelberg
ResolvedJdlrobson
ResolvedJdlrobson
Resolvedovasileva
OpenFeatureNone
OpenFeatureNone
Resolvedmatmarex
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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)

@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.)

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.