Page MenuHomePhabricator

Editing lede section in VE mobile loads the whole article
Closed, ResolvedPublic

Description

Section editing is enabled in mobile everywhere, so editing the lede section (section=0) should not load the whole page:

https://en.m.wikipedia.org/w/index.php?title=Megan_Rapinoe#/editor/0

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 522509 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/MobileFrontend@master] Pass through section=0 to VE

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

Change 522509 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Pass through section=0 to VE

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

So here are the problems if we don't do this:

  • Our A/B test becomes less meaningful as we are comparing different experiences when the user presses the first edit button (which is probably a large percentage of users, if not a majority)
  • VE is given an unfair disadvantage in this A/B test as the full page takes so many times longer to load.

Concerns if we do this:

  • From testing, users often expect the top edit button to load the full document. Taking the user to an editor that doesn't contain the content they want is very confusing.

Other questions:

  • Are there better ways to get the user to the section they want if they mistakenly think the top edit button will open the whole document?
  • Given the drop off rates when VE is slow to load, can we afford to load the whole document given how slow it can be?

Option C:

  • Enable lede section editing just for users in the AB group. This would allow us to make the AB test "fairer" without changing the experience for other usesrs, however this just defers the problem until the AB test is over.

ACTION:
@ppelberg to decide between: lede/full doc/option C. Should be in time for us to make any necessary changes for the Tuesday change (i.e. end of Monday at the latest)

This statement is a very important call-out from @Esanders:

From testing, users often expect the top edit button to load the full document. Taking the user to an editor that doesn't contain the content they want is very confusing.

Is it impossible to add a section editing button to the lede (option c) while also incorporating an Edit All button that only loads on click in the toolbar?

Is it impossible to add a section editing button to the lede (option c) while also incorporating an Edit All button that only loads on click in the toolbar?

I don't think so. To clarify: "Sections" don't really exist as a thing to be added, but are inferred from the headings. so just making the desktop heading tool accessible on mobile would mean the user could create new sections before or after the current section.

We may also want to consider more guided flows (such as "add section" buttons and the start/end of the current section) or other buttons in read mode, but I don't think that would depend on an "edit all" button.

Of course, there are other use cases for "edit all" and we should consider the best way to provide that feature on T203151: Consider adding a button to let users edit the whole page in MobileFrontend.

Edit: Ignore my comment as I mis-parsed your comment about "add a section editing".

Is it impossible to add a section editing button to the lede (option c) while also incorporating an Edit All button that only loads on click in the toolbar?

To answer the question you actually asked:

I think what you are describing is a possible solution to T203151: Consider adding a button to let users edit the whole page in MobileFrontend, which I think we should address soon.

ACTION:
@ppelberg to decide between: lede/full doc/option C. Should be in time for us to make any necessary changes for the Tuesday change (i.e. end of Monday at the latest)

Decision
I think we should do what this task is proposing: make it so a tap on an article's top-most edit pencil will load just the lede section (section=0) instead of the entire article across all wikis.

Thinking

  • The performance gains we can expect from "all section editing" outweighs the potential UX regression.
  • Full-page article editing on mobile isn't [currently] a great experience, even if it is what the current treatment of the top-most edit pencil suggests is possible.
  • Meta: strategically, we are experimenting with promoting more frequent publishing behavior to protect against contributors losing focus and subsequently, not following through on completing their in-progress edits. See: T219812#5103068

Resulting questions/explorations

ItemDescriptionTask
A.Revise how an article's top-most edit pencil is presented to better communicate that tapping it will open one section of article, not the whole article [2]T228107
B.Consider creating a way for contributors to navigate between article sections, while still in edit mode [3]T228109
C.Consider creating a way for contributors to edit the entire article in mobile VE [4]T219812
D.Investigate what impact moving to "all section editing" within mobile VE has?

  1. UX of full page editing: In our latest round of usertesting for Edit Cards v2, we noticed some test participants seeking better ways of finding specific content within the article. As @Esanders mentions, this could be a consequence of the test's instructions – "Find and edit this specific thing" – it could also be a consequence of too much information being presented on-screen at once creating a need for tools (i.e. in-article search, table of contents) to better locate content within the article.
  2. Presentation of top-most edit pencil: T227897#5333084
  3. Navigate between section: T227897#5329332
  4. Whole article editing: T227897#5333084

After talking with @Esanders, we confirmed this patch will apply to the following:
Wikis: all
Platforms: mobile
Editing interfaces: VE (tapping an article's top-most edit pencil in mobile wikitext already default to editing the lede section of an article)

ppelberg claimed this task.