Topic on VisualEditor/Feedback/Flow

1. Multi-level lists don't seem to work - they simply become 1 line with 3 dots preceding it, even though they show up as 3 bullets lined up diagonally on the visual editor. But they work if I put some text on each bullet point.
2. Feature request: Shouldn't links be formatted correctly (external vs interwiki vs internal) within the editor?
3. Also, when I save the [edit] buttons appear on the section headings... and obviously those don't edit. But I guess that isn't a problem with the visual editor as of now.

Good work, keep coding!

To answer your points in order:

1. Naked multi-level lists (i.e., the same as wikitext with a line starting '*** foo') have to allow you a spot to edit the earlier lists; we leave what we call a 'slug' in the edit interface for a paragraph-that-isn't-there where you can insert the caret. This means the 'view' mode and the 'edit' mode don't look identical, which isn't great, but then users shouldn't really ever use naked multi-level lists in our content (they're hacking in some formatting using semantic tags), so...
2. Yes, this is a good idea, though it might be a bit difficult; thrown it up on our issue-tracker.
3. There's a lot of questions about integration UI and how the edit buttons should appear that we have to think through, and I agree that this is one of those.

Thanks for the vote of confidence, and the ideas. :-)

A follow-up on point 3: I'm assuming "edit section" will be an upcoming feature!

Edit section links "work" currently, in the sense that they take you to that section's place in the overall page's edit view. But when the edit interface is relatively trivial, would we still want section-editing as a distinct concept? Something to consider.

Yes we do. Edit section exists because we don't want to burden ourselves with a 80kB text box. A visual editor containing the parsed version of 80kB source code can only be worse.

+1

A visual editor containing the parsed version of 80kB source code can only be worse.

Why? Remember that the "parsed version of the source code" is essentially the same as "the read tab". Essentially you're saying you're happy for readers to have to wade through a huge amount of text, but not editors. This means (a) we're probably serving our readers poorly, but more obviously (b) we'll be stopping editors from seeing the context of the area that they are editing.

(Playing devil's advocate a little. :-))

You've got a point in that summary style should be occurring if it is going to be difficult to edit in a full page mode; however, readers can also jump around using the TOC. When you are editing, I assume that you won't be able to. Section editing also helps reduce edit conflicts.

Reading the 80kb of (static) parsed code is different from having a script to interact with that same amount of code.

And for the purpose of editing a section, the VE could just keep the other sections intact, to provide you some context, but still parse/interact only with that only section (and in case you change your mind and also want to edit more section after that, it could edit the whole page - or a group of sections, if that was possible).

+1. An editable box consumes many many times the amount of client hardware power compared to a read-only page with the same amount of pretty content in it.

I think this is because "insert" and "input hardware interaction" consume lots of processing power; but I'm not a developer for this project so I'll let them speak.

"And for the purpose of editing a section, the VE could just keep the other sections intact, to provide you some context, but still parse/interact only with that only section (and in case you change your mind and also want to edit more section after that, it could edit the whole page - or a group of sections, if that was possible)."

Please! This would be a great feature.

“(b) we'll be stopping editors from seeing the context of the area that they are editing”

No. Section editing is a wanted feature. But we'll not remove the full article editing feature.

Also current editsection behavior is an important measure to prevent edit conflicts. So if that disappears, we probably need to find an alternative way to work around the editconflict problem.

Well, first of all, finding a way to solve the edit-conflicting problem is a core part of our work on the VisualEditor, worry not. However, editing of sections actually isn't involved in preventing edit conflicts, and as I understand it, it hasn't been since we switched to diff3 in 2005. It's fascinating how folk-knowledge persists, though. :-)

James, that's because so far editing sections in isolation is the only surefire way of letting two people edit a page simultaneously without triggering an edit conflict.

“editing of sections actually isn't involved in preventing edit conflicts”

Of course it is.

While I am editing the section A of an article, someone else can edit section B and no edit conflict. If I edit the whole page and change only the section A in it, when I click Publish I am publishing the new section A and the old section B. If the other person has edited section B in the same time, edit conflict ! Which is particularly annoying. So, to avoid that, the future of Wikipedia is being able to choose edit scopes as atomic as possible.