Talk:VisualEditor on mobile/Section editing

Jump to navigation Jump to search

About this board

Section Editing – the feature – is intended to improve editors' experience editing with the visual editor on mobile. But, does it? This is a question this test is intended to help answer.

With the above in mind, what did you think of the prototype? In what ways does Section Editing function how you expected it to? In what ways does Section Editing not function how you expected it to? How do your past editing experiences with the visual editor on mobile compare to your editing experience with the prototypes?

The questions above are intended as starters. So please, do not feel limited – we value any comments, feedback or questions you feel relevant to share.

Feedback here will be summarized on the main project page.

It worked but VE took double the time to load

6
213.57.79.144 (talkcontribs)

Both worked well for me with no preference either way. I did however compare to wikitext editing and it loaded in half the time.

Whatamidoing (WMF) (talkcontribs)

Thanks!

PPelberg (WMF) (talkcontribs)

Thank you for giving the prototype a try ^ _ ^


That's reassuring to hear about the loading times you encountered. Out of curiosity, in the times you've used visual editor on mobile in the past, how often do you remember feeling like you were "waiting" for the editing interface?

Neil P. Quinn-WMF (talkcontribs)

@PPelberg (WMF), check the title—VE's loading time was worse, not better :)

PPelberg (WMF) (talkcontribs)

Oh, no – I'm a bit unclear...@Neil P. Quinn-WMF, what do you think is meant by this, "I did however compare to wikitext editing and it loaded in half the time." here?


I interpreted "it" in the second sentence of the post's body as referring to section editing given the thread's title, but perhaps "it" is actually a reference wikitext in which case, yes, I am mistaken...


PPelberg (WMF) (talkcontribs)

213.57.79.144 if you're out there, somewhere, please know your help is needed 🔭

Reply to "It worked but VE took double the time to load"

Can't to switch from wikitext section mode to visual editor section

5
197.235.77.159 (talkcontribs)

Issue: Unable to switch from wikitext section to visual editor section

Steps to reproduce 1. Edit section using wikitext editor 2. Click the dropdown to switch to visual editor

Expected Loads just a section in VE

Actual Loads the whole article in visual editor.

197.235.77.159 (talkcontribs)

Note, this only happens after toggling the desktop mode, when clicked on the footer. So this might not be a 100% relevant to mobile devices.

Whatamidoing (WMF) (talkcontribs)

A lot of established editors use the desktop system on their mobile devices, so it's possible that this will happen more than it might be expected.

JKlein (WMF) (talkcontribs)

I'm having trouble reproducing this issue because when I try to switch modes, I get the prompt to save. This is documented in phabricator.

Whatamidoing (WMF) (talkcontribs)

197.235, if you see this, could you tell us what your web browser and OS is? For example, Safari on iOS or Chrome on Windows 10.

Reply to "Can't to switch from wikitext section mode to visual editor section"

Feedback

2
Summary by JKlein (WMF)

Extra white space is a known issue being tracked.


CMadeo (WMF) (talkcontribs)
  • Version A, Version B: which experience did you prefer? Why?
    • I preferred Version B, although the load time was a bit slower than I had expected. That being said the loading indicator was significantly clearer in Version B then on Version A.
    • I liked being able to focus on the section. When loading Version A I was initially brought to the Wikitext editor and then my place was lost when I switched to VE.
    • One negative with Version B was the extra empty space at the bottom of the section, it made it harder for me to gauge by looking at the scroll indicator how much text was included in the editing view (eg. would it be one section or all of the sections below the selected section).
    • I also found the two step process (check and then publish) for publishing my edit to be a bit confusing and cumbersome.
  • What device and browser did you use to test Versions A and B?
    • iPhone X running iOS 12.1.2
    • Chrome app
  • How familiar are you with the visual editor?
    • Familiar
  • How frequently do you use the visual editor on a mobile device?
    • Never (Sorry, I always edit in the app!)
JKlein (WMF) (talkcontribs)
Reply to "Feedback"
AHollender (WMF) (talkcontribs)

Cool stuff.

General note: perhaps this was done intentionally, but I wasn't able to find any instructions regarding which parts of the prototypes to focus on/compare when giving feedback. I think it would be useful to get a bit of guidance regarding what is different about Version A and B, and perhaps even a sense of what decision you all are trying to make, i.e. why you're testing these two versions.

  • Version A, Version B: which experience did you prefer? Why?
    • I preferred version B, because with version A when I tapped the edit icon I saw the top of the article while the editor loaded (screenshot), which seemed more jarring/confusing than version B where the section I was on remains on-screen the entire time (screenshot).
  • What device and browser did you use to test Versions A and B?
    • Samsung Galaxy, Chrome
  • How familiar are you with the visual editor?
    • Familiar – I use it occasionally to make edits
  • How frequently do you use the visual editor on a mobile device?
    • Less often than a monthly basis
JKlein (WMF) (talkcontribs)

Thanks for the feedback @AHollender (WMF) - we were trying to leave the questions and test open-ended, but will keep this in mind for future tests.

Reply to "Non-editor feedback"
100.12.66.238 (talkcontribs)
  • Version A, Version B: which experience did you prefer? Why?
  • What device and browser did you use to test Versions A and B?
  • How familiar are you with the visual editor?
    • Not at all – I never use it
    • Familiar – I use it occasionally to make edits
    • Very familiar – I could teach someone how to edit
  • How frequently do you use the visual editor on a mobile device?
    • On a daily basis
    • On a weekly basis
    • On a monthly basis
    • Less often than a monthly basis
    • Never
100.12.66.238 (talkcontribs)

Sorry, I hit ctrl-enter and didn't realize it was going to post

  • Version A, Version B: which experience did you prefer? Why? Version B took significantly longer to open, and I didn't notice a significant difference in usage from a casual use. Version B also had a functioning "remove format" button where version A's did nothing.
  • What device and browser did you use to test Versions A and B? Android 9 Chrome browser, Google Pixel 1
  • How familiar are you with the visual editor?
    • Not at all – I never use it
  • How frequently do you use the visual editor on a mobile device?
    • Never
Reply to "Non-editor feedback"

Lose edits if idle on page

2
Summary by JTanner (WMF)
98.218.225.109 (talkcontribs)

Steps to reproduce:

  1. On iOS open http://visualeditor-test.wmflabs.org/w/index.php?title=Pride_and_Prejudice&mobileaction=toggle_view_mobile from GChat.
  2. Allow phone to enter sleep mode and return to lock screen
  3. Unlock phone and return to page where you were editing


Expected:

The page would still be there and editable.


Notes: The black loading screen appeared and it shut out of Mobile Web and returned to the GChat app. The phone may not have been able to handle the testing server, it may just be too much for it. However, from a user perspective this could be discouraging. Not sure what can do about it.

Whatamidoing (WMF) (talkcontribs)

I don't know what we can do about it in the end (beyond "recover your edit", which would be handy there when it works). You're right, and there are all kinds of ways for that to happen: in addition to the case of the phone going to sleep while you're reading, you could lose your work because your battery dies, or the browser might drops everything in the editing window if it needs all the memory to open a large webpage. I'm sure you could think of more scenarios than I can right now. It is a worrying thing.

Do you happen to know whether Android behaves the same way?

Reply to "Lose edits if idle on page"

When closing a section, page doesn't go back to read mode

1
Summary last edited by ESanders (WMF) 19:45, 26 February 2019 2 months ago
197.235.245.211 (talkcontribs)

Page not scrolling back to edited section once saved

2
Summary by ESanders (WMF)
197.235.77.159 (talkcontribs)

Steps to reproduce 1. Click pencil to edit section 2. Make edit 3. Save page

Expected

Page scrolls back to section.


Actual

Page shown on top.


It seems reasonable that the user would like to see the saved section. Currently they'll need to scroll or try browser find.

Possible solution:

  • Scroll to edited section.
  • Show note on top with link to allow user to jump to section.
Iamjessklein (talkcontribs)

Thanks! This an absolutely reasonable expectation.

197.235.77.159 (talkcontribs)

It seems like a promising design and works well enough to deploy it. Here's some feedback:

The good

  • Section editing is pretty intuitive
  • It seems to be slightly more performant than loading the whole article
  • It makes it easy to make quick fixes

The bad

  • It seems to consume as much bandwidth as the loading of the full article.
  • Harder to see all other references, so the user is forced to "try" to insert a new reference to see references defined elsewhere in the document. This should be a quick interface to give context while editing.
  • Categories not shown, in edit or in preview. A section edit can result in categories or tracking categories being added by templates, extension tags, or parser functions.

The ugly

  • Too many pencil icons. It simply looks ridiculous even on the desktop to have so many edit links, aside from just wasting bandwidth with unnecessary overlinking. Real estate on mobile devices is limited, so this makes things worse.
  • Page title is cramped on the toolbar, and can't ever be properly visible for smaller devices. The browser url field contains more text but still makes this more visible.
ESanders (WMF) (talkcontribs)

Many thanks for you feedback, it will be shared with the team.

Here's some additional context around the issues you have raised, which may be of interest:

It seems to consume as much bandwidth as the loading of the full article.

That is correct. We have evaluated the possibility of only requesting the required HTML, and may yet pursue that apporach in the future but for now we went with a client-side approach for a number of technical reasons. There are still many performance benefits to be had with this client-side approach as you observed.

Harder to see all other references

This is true, although will be somewhat unavoidable with any section editing solution, especially on pages with very long reference lists

Categories not shown

Categories are currently not shown in any of the mobile interfaces. If this changes we can reconsider if/how we want to support them in mobile section editing.

Too many pencil icons.... aside from just wasting bandwidth

The bandwidth overhead is pretty low, each icon is only a few bytes.

Real estate on mobile devices is limited, so this makes things worse.

In most cases the pencils occupy space that would otherwise be blank.

In general, the length of a section is not part of the parser output so we currently can't decide to render section edit links based on section length.

197.235.77.159 (talkcontribs)

This is true, although will be somewhat unavoidable with any section editing solution, especially on pages with very long reference lists.

To be clear, the idea here is to simply take pictured "re-use references dialog", and make it possible to show it separately outside the dialog. For example, it could be triggered by a small icon at the bottom of the page, or it could be swiped from the left or right in its own pseudo-toolbar. The idea could even be extended to contain collections of items on the page, references, categories, interwikis, et al.

Categories are currently not shown in any of the mobile interfaces. If this changes we can reconsider if/how we want to support them in mobile section editing.

That's true. Generally speaking, using categories for tracking errors has always been a bad approach, although it is better than nothing. For example, consider adding an empty <ref></ref> reference. It currently triggers no error at all. Perhaps, at a minimum it would be a good idea to have error reporting similar to the desktop interface.

As for the extra pencils, it might be more sensible to only show the icons in the view area, maybe just the ones in the middle. The user will quickly learn to scroll up or down to click the others.

Alternatively, doing away with all icons except for the first one, and requiring a double tapping or triple tapping to edit an section would be more sensible than excessive icons or links. That could easily be a tip taught to the user when they click the edit icon for the first time. Anyway, that's a considerable change that might be a separate project.

Reply to "The good, the bad, and the ugly"
Julle (talkcontribs)

Coming from desktop editing, this was more in line with expected behaviour of editing a section and helpful in the same way as it is on desktop: easier to focus on the particular part I wanted to change.

(I still find it somewhat confusing that I have to click on the check mark, then click save, then write my edit summary and click again to publish the change. To me, that seems like at least one step too many. But that has less to do with section editing.)

JKlein (WMF) (talkcontribs)

Thanks @Julle - We have the multi-step save to publish process earmarked for design review, but I appreciate that you are confirming that's it is confusing.

Reply to "Feedback"