Page MenuHomePhabricator

[SPIKE] Generate approaches for showing edit notices within mobile editing interfaces
Open, Needs TriagePublic

Description

This task involves the work with generating a list of potential approaches to making edit notices available to people who are using mobile editing interfaces (T201595).

Stories

  • As an experienced volunteer who feels responsible for the integrity of a particular page and the content contained within it, I need a way to make people who have taken an action to begin modifying said content on a mobile device aware of information they ought to consider, so that they do not unknowingly subject themselves, or the content they are modifying and/or contributing, to undesirable outcomes.
  • As someone who is seeking to modify or create content using a mobile device, I want to know whether there is information I ought to consider before making the changes I have in mind so that I do not unknowingly subject myself, or the content I am modifying and/or contributing, to undesirable outcomes.

Requirements

Loose

  • Before people begin making a change, they need to, at a minimum, be put in the position to decide whether they will review the edit notices relevant to the content they are seeking to change and/or contribute
  • If/when people elect to view the edit notices relevant to the content they are seeking to change and/or contribute, they need a way to dismiss it so that they can focus on the content they are wanting modify and/or contribute
  • People need a way to revisit the edit notice(s) they dismissed without sacrificing the changes they have already started making

Meta

  • Editing interfaces: MobileFrontend's source and visual modes
  • Platform(s): Mobile
  • Skin(s): Minerva Neue

Approaches

Approach #1: Add User:Alexis Jazz/EditNoticesOnMobile.js to MediaWiki:Minerva.js

  • User experience
  • Considerations
  • Open questions
    • .

Approach #2: present edit notices within a popup that appears after people tap an edit affordance

  • User experience
    • This approach imagines something similar to what is implemented in the Android App (T201597)
  • Considerations
  • Open questions
    • How will people be able to revisit the edit notices if/when they decide to close/dismiss the dialog that contains them? Currently, neither the source or visual mobile editing toolbars have a place to house said edit notices. On desktop, in the visual editors, edit notices are "kept" in the ⚠️ button within the toolbar. On desktop, in the source editor, edit notices cannot be hidden and remain visible above the editing surface.

Open questions

  • How – if at all – should we enable volunteers who create and maintain edit notices to decide whether an edit notice is: A) automatically shown to people upon entering an editing interface or B) only shown to people when they explicitly tap a button/link to reveal/show the edit notice?

Done

  • ===Approaches are documented
  • ===Requirements are documented
  • @ppelberg shares the ===Approaches on en.wiki

Background

  1. Volunteers depend on edit notices to help people who are modifying or creating content avoid making mistakes and causing conflicts.
    • Note: at en.wiki, edit notices also deliver crucial information like discretionary sanctions information which indicate the policies applying to this page are different to other pages (e.g. you can be blocked for more minor conflicts.
  2. Edit notices are not visible to people editing on the mobile site
  3. "2." means there is a growing population of volunteers who miss out on important instructions and information

Event Timeline

How will people be able to revisit the edit notices if/when they decide to close/dismiss the dialog that contains them?

On mobile web we do not currently have multiple toolbars (we did at one point, but as they both had to be at the top of the page to avoid iOS issues we decided we that was too confusing), so the approach that Android use will not work here.

While we have avoided having a toolbar at the bottom of the page, we have learnt with our work on the contexts (e.g. link cards) that we can pin stuff to the bottom of the page if we are careful about the interaction with the keyboard on iOS, i.e. we hide it when the iOS keyboard is up.

Accordingly we could add a bar to the bottom of the page with a button to re-show edit notices.

image.png (682×389 px, 115 KB)
image.png (690×396 px, 99 KB)

To avoid this getting in the way of the editing experience we should:

  • Hide this when the keyboard is shown, to avoid issues on iOS and to preserve space for showing the document while typing
  • Ensure that context items (e.g. link cards) appear on top of this bar (VE only)

I've thought of changing the "editor switch" image.png (57×67 px, 593 B) menu into more general "editor options", and sticking the button to show edit notices again there. The menu could also serve for other features (e.g. T203151).

(This would be in addition to the "Approach #2", a popup when initially opening the editor.)

I've thought of changing the "editor switch" image.png (57×67 px, 593 B) menu into more general "editor options", and sticking the button to show edit notices again there. The menu could also serve for other features (e.g. T203151).

(This would be in addition to the "Approach #2", a popup when initially opening the editor.)

The "editor switch" button isn't included on pages that can't be edited with VE. So you'll need to change the conditions that cause it to be included.

I've thought of changing the "editor switch" image.png (57×67 px, 593 B) menu into more general "editor options"

I think users already find it difficult to switch editors. Hiding the switch options away behind a mystery "options" dropdown would make switching harder (as well as finding the edit notices).

Another option is to just add the icon to the top menu, but I think we are already at the limit how many icons we can fit in there. 8 icons starts to drop below accessibility guidance of touch targets, and looks very cluttered at common device widths (e.g. 375px on iPhone SE):

image.png (221×396 px, 28 KB)

How will people be able to revisit the edit notices if/when they decide to close/dismiss the dialog that contains them?

It's probably worth noting that even if we didn't provide this functionality for now, just showing the notices once as opposed to not at all would be an improvement. I would imagine that after users have dismissed the edit notices they rarely want to refer back to them. Perhaps the Android team have some usage data to confirm this?

Change 812374 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/MobileFrontend@master] WIP Show edit notices

https://gerrit.wikimedia.org/r/812374

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d43d863a02/w/

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d43d863a02/w/

@Esanders is there a particular page on this patchdemo instance that has an edit notice? I ask this wanting to know where to go to try out what you're experimenting with here.

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d43d863a02/w/

@Esanders is there a particular page on this patchdemo instance that has an edit notice? I ask this wanting to know where to go to try out what you're experimenting with here.

Just importing one now (for all pages in the main namespace)

The above WIP patch shows the alert at the correct point in the workflow (after the anon warning has been dismissed), for all section edit links, in a 300px modal (OO.ui.alert) and with CSS stripped. This mimics most of the Android implementation.

Here's how a {{TFA editnotice}} looks:

image.png (688×396 px, 137 KB)

You can test on the above patch demo: https://patchdemo.wmflabs.org/wikis/d43d863a02/w/index.php?title=Douglas_Adams&mobileaction=toggle_view_mobile#/editor/1

The button to re-show the notice, auto-dismissing, or cached dismissing are not addressed yet.

Another option is to just add the icon to the top menu, but I think we are already at the limit how many icons we can fit in there. 8 icons starts to drop below accessibility guidance of touch targets, and looks very cluttered at common device widths (e.g. 375px on iPhone SE):

image.png (221×396 px, 28 KB)

iPhone SE 2nd/3rd gen is 750px wide according to Wikipedia. I know the DPI is higher, but I don't quite get why you simply halve the number of pixels. You wouldn't increase it when I use a 720p 50" plasma TV.. I think, or maybe you would?

It's not a popular opinion, but we really should accept that small displays in portrait mode are just not suitable for typical wiki editing. I'm not saying it's impossible or should be forbidden to edit wikis on phones in portrait mode, but one-size-fits-all just doesn't work here and limitations of the platform should be respected. Sometimes that means saying no. A screwdriver isn't a power drill.

But regardless: link and cite and be combined. Bawl proves that.

And how usable is VE at that size and with limited CPU/memory? I don't edit on a phone (or use VE for that matter..) so I wouldn't actually know, but I can't imagine it to be a good experience.

The above WIP patch shows the alert at the correct point in the workflow (after the anon warning has been dismissed)

I'm still not sure that's actually optimal. Imagine a user reading a page, thinking "you got it all wrong, the earth is flat!", clicks edit, is asked to continue or log in/sign up, decides to sign up, goes through the CAPTCHA that everybody hates, comes back to the page, tries to edit, and NOW is greeted with an edit notice that tells them the earth REALLY is roughly spherical and they just shouldn't bother.

I say tell them straight away.

, for all section edit links, in a 300px modal (OO.ui.alert) and with CSS stripped. This mimics most of the Android implementation.

Ugh, pixels! Why does everybody keep doing that?

Another option is to just add the icon to the top menu, but I think we are already at the limit how many icons we can fit in there. 8 icons starts to drop below accessibility guidance of touch targets, and looks very cluttered at common device widths (e.g. 375px on iPhone SE):

image.png (221×396 px, 28 KB)

iPhone SE 2nd/3rd gen is 750px wide according to Wikipedia. I know the DPI is higher, but I don't quite get why you simply halve the number of pixels. You wouldn't increase it when I use a 720p 50" plasma TV.. I think, or maybe you would?

The browser reports 375px as the width of the viewport. It doesn't really have any relation to the number of physical pixels it can display. See official table from Apple here (somewhat outdated), or an up-to-date unofficial one here. In web browsers this unit is known as the "CSS pixel" and not related to the physical pixels on the device.

It's not a popular opinion, but we really should accept that small displays in portrait mode are just not suitable for typical wiki editing. I'm not saying it's impossible or should be forbidden to edit wikis on phones in portrait mode, but one-size-fits-all just doesn't work here and limitations of the platform should be respected. Sometimes that means saying no. A screwdriver isn't a power drill.

I do not think this is good advice, considering that simplifying for different platforms is the reason why the mobile site is missing the edit notices and various other features.

But regardless: link and cite and be combined. Bawl proves that.

I do not think the communities would appreciate if we made citations more difficult to add.

And how usable is VE at that size and with limited CPU/memory? I don't edit on a phone (or use VE for that matter..) so I wouldn't actually know, but I can't imagine it to be a good experience.

I use an iPhone SE (first edition, 320px width, so even smaller and older than the one @Esanders was talking about), as a personal phone and also for testing the mobile features we work on. The CPU/memory is not a problem, particularly since the visual editor on mobile uses section editing (it may be a problem with other phones). Screen size is an issue, but I've managed to make a couple of edits on it (I usually use the desktop site though).

By the way, editing in landscape mode as you suggested is by far the worse experience, it looks like this:

1E7000DC-4369-42EB-91A2-DFB1B7A2A597.png (640×1 px, 79 KB)

The above WIP patch shows the alert at the correct point in the workflow (after the anon warning has been dismissed)

I'm still not sure that's actually optimal. Imagine a user reading a page, thinking "you got it all wrong, the earth is flat!", clicks edit, is asked to continue or log in/sign up, decides to sign up, goes through the CAPTCHA that everybody hates, comes back to the page, tries to edit, and NOW is greeted with an edit notice that tells them the earth REALLY is roughly spherical and they just shouldn't bother.

I say tell them straight away.

I agree. On desktop we treat the warning about being logged out as just one of the edit notices. I'd like to see the same on mobile. I already hate the current popup and having two different popups before you reach the editor seems not cool at all.

, for all section edit links, in a 300px modal (OO.ui.alert) and with CSS stripped. This mimics most of the Android implementation.

Ugh, pixels! Why does everybody keep doing that?

Well, what else are you going to use? The width of that modal is defined to be 300px (in CSS pixels). You could define it in centimeters if you wanted, but that seems less intuitive, and anyway all other units in CSS are defined in terms of the pixel.

Another option is to just add the icon to the top menu, but I think we are already at the limit how many icons we can fit in there. 8 icons starts to drop below accessibility guidance of touch targets, and looks very cluttered at common device widths (e.g. 375px on iPhone SE):

image.png (221×396 px, 28 KB)

iPhone SE 2nd/3rd gen is 750px wide according to Wikipedia. I know the DPI is higher, but I don't quite get why you simply halve the number of pixels. You wouldn't increase it when I use a 720p 50" plasma TV.. I think, or maybe you would?

The browser reports 375px as the width of the viewport. It doesn't really have any relation to the number of physical pixels it can display. See official table from Apple here (somewhat outdated), or an up-to-date unofficial one here. In web browsers this unit is known as the "CSS pixel" and not related to the physical pixels on the device.

Interesting. :-) "CSS pixel", hadn't heard of that term yet.

It's not a popular opinion, but we really should accept that small displays in portrait mode are just not suitable for typical wiki editing. I'm not saying it's impossible or should be forbidden to edit wikis on phones in portrait mode, but one-size-fits-all just doesn't work here and limitations of the platform should be respected. Sometimes that means saying no. A screwdriver isn't a power drill.

I do not think this is good advice, considering that simplifying for different platforms is the reason why the mobile site is missing the edit notices and various other features.

I think you just didn't go far enough. If a platform is not adequate for editing, don't provide edit functionality for it. (or heavily constrict it, for example, edit requests only) As someone once said: "Make everything as simple as possible, but not simpler".

Again, not saying phones should be banned or anything. But the complexities of editing a wiki can mean that for a new user it's unrealistic to take it all in through such a small viewport.

But regardless: link and cite and be combined. Bawl proves that.

I do not think the communities would appreciate if we made citations more difficult to add.

I don't recall saying that..

And how usable is VE at that size and with limited CPU/memory? I don't edit on a phone (or use VE for that matter..) so I wouldn't actually know, but I can't imagine it to be a good experience.

I use an iPhone SE (first edition, 320px width, so even smaller and older than the one @Esanders was talking about), as a personal phone and also for testing the mobile features we work on. The CPU/memory is not a problem, particularly since the visual editor on mobile uses section editing (it may be a problem with other phones). Screen size is an issue, but I've managed to make a couple of edits on it (I usually use the desktop site though).

By the way, editing in landscape mode as you suggested is by far the worse experience, it looks like this:

1E7000DC-4369-42EB-91A2-DFB1B7A2A597.png (640×1 px, 79 KB)

in practice, maybe, but how come?

If you had three or four lines of text to see it would probably be fine. If your onscreen keyboard in portrait mode was acceptable, the landscape keyboard could be rendered a little smaller. The autosuggest should probably just bugger off. I suck at typing on a touchscreen and just typing is still faster than even considering the generally stupid suggestions. I know some people are addicted to it. I think it makes the way people use language worse. Even when it works well (which is frankly never), autosuggest gets in the way of any form of creative writing. It makes everything bland.

That bar with the blue "done" also takes up more space than needed.

Maybe the wiki toolbar could hide while you're actively pressing keys. (so not necessarily immediately when the keyboard is opened)

The text could be rendered slightly smaller. (if your eyesight is sufficient, but if you're editing on a phone to begin with it kinda has to be)

Some combination of the above would allow you to see multiple lines. Would it still be worse in that case?

, for all section edit links, in a 300px modal (OO.ui.alert) and with CSS stripped. This mimics most of the Android implementation.

Ugh, pixels! Why does everybody keep doing that?

Well, what else are you going to use? The width of that modal is defined to be 300px (in CSS pixels). You could define it in centimeters if you wanted, but that seems less intuitive, and anyway all other units in CSS are defined in terms of the pixel.

I use em for just about everything and % for everything else.

@ppelberg where can I see the open question on whether to include functionality like T312999 ?

FYI: English Wikipedia is getting ready to start enabling the javascript gadget for users as opt-out, in waves (by user groups, anons will be last). If there are any significant blocking items please let us know at https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile#Getting_ready_for_launch as soon as possible.

Notice: enwiki has expanded this gadget to all extendedconfirmed users has wave 2 of 4 of the rollout. Any issues, please report to https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile

Notice: enwiki has expanded this gadget to all extendedconfirmed users has wave 2 of 4 of the rollout. Any issues, please report to https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile

Thank you for the heads up, @Xaosflux .