Talk:Visual-based mobile editing/Ideas/October 2018

Reply here if you have a comment about section editing!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

Just some thoughts that occur to me: If it remembered the scroll position, I wouldn't really want to be restricted to a single section when I start section editing. (Even so, I don't really want a single section to load only, probably.) My preference would be to be able to be reading an article, and switch at a given point to either visual or source editing, and have it keep its position right there. I only really use the section editing links to avoid losing my position when I start editing (e.g. when I notice something that I want to fix), and then scroll from there. Granted, I generally do copyedits and such more than extensive new writing. (I can't really comment on what people who write more would prefer.) I hope this helps. :) Thanks for the great work on the visual editor and new source editor, I enjoy them a lot!

Thanks, currently it is a little odd that section links behave differently in wikitext and VE, however if we implement visual section editing we should anticipate that VE users might be used to getting the whole document when using section edit links.

To open the editor at your current location in the article, you can also use the shortcut key – usually Alt+Shift+V, but it may differ depending on your browser and operating system. You can find it out by hovering over the "Edit" tab with the mouse cursor. (Alt+Shift+E opens the wikitext editor.)

We've been thinking about some ways to make this more accessible (so that you don't have to scroll up to click "Edit", or use section editing), but we don't have any plans/ideas so far.

(As I wrote that, I tested it and discovered using the accesskey actually scrolls to the top of the page on Firefox, but not on other browsers. That's very annoying. I filed this as T208891.)

On many other browsers the shortcut is only Alt+V

Good to know, for when it gets working! That will be handy. Thank you!

I would like to see "Section editing" soon.

They're working on section editing right now. They might have something stable before long.

I think Section Editing would be helpful.

Thanks for your note. The devs are working on section editing, and I *think* that the prototype might be ready to test soon. I'm just waiting for the last person to finish up.

Reply here if you have a comment about Toolbar improvements!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

Is this a floating (and collapsible) toolbar?

No details have been decided. Would you like it to be floating? Would you like it to be collapsible?

Both of them if possible.

I think "Languages" slideshow should be made visible on mobile version. Otherwise, I have to go all the way down and choose the desktop one.

In the source editing, it could be easier to have the links within the document highlighted some way, so that contributors don't have to jump them while editing. Sometimes can be confusing reading all the brackets while editing.

Reply here if you have a comment about the Table of contents!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

I agree that this is quite useful.

Reply here if you have a comment about scrolling!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

yes the idea about the scroll depth is good and viable and will be user friendly even a left right slide from one page to the visual editor will be much helpful.

Reply here if you have a comment about how to Improve copying and pasting!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

I think there is a problem in the application; where I can not copy and paste the text in the app, contrary to what is located in the site!

On mobile, it'd be great to find ways that the interface can provide copy/paste functionality, without the user having to actually perform the traditional copy and paste actions. Because, even something as simple as selecting a block of text to cut or copy can be a serious chore in a mobile editor.

• The handles at either end of the selection are finicky and difficult to position, all too often refusing to stop in exactly the spot we want, or leaping wildly across the screen to accidentally highlight far too much or far too little text.
• If the end of the text we want to select is near the edge of the screen, our fat fingers may not be able to coax the selection handle all the way to the very end of what we're targeting.
• All too often, because of the screen size, we need to make a selection that extends off the top or the bottom of the screen (or at least into the area covered by the on-screen keyboard that insists on being visible during text selection, shrinking the already-small screen even further), and good luck trying to scroll the text without losing whatever part of the selection you've already made.
• If we do finally manage to select exactly the text we want, then we have to hope that the popup menu containing "Copy" or "Cut" has actually come up, and is in the visible area of the screen instead of (again) hiding halfway under the on-screen keyboard.

In short, it's a nightmare. And for Wiki editing, specifically, we should be able to leverage the text parser to do better, by making more intelligent assumptions — at least some of the time.

• If a user taps on, say, a reference, just pop up options to cut or copy that entire reference — they shouldn't have to select anything.

• Ditto for sentences, or paragraphs, perhaps — this would be a good opportunity for user research, to figure out what "unit" of text users most often copy-and-paste.

  Mobile input systems have mostly settled on the single word as the default unit of selection — text-highlighting mode initiates when you long-press on a word, which gets selected, and then you can resize the selection area from there. But, I've never met anyone who bothers using copy-and-paste for a single word — they'll just retype it, because copying text is a big enough pain in the ass that it's not worth the trouble. When we use copy-and-paste, especially on mobile, it's because we want to sling around much more substantial blocks of text.

  I know that, when I use copy/paste during my (dekstop) wiki editing, it almost always takes one of a few basic forms:

  • I copy an entire template transclusion, either because I need to duplicate it elsewhere or I need to create a similar enough transclusion that I'd rather start with an existing template and modify it.
  • I copy an entire reference (possibly including the {{cite}} transclusion inside the <ref>...</ref>s), again either because I need to use it as a template, or because I need to duplicate it in a different article.
  • I copy one or more table rows, then paste them back into the table — once again, to act as a template (in this case, a structural one), replacing the contents of some or all of the copied cells with whatever new data I want to insert into the table.
  • I copy (more likely cut) a sentence, or paragraph, or one or more item(s) in a list, because I'm reorganizing the structure of my writing and feel those paragraphs/sentences/items make more sense if I put them at a different place in the text.

All of these things typically involve click-and-drag (or hold-Shift-and-move-cursor) text highlighting operations, to perform on the desktop... and with a traditional keyboard/mouse input interface, they're fine! But on mobile, we should strive to eliminate manual text selection as much as possible, wherever possible. Because it is bad enough, and disruptive enough to the editing process, that doing it should be considered an absolute last resort.

Reply here if you have a comment about how to Figure out whether you're done!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".

Yes. This will be good for editor. ~~~~

many times during arguments and discussions autocorrect changes a vital word or more, and it's very annoying to notice afterwards others are responding and not understanding your argument. It would be nice to have a feature that can (for those who choose to) disable automaticaly the autocorrect during the edit. melo kol (talk) 15:28, 8 November 2018 (UTC)

Hello, m:Tech/Ambassadors User:NahidSultan, User:MD Abu Siyam, User:Jhalmuri, User:J ansari, User:علاء, User:ArabCom, User:Ladsgroup, and User:IKhitron: Please put this page on your watchlist. Next week, the Editing team hopes to post some ideas that might benefit editors at your home wikis.

Okay.

How can I add it in watchlist?

It works like a normal wiki page. There is a star at the top of the page, next to the history tab. Click the star to add this whole page to your watchlist.

@MD Abu Siyam: You may click on the star button right side of the topic box.

The ideas have been posted! Please read the page and share your opinions. Please ask your communities to read it and share their thoughts, too.

Reply here if you have a comment about Differentiating modes with UI!

It's also okay to start a new topic on this page. Just go to the top of the main page and find the box that says "Start a new topic".