Page MenuHomePhabricator

Editor should flag mobile editing warnings
Open, HighPublic

Description

In mobile/desktop mode, when previewing or saving an edit, we have the opportunity to flag problems to the user. For example when editing pages in the Schema namespace errors are shown in both mobile and desktop that prevent saving:


I'm assuming that it should be possible to "warn" against certain problems and surface these warnings in previews and upon saving (with an override button").

In mobile, for every view, we run the MobileFormatter, which takes a DOM tree for the page and walks it, making modifications to improve mobile friendlyness.

I believe that if we combine these 2 things, we could flag mobile issues to editors at time of editing to let them know that the content they are producing is not suitable/optimal for mobile devices.

Strawman proposal

The IMobileTransform class would have a method doesApply that takes a DOMElement and returns a boolean expressing whether the transform applies

On every edit we would run MobileFormatter::checkContent( htmlstring ) where htmlstring corresponds to the parsed wikitext that is about to be saved.

This method would run certain MobileFormatter transforms with the purpose to identify issues with wiki content.

To start with we'll focus on the LegacyMainPageTransform which will only run on edits to the main page to facilitate implementation of T32405. This will also allow us to measure the impact of doing this on every edit.

When previewing an edit for the main page, if the legacy main page transform, is needed it will render an error like so:


A link will be provided to read more.

If this proves successful we can expand this for other purposes (see below).

Thank you for @TheDJ for the poke which reminded me to make this task.

Possible transforms

  • When an infobox appears before a lead paragraph we can guide editors to reposition it
  • When page issues are not using the "fix" parameter, report a problem e.g. T197047,T197049,T197048
  • When page issues are using long issues and truncation we are doing in T197931 is likely to impact readability - flag that to the editor.
  • When multiple page issues are present on a page and are not wrapped in a "multipleissues" template, we can instruct editors to fix this

*When certain inline styles are used e.g. width or float that are known to cause problems in mobile we can flag them

  • When certain elements are larger than the available viewport (e.g. T160946) we could flag this to editors, rather than rely on ad-hoc app reports (note this issue is extremely common)
  • One we have a framework in place we can add various other use cases from https://phabricator.wikimedia.org/project/view/1682/

Possible iterations on this idea

  1. When an article has issues that an editor doesn't fix we could store that information as a page property to allow editors to discover problematic articles and fix them.
  2. If a page has a problem, the mobile site could render an automatically generated page issue "This page may not be mobile friendly".

Downsides

  • This will increase the time it takes to preview an edit. If this proves to be problematic, this could be run at request of an editor e.g. not on every edit, but via a specific button in the editor or be opt-in via Special:Preferences.

We could also run the test as part of the existing render, storing the result as a page property. The warning would then become "This page was recently reported to have a mobile issue" rather than "This page has a mobile issue".

  • Note: the transform would run for all transcluded templates so in some cases it might not be clear where in the page the problem is. For instance, the Barack Obama article may report an error for a Template that it uses rather than an issue with the article itself
  • Some changes may be too technical for some users. We thus might want to limit certain messages to users with the TemplateEditor user group or use an opt in user preference.
  • Certain issues are so common (e.g. Template:Navbox not being mobile friendly) it doesn't make sense to render the issue on every edit. We'll need a way to limit issues to constructive and actionable use cases or to scope those problems to the template itself.

Event Timeline

Jdlrobson triaged this task as High priority.Aug 1 2018, 8:31 AM
Jdlrobson created this task.
Jdlrobson updated the task description. (Show Details)Aug 1 2018, 8:35 AM
Jdlrobson added subscribers: Esanders, matmarex.

@TheDJ @Esanders @matmarex I don't know much about how editor warnings/errors work, but is something like this viable?

Jdlrobson updated the task description. (Show Details)Aug 1 2018, 8:56 AM
Jdlrobson added projects: Proposal, TechCom.

Given the impact this would have on the editing workflow (previews) I'd also be interested in some recommendations from TechComm on

  • whether this sounds like a good idea
  • how to store/test for mobile issues without causing a performance nightmare
  • how to best target appropriate users (e.g. opt in preference or using user rights group)
TheDJ added a comment.EditedAug 1 2018, 9:50 AM

I'd say doing this solely for Main page is relatively easy and non-disruptive. Doing it for all pages is much harder (both due to audience and performance concerns), and should probably go into Special:LintErrors or a linting module for CodeMirror. Having two solutions for two different use cases might also be a valid solution.

RHo added a subscriber: RHo.Aug 1 2018, 6:58 PM
Krinkle edited projects, added TechCom-RFC; removed TechCom.
daniel moved this task from Inbox to Backlog on the TechCom-RFC board.Aug 1 2018, 8:28 PM
matmarex added a subscriber: Legoktm.EditedAug 1 2018, 8:41 PM

I only skim-read your proposal, but it sounds viable, other extensions implement similar mechanisms (e.g. AbuseFilter). I haven't made up my mind yet on whether it's a good idea.

I think @TheDJ is making a good point about using the Linter extension to display these warnings on Special:LintErrors instead. @Legoktm would be the person to ask if that is viable.

One problem I see with making it a warning on save/preview would be that someone making a typo fix to a page that has a mobile-related problem will get the seemingly irrelevant warning. You'd have to also check the version before their edit and filter out already existing problems, and then there is no way to discovere them in existing pages.

Tgr added a subscriber: Tgr.Aug 6 2018, 8:14 AM

I don't think this is viable as an edit warning if it cannot differentiate between problems in the wikitext of the current page and problems in templates (which is probably not possible with the PHP parser). Most articles are just text and the problems will come from the infobox, navbox etc. templates they include, so there will be lots of non-actionable warnings confusing editors. The Linter approach seems more feasible.

daniel added a subscriber: daniel.Aug 8 2018, 7:23 PM

This seems to mainly be a question of product behavior and UX design. I'm trying to understand what the technical challenge is here. If I understand correctly, the desired functionality is similar to that of AbuseFilter or ConfirmEdit: check some propererties of an edit before that edit happens, and provide feedback to the user if the edit doesn't look good. Do I understand that correctly?

If so, there are several hooks that can be used for that purpose. There is also a mechanism for getting the rendered output (including all the meta-info about links, templates, etc) in such a hook handler (namely, WikiPage::prepareContentForEdit), but it's admittedly arcane. I hope to replace it with something saner soon, as a by-product of T198075: RFC: factoring page update logic out of WikiPage.

Is there, on the technical side, anything needed beyond that?

I'm trying to understand what the technical challenge is here

As I understand it, most editor warnings relate to wikitext NOT HTML and especially not mobile formatted HTML.
They also only happen at time of edit. Given concerns around non-actionable warnings for editors it seems like it would be useful to store these issues for discoverability e.g. via a page Special:MobileIssues
I'll sync up with @Legoktm about the linter approach as that provides another way of doing this.

Is there, on the technical side, anything needed beyond that?

I've captured my questions here https://phabricator.wikimedia.org/T200880#4468311

daniel added a comment.EditedAug 8 2018, 9:41 PM

As I understand it, most editor warnings relate to wikitext NOT HTML and especially not mobile formatted HTML.

Lots of things, like AbuseFilter and ConfirmEdit, use the rendered output - usually not the actual HTML, but the links extracted during parse, but that doesn't matter, they could just as well use the HTML, they have a ParserOutput object. You are however correct that getting the mobile HTML in that context would be harder.

They also only happen at time of edit.

ParserOutput can store arbitrary extra data, and hooks can easily be used to output them later as desired. That's actually trivial.

daniel added a comment.EditedAug 8 2018, 9:43 PM

As I understand it, most editor warnings relate to wikitext NOT HTML and especially not mobile formatted HTML.

Lots of things, like AbuseFilter and ConfirmEdit, use the rendered output - usually not the actual HTML, but the links extracted during parse, but it doesn't matter, they could just as well use the HTML. You are however correct that getting the mobile HTML in that context would be harder.

They also only happen at time of edit.

ParserOutput can store arbitrary extra data, and hooks can easily be used to output them later as desired. That's actually trivial.

I've captured my questions here https://phabricator.wikimedia.org/T200880#4468311

These are not technical questions in the scope of TechCom, though.

In my mind, the remaining issue is how do apply the validations you want, based on mobile format HTML, without generating that twice.

Looping in @Deskana and @iamjessklein.

Helping editors author pages such that they will display nicely on mobile (or wherever they are displayed) is something that comes up fairly frequently on our team. @Jdlrobson created this page which might be interesting to y'all: https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles. Ideally these kinds of recommendations would be presented inline while you're editing. This seems like an area we could collaborate on.

Thanks for looping us in @alexhollender - we are in the process of improving the visual editing mobile experience and this page that @Jdlrobson made is very insightful. We are still at the point where we are identifying what part of the experience to tackle first, but if you are interested you can read our progress here: T201547

stjn added a subscriber: stjn.EditedSep 25 2018, 5:09 PM

This, sadly, will prove more annoying for editors than useful if we’d try to implement this on a large scale, in my opinion. Especially if the thing that MobileFrontend has concerns with is in some protected template − how a user is expected to go around this if they don’t want to see the warning in the article they’ve written with it?

I kind of think that displaying a notice at main page editing for every wiki from that .dblist is more enough to solve the current problem, and future problems won’t be solved exactly by this measure since most editors are not technically proficient and won’t know what to do even if you give them a link. LintErrors is probably the wisest solution for this. (That’s pushing aside the fact that some of suggested transforms are controversial.)

Yup, I don't think it makes sense to show to all editors, but it may be useful to show to editors with the TemplateEditor right. A linting tool does seems like a good first step.

Jdlrobson moved this task from Backlog to Tracking on the MobileFrontend board.Oct 18 2018, 7:00 PM