Last modified: 2014-10-23 10:12:45 UTC
I don't seem to be able to section edit with VisualEditor.
Thoughts: It strikes me that this might not be overly difficult - if VE is just using H<n> elements to represent sections anyway, then it should be relatively simple to change the edit URL to "javascript:", and add some JavaScript events to them that call the VE setup and, once it's done, brings the specified section to the top of the user's screen. I won't mark this as easy, because I don't think it is. I wish we had an "intermediate" keyword.
(In reply to comment #0) > I don't seem to be able to section edit with VisualEditor. There are three issues here: * To edit a section, we would need to get its HTML from Parsoid - but a section isn't guaranteed to be balanced HTML, for example (commonly-used): {| ! Foo !! Bar |- === Section 1 === |- | Foo || bar === Section 2 === |- | Foo || bar |} Coming up with a solution to this is would be a significant piece of engineering effort for marginal utility. * The reasons we brought in section-editing originally were two-fold - to skip past confusing wikitext in other areas to find the item you actually wanted to edit (not an issue in the context of VisualEditor), and to avoid edit conflicts using the page-based diffs at the time (not an issue for ~ 7 years since Tim re-wrote the diff tool). * Editing by section blocks users from editing other areas at the same time that the notice flaws in after they've entered editing, for very limited added-value. The behaviour in VisualEditor when running as the default editor is for the edit section links to take you into VE for the entire page, with the view moved down to the anchor of that section (note, this is not how it appears right now on the various Wikipedias, but will be once they have the 'beta' enabled). I'm not convinced that this is a WONTFIX, but I'm similarly not convinced that we should spend our time fixing this rather than, say, making VisualEditor and Parsoid work on Wikisource, or other things we could be doing with our limited resources.
There must be a recognition that editing large articles is burdensome and that section editing has (had) _enormous_ value. Even with JavaScript disabled, the parser continues to take a significant amount of time to parse a large article. And while modern browsers on modern hardware don't have as many issues, rendering large articles can also be taxing. VisualEditor adds to this burden by piling on a lot of JavaScript. The idea that wanting to edit only a section of [[GE]] or [[Iraq War]] stems from wanting to skip past confusing wikitext or avoid edit conflicts misses the point, I think. Though I realize that VisualEditor uproots many principles of the current editing workflow/paradigm. Krinkle briefly mentioned an idea where section edit links might load the full VisualEditor form and then jump down to the specific section. This might be an approach to consider.
(In reply to comment #3) > Krinkle briefly mentioned an idea where section edit links might load the > full VisualEditor form and then jump down to the specific section. This might > be an approach to consider. I mentioned it too, you know :-) - see: (In reply to comment #2) | The behaviour in VisualEditor when running as the default editor is for the | edit section links to take you into VE for the entire page, with the view | moved down to the anchor of that section (note, this is not how it appears | right now on the various Wikipedias, but will be once they have the 'beta' | enabled).
(In reply to comment #4) > I mentioned it too, you know :-) - see: > > (In reply to comment #2) > | The behaviour in VisualEditor when running as the default editor is for the > | edit section links to take you into VE for the entire page, with the view > | moved down to the anchor of that section (note, this is not how it appears > | right now on the various Wikipedias, but will be once they have the 'beta' > | enabled). Err, whoops. Sorry, yeah, completely missed that paragraph. If the default editor behavior is a switch that controls parts of the interface like this (I didn't realize that), is this testable now anywhere? A Labs wiki or something?
(In reply to comment #5) > Err, whoops. Sorry, yeah, completely missed that paragraph. :-) > If the default editor behavior is a switch that controls parts of the > interface like this (I didn't realize that), is this testable now anywhere? > A Labs wiki or something? No; we should do that. One of the things I'm pondering is if we should relabel the edit section links to have two links, one to VE and the other to wikitext. Possibly "[_edit_ _*_]" or somesuch.
(In reply to comment #6) > One of the things I'm pondering is if we should relabel the edit section > links to have two links, one to VE and the other to wikitext. Possibly "[_edit_ > _*_]" or somesuch. I think that might be too much clutter when VE rolls out to everyone. But while it's opt-in, it will definitely encourage me to test it, since I use the edit section link a lot.
See discussion here: [[Wikipedia:VisualEditor/Feedback]] and go to the section titled "VisualEditor not enabled for section editing". That talk section will end up in the archives eventually. Do an archive search then. Load time will still be an important factor with VisualEditor. That reason alone justifies continuing with section editing. If VisualEditor is enabled for section editing, then it will also be necessary to enable "edit source" somehow for sections too. So people can choose between the two. Just like at the top of page. If the developers are worried about cluttering up each section with both "edit" and "edit source" links, then there needs to be some icon next to "edit" that will be the link for "edit source". The clickable icon will have a popup tooltip saying "edit source". I use section editing for almost all my editing, whether in short or long articles. Do you have section editing enabled? If not, you might try it. It speeds up editing immensely for me, and many others. See: [[Special:Preferences#mw-prefsection-editing]] and "Enable section editing via [edit] links". It would be better if it were enabled by default for all editors, whether logged in, or not. Many people will still use wikitext source editing. There will long be a need until every single bug is fixed in VisualEditor. I can tell you this from years of experience with the Wikia visual editor. Many, if not most, regular editors on Wikia avoid it due to its continuing bugginess. When using source editing I don't know why anybody would want to wade through paragraphs of irrelevant stuff to get to the paragraph and section one is interested in editing. Especially if you make multiple edits, and use multiple previews. Why wait long periods of time for full-page previews? A section preview is much faster. I have been editing Wikipedia since 2005, and at one point I had forgotten that section editing is not a given for all editors. We are wasting a lot of editors time by not enabling it by default. Since there are fewer and fewer editors we need to make their editing more and more efficient. Anonymous editors do much of the editing on Wikipedia, and many will prefer to edit the source wikitext for all the reasons previously discussed. Many anonymous editors are experienced Wikipedia editors, and will not tolerate having to only use VisualEditor. So never get rid of the option for source editing. Let me repeat: WIKIA, WIKIA, WIKIA. Bugs are seemingly never-ending and ever-growing with visual editors.
(In reply to comment #8)A section > preview is much faster. I have been editing Wikipedia since 2005, and at one > point I had forgotten that section editing is not a given for all editors. We > are wasting a lot of editors time by not enabling it by default. Wikitext section editing is enabled by default.
OK. I see that section editing is currently enabled for anonymous users too on Wikipedia. I am almost always logged in, and so I must have been confused by the preference "Enable section editing via [edit] links". I see now that it is about the URLs. See [[Help:Section#Section_editing]]. I would hate to lose section editing of source wikitext if VisualEditor is enabled for section editing. That would be a serious step backwards for the reasons I and others have discussed.
(In reply to comment #10) > OK. I see that section editing is currently enabled for anonymous users too > on Wikipedia. I am almost always logged in, and so I must have been confused by > the preference "Enable section editing via [edit] links". That is in fact the preference, but it's checked by default (as well as always on for anons).
OK. Now that I finally get it, and see that everyone (logged in or not) currently gets source editing of sections, let us not remove section editing of source wikitext when VisualEditor is fully implemented! That would make many editors very unhappy. I sometimes like to open up a section in a new tab for editing. So I can switch between tabs to alternate between how the section currently looks, and how my preview looks. This also helps me in finding stuff in the wikitext. I can use browser find in both tabs to help me find where I need to edit. This can be very necessary when editing references, tables, navigation boxes, image captions, and other such wikitext. Images that are right-floating, for example, can be difficult to find in the wikitext otherwise.
(In reply to comment #12) > OK. Now that I finally get it, and see that everyone (logged in or not) > currently gets source editing of sections, let us not remove section editing > of source wikitext when VisualEditor is fully implemented! That would make many > editors very unhappy. Just to update on this point: as of today, we have switched over to the 'beta' behaviour for VisualEditor in a number of regards, including section edit links - i.e., default behaviour for users with VisualEditor (which will soon be all users) is that section edit links will take you into VisualEditor, scrolled to that section, with the cursor at the start of it. For the mean time (until VisualEditor is out of beta, when it will be much less likely that users will want to use wikitext editor often), there's a user preference (defaulted to off) that will redirect these section edit links back to the wikitext editor; this is in Special:Preferences > Editing > Beta features. I'm open to seeing if there's a way of giving people two section edit links without being confusing in the medium/long term, but that's a discussion for later. :-)
Many registered editors don't edit enough to know much about preferences. This is a bad idea. There are already many complaints here: [[Wikipedia:VisualEditor/Feedback]] This could cause many editors, who already do not edit much, to edit less because their edits get reverted soon after using Visual Editor. VE messes up many things. I have seen it myself, and so I do not use VE. I have to check a WHOLE-PAGE preview diff for errors it inserts before I save some other minor thing I edited. Minor typos and other things that used to take me a few seconds to fix now take a long time with the Visual Editor. Visual Editor needs to edit SECTIONS, too. Not the whole page. So this fix is not a fix. Visual Editor still does not support section editing. It still only edits the whole page. Worst of all, what was once an interesting option has now become an imposed encumbrance. There is no way to edit in source mode now without effort. Registered editors are forced to use VE. They can only opt-out of VE section editing. They must go here: [[Special:Preferences#mw-prefsection-editing]] Please return section editing of source wikitext as the default. Make this VE section editing gimmick the option in preferences. Make it opt-in, not opt-out. The WMF does not have anywhere near a consensus or approval or any other type of community process sanction that justifies imposing beta VE. Especially when it is as buggy and beta as it is now. VE was actually an interesting option until this latest forced imposition of beta VE.
(In reply to comment #14) > Many registered editors don't edit enough to know much about preferences. > ... Editors who haven't changed their preferences are still using the wikitext editor. > Worst of all, what was once an interesting option has now become an imposed > encumbrance. There is no way to edit in source mode now without effort. > Registered editors are forced to use VE. They can only opt-out of VE section > editing. They must go here: > [[Special:Preferences#mw-prefsection-editing]] > > Please return section editing of source wikitext as the default. Make this VE > section editing gimmick the option in preferences. Make it opt-in, not > opt-out. It is opt-in. So far, the defaults have not changed in any way. You can sign up for a temporary test account and see for yourself. If you don't change any preferences, editing remains wikitext only. And you can change back (and forth) at any time. That means the defaults are not being imposed on anyone. I understand your point. VisualEditor is a work in progress. However, it's a work in progress that's currently 100% opt-in, and James has already said he will consider two section edit links.
Matthew. You are incorrect. There has been a recent change. Please read comment 13 by James Forrester above. Here is the relevant part: "as of today, we have switched over to the 'beta' behaviour for VisualEditor in a number of regards, including section edit links - i.e., default behaviour for users with VisualEditor (which will soon be all users) is that section edit links will take you into VisualEditor, scrolled to that section, with the cursor at the start of it."
(In reply to comment #16) > Matthew. You are incorrect. There has been a recent change. You're right that the section editing default has changed for people who opted in to VE. However, if you've never changed any editing preferences (most registered users), you are still using the old editor by default. That will change, assuming the random test works well and VE continues to improve.
I commented at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Now_unable_to_edit_sections_by_old_method that it would be ideal to have section-edit links for [edit] and [edit source]. ie. Sandbox [edit] replaced with: Sandbox [edit] [edit source] I believe this would prevent a LOT of complaints in the short term, and it would permit a lot of us to continue being active beta testers (section-editing is my most frequent type of edit), that it should be High priority, if at all possible. Thanks.
(In reply to comment #17) > (In reply to comment #16) > > Matthew. You are incorrect. There has been a recent change. > > You're right that the section editing default has changed for people who > opted > in to VE. > > However, if you've never changed any editing preferences (most registered > users), you are still using the old editor by default. That will change, > assuming the random test works well and VE continues to improve. I think Timeshifter means the "which will soon be all users" part, and I agree that it would be very unfortunate. Quiddity's solution seems like the best one, and IMO should be implemented before the A/B test on en.wp.
I read the discussion, and it seems nobody mentioned what i think is the "real" bug here: we have the "edit source" link, that drops you back to wikitext editor. The correct behavior for ve should obviously be to drop you to a section edit if the hser entered edit state through an edit section link. Peace.
(In reply to comment #20) > I read the discussion, and it seems nobody mentioned what i think is the > "real" > bug here: we have the "edit source" link, that drops you back to wikitext > editor. The correct behavior for ve should obviously be to drop you to a > section edit if the hser entered edit state through an edit section link. > It does do so (in its own way). If you click a section-edit link, it currently enters VE edit-mode, and scrolls down to the section you clicked on, and places the cursor at the beginning of the section-header.
(In reply to comment #21) > (In reply to comment #20) > > I read the discussion, and it seems nobody mentioned what i think is the > > "real" > > bug here: we have the "edit source" link, that drops you back to wikitext > > editor. The correct behavior for ve should obviously be to drop you to a > > section edit if the hser entered edit state through an edit section link. > > > > It does do so (in its own way). If you click a section-edit link, it > currently > enters VE edit-mode, and scrolls down to the section you clicked on, and > places > the cursor at the beginning of the section-header. no it doesn't. what i meant is that if you click on the "edit" section link, and then see something that requires wikitext editing and click "edit source", you are dropped into "old" editor _for the whole page_. this means that there is no way to execute the old "section edit" in the wikitext editor. removing this existing functionality is a regression, and fixing it should be easy. "fixing it" meas that if you open the editor through a "section edit" link and then press "edit source", you will be in the exact same state as someone who has VE disabled and pressed the edit section link. failing to fix this causes editors to disable VE (i know for a fact that i am not the only one who disabled VE because of this very reason). peace.
Related URL: https://gerrit.wikimedia.org/r/68868 (Gerrit Change I13bbb9549c999bb7301bbcf530706a813184425d)
I submitted the patch above to show two links side-by-side, in the form of "[edit] [edit source]", similarly to how the article tabs are done.
I like kipod's ideas (comment 22). I think to more fully support section editing means to make it easy to choose either editor at any time. Let me explain. If the Bartosz patch is implemented (comment 24), or some variation of it, there will be "edit" and "edit source" links or icons on every section. It would be wonderful if the "edit source" links or icons for sections also showed up inside the Visual Editor. The Visual Editor could treat "edit source" links or icons as uneditable links. But the link would still work. So people could click "edit source" links or icons to open source editing of a section. People could go to source mode editing at anytime, even from inside the Visual Editor. That would be so convenient and so useful. Later on, this functionality could be extended to anything the Visual Editor can't edit. People could click on templates, tables, etc. inside the Visual Editor and go directly to source mode editing of that section. Or they could right-click templates, tables, etc. to go to a new tab in source mode for that section.
Timeshifter, this sounds very much like what is described at bug 43133.
Bartosz (comment 26). If I am reading bug 43133 right it sounds way too complicated. What I am suggesting is a simple "edit source" link to source mode editing of a section. Nothing fancy like floating windows, etc. tied in any way to the Visual Editor. One clicks out of the Visual Editor altogether. This means that edits to the source wikitext in a section are treated the same no matter how one got to that wikitext edit window. This avoids integration conflicts, additional edit conflicts, or anything complicated. Same for clicking on stuff Visual Editor can't edit. One is sent to source mode for the section where that stuff is found. Nothing more. For transcluded templates one still has to go to the bottom of the source-mode edit window for the whole page. That is where the list of transcluded templates is found. It would be nice if one could see such a list at the bottom of source-mode edit windows for sections too.
(In reply to comment #20) > I read the discussion, and it seems nobody mentioned what i think is the > "real" > bug here: we have the "edit source" link, that drops you back to wikitext > editor. The correct behavior for ve should obviously be to drop you to a > section edit if the hser entered edit state through an edit section link. > > Peace. I have created this as bug 49664.
(In reply to comment #25) > It would be wonderful if the "edit source" links or icons for sections also > showed up inside the Visual Editor. The Visual Editor could treat "edit > source" links or icons as uneditable links. But the link would still work. So > people could click "edit source" links or icons to open source editing of a > section. I have created this as bug 49665.
(In reply to comment #18) > I commented at > http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/ > Feedback#Now_unable_to_edit_sections_by_old_method > that it would be ideal to have section-edit links for [edit] and [edit > source]. > > ie. > Sandbox [edit] > replaced with: > Sandbox [edit] [edit source] > > I believe this would prevent a LOT of complaints in the short term, and it > would permit a lot of us to continue being active beta testers > (section-editing > is my most frequent type of edit), that it should be High priority, if at all > possible. Thanks. I have created this as bug 49666.
Related URL: https://gerrit.wikimedia.org/r/69984 (Gerrit Change I4b9c47fd65a700a81c880144247fec524edff7e5)
Just a note (for users not following the other bugs) that we have just merged a change along the lines of bug 49666 - there will be both an "edit" and an "edit source" link on every section, with the edit link taking the user into VisualEditor, scrolled down to that section. This enhancement request (to have VE appear just for a section within a wider page) is not impossible, and we're keen to explore what impact it has, but very hard, and blocked on Parsoid's HTML being used as the basis for MW's read pages, so may take some time.
*** Bug 50592 has been marked as a duplicate of this bug. ***
I can't believe that section editing is marked as a "lowest priority" "enhancement"! This is incredibly important to me. The way it's currently set up wastes bandwidth and slows load time relative to the old editor. Both of these are important when making a quick-fix edit. Hardly "marginal utility". James, please try regular editing on a slow connection if you haven't done this before, I'm pretty sure you'll end up editing the section source. I'm quite supportive of visual editor in general, but if this is not going to be fixed, I may have to turn back.
(In reply to comment #34) > I can't believe that section editing is marked as a "lowest priority" > "enhancement"! "Enhancement" means "the software doesn't do this, and isn't as-written meant to do this"; it's not a judgement on whether it should. "Lowest priority" means "the core developers of this are not intending to work on this issue any time soon"; bugs are always open to other developers coming and working on them, which frequently happens. "Lowest" is a very clear way of me marking the bug as something that can be taken up without fear of duplication of work by a developer new to the code. (This is known as avoiding "cookie licking".) > This is incredibly important to me. I appreciate that it is important to some editors, but I have to balance all requested features, changes and bugs with VisualEditor against one another, and in my judgement this is, relatively, an edge case. > The way it's currently set up wastes bandwidth and slows load time relative > to the old editor. Both of these are important when making a quick-fix edit. I agree with that; I recommend using the wikitext editor for exactly these use cases by power users if they prefer. > Hardly "marginal utility". That specifically refers to finding a solution which you don't want. A simpler solution - involving having the entire document available, but just not editable except for the section the user asked for - is do-able, but in that case, the benefits you're looking for (low bandwidth, fast loading time, low load on local computers) would not be present; hence, marginal utility. Solving what you're actually asking for (a form of VisualEditor/Parsoid that loaded and edited only one section at a time) would be a mammoth piece of work, albeit with some usefuless as you describe. > James, please try regular editing on a slow connection if you haven't done > this before, I'm pretty sure you'll end up editing the section source. I've edited Wikipedia (and other wikis) since 2001, including over heroically-terrible connexions through the years; I am very aware of the impact that our current site has on low-bandwidth users, even without VisualEditor, but I cannot justify spending donor funds to that extent when there are more pressing demands on the resources of the VisualEditor team. > I'm quite supportive of visual editor in general, but if this is not going > to be fixed, I may have to turn back. I'm sorry that that is the case, and hope that it does not come to that. Sorry if my explanation here is insufficient.
> Solving what you're actually asking for (a form of VisualEditor/Parsoid that > loaded and edited only one section at a time) would be a mammoth piece of > work, > albeit with some usefuless as you describe. > > > James, please try regular editing on a slow connection if you haven't done > > this before, I'm pretty sure you'll end up editing the section source. > > I've edited Wikipedia (and other wikis) since 2001, including over > heroically-terrible connexions through the years; I am very aware of the > impact > that our current site has on low-bandwidth users, even without VisualEditor, > but I cannot justify spending donor funds to that extent when there are more > pressing demands on the resources of the VisualEditor team. My first thought is what were people thinking when they thought that using a visual editor to edit a whole page at a time would not slow things down a lot for many users? I am not a developer though, and hindsight is 20/20. Whatever it costs to make a visual editor that edits a section at at time would be worth it. The WMF spends money on far less important things. I have been saying this for years. I think millions of dollars more a year should be spent on developer salaries just for the visual editor, and the coordination of vast armies of volunteer developers to work on the visual editor. Another spending priority would be developer money for cross-wiki watchlists.
> the core developers of this are not intending to work on this issue any time soon That's exactly what befuddles me, and seems like a poor judgement. If it's anywhere near as big a task as you envisage, then I can't expect a volunteer to take it up. So I conclude that realistically it will never be done. > having the entire document available, but just not editable Ok, I agree that would be useless, possibly of negative value. You're right that this is not what I'm asking for. >Parsoid that loaded and edited only one section at a time would be a mammoth piece of work Obviously I'm not a mediawiki programmer, so I speak from ignorance here. But I don't understand why Parsoid can't just be given a shorter piece of wikitext to parse, along with the section number it is starting at. Since the old editor is quite capable of serving up a correct section of the wikicode to the user, I don't see why the same wikicode can't be given to Parsoid. Please can you get a third and fourth opinion on the feasibility of this. Someone in your team may be able to think of a way around the problems you envisage. > I've edited Wikipedia (and other wikis) since 2001, including over heroically-terrible connexions So have you now also tried VisualEditor on those heroically-terrible connections? I'm willing to bet that you will feel the weight of this problem. >I cannot justify spending donor funds The whole goal of VisualEditor is to improve accessibility and the editing experience for lower-tech editors right? Well, the sad truth is that low-tech and globally underrepresented editor communities are strongly correlated with low bandwidth access. Section editing in a long article gives an order of magnitude speed gain to those editors. If you cannot do this for the target audience, I fear that VisualEditor will not serve those who need it the most. I really hope you will discuss this with more people before confining it to the dustbin.
Oh, and sorry to be pedantic, but in the original context, "marginal utility" was not referring to a specific semi-solution as far as I can see: >> I don't seem to be able to section edit with VisualEditor. > To edit a section, we would need to get its HTML from Parsoid - but a section isn't guaranteed to be balanced HTML ... > Coming up with a solution to this is would be a significant piece of engineering effort for marginal utility. Thank you for confirming now that you *do* see utility in stopping the waste of bandwidth and slowing of load time. Even if you think it is too difficult.
I appreciate the VE is a hard problem - but now you have an interface that *lies* to the user. It claims visual section editing is possible, but the PM for the VE has stated this functionality will not be funded. So, is the interface lying to the user this bug, or should it be a separate bug? If lying to the user is considered a feature, what is it for?
Ah, I see the "edit|edit source" links on sections have turned back into just "edit" links, which edit the wikitext. Thank you :-)
Ah, the disappearing double-links are Bug 50731.
This is quite serious for slow connections.
I'm upgrading this to "normal" since it's listed at #4 on https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm not seeing any good case for low/lowest made here.
(In reply to comment #43) > I'm upgrading this to "normal" since it's listed at #4 on > https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm > not > seeing any good case for low/lowest made here. The "priority" field doesn't mean "how much do people want it", it's "how soon are the developers likely to get to do it". As I explained above, this will require a series of major changes in Parsoid and a huge re-write of MediaWiki's skins system as we switch over to use Parsoid's generated HTML for read pages, and is many (many) months away - we're hoping to be able to undertake it some time towards the start/middle of next calendar year. Magically changing the status of the priority doesn't make this complex work happen any quicker. There is no value in edit-warring over Bugzilla statuses, so I'm going to leave this as is, but please don't make changes like this.
This: "but I cannot justify spending donor funds to that extent" just turned into: "we're hoping to be able to undertake it some time towards the start/middle of next calendar year" Which sure sounds like a priority change, so I'm not sure if my flag change was psychic-magic or precipitative-magic, but either way, it now seems like the correct priority status. I've tried communicating other ways: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Section_editing_will_never_be_implemented ("Any update from the dev discussion?") but got no answer, and the known problems page still says "not planned". Anyway, it's good to hear that you are now planning to do this. I'm sure it will be worth it for low-bandwidth editors.
upgrading this to "highest" as this is the main reason for item 1 (slow loading), item 2 (slow scrolling) and item 6 (no section editing) of https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems. personally i think this should be _the only_ "immediate". why? i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho. * 1 click and 15 secs to edit * 1 click to make go a away a note (see attachment) * 1 click to edit summary * 1 click and 20 secs to review changes * 1 click to return to save form * 1 click and 40 secs to save * 5* pg down to go to the section just edited section edit with the text editor takes: * 1 click and 2 secs to open * 1 click and 2 secs to preview * 1 pg-down to find the save button * 1 click and 10 secs to save
Created attachment 13058 [details] note blocks section edit
james, we tried your sections within a table example from above here: https://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/Known_problems#section_in_a_table and we could not create something useful.
(In reply to comment #2) > {| > ! Foo !! Bar > |- > === Section 1 === > |- > | Foo || bar > === Section 2 === > |- > | Foo || bar > |} > > Coming up with a solution to this is would be a significant piece of > engineering effort for marginal utility. The section editing feature in the old parser works by excluding all sections headings where the heading is not a child of the document root. The previous section thus runs on past the excluded heading. This means that a section can always be represented as a set of adjacent DOM subtrees. It seems to me that the same solution could be implemented in VE. The definition of "children of the document root" would change somewhat, since it is a different kind of DOM, so the number of excluded sections would be larger, but it would still be a better solution than what we have now. > * The reasons we brought in section-editing originally were two-fold - to > skip > past confusing wikitext in other areas to find the item you actually wanted > to > edit (not an issue in the context of VisualEditor), and to avoid edit > conflicts > using the page-based diffs at the time (not an issue for ~ 7 years since Tim > re-wrote the diff tool). Section editing has never had any special case to help with edit conflicts -- it was always dealt with using the generic three-way merge feature, which, for the record, I did not write. I think the main two reasons for implementing section editing were bandwidth and avoiding the need to scroll. Erik's original post on the subject suggests as much: http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/3433 Note that it was implemented at a time when 56k modems were still common -- I had one at the time, and I was certainly glad of the performance improvement. > * Editing by section blocks users from editing other areas at the same time > that the notice flaws in after they've entered editing, for very limited > added-value. For large articles, I think the added value would be very large indeed. People don't want to wait tens of seconds to make a small correction, and it's likely that VE performance causes many edits to be abandoned. Perhaps there are other solutions for the performance issue, but it seems to me that this is a fairly obvious approach, especially for bandwidth reduction. Yes, the existing feature prevents users from editing other sections on the page, which sucks. That could presumably be addressed in VE: a separate content-editable region could be created by each section edit click, to be saved in bulk.
(In reply to comment #49) > > Yes, the existing feature prevents users from editing other sections on the > page, which sucks. That could presumably be addressed in VE: a separate > content-editable region could be created by each section edit click, to be > saved in bulk. i agree with Tim's comment wholeheartedly, except the last paragraph: preventing the user from editing outside the section doesn't "suck". it's a great feature. when editing a section, we have automatically generated edit summary with the section name. for users that use wikitext editor, you pretty much know, when you see the very common "/* section name */ optional comment" edit summary, that the edit is indeed confined to the section whose name appears in the comment. but with VE, because of the wrong (IMHO) way bug 50872 was handled, a user can press the "sectionedit" link of some section, then edit anywhere on the page, and the summary will still show the section name of the click. this makes the summary practically useless: when looking at the history, seeing a section name in the summary tells me nothing - i don't care which button Joe pressed, i care which content was changed, and the summary does not tell me that anymore.[1] since the most urgent issue ATM for VE is unacceptable performance on longer articles with slower machines, true section edit would be (as Tim notes) a very very desirable feature. how about this: i think that the cases where a section is not balanced, in terms of html tags (the case described in comment 2) is very rare. how about falling back to full article edit in those rare cases? [2] true, it means that those cases would be even slower, but i believe that those are a negligible minority. the vast majority of the sections *are* balanced, and will gain greatly (performance wise) from the ability to edit a single section. peace. --------------------------------------------- [1] this can be handled by undoing the solution for bug 50872, and solving bug 51903 instead (i.e., create the summary by analyzing the diff instead of the button the user clicked), but the best thing, IMO, would be to support true "section edit" for VE. [2] this means: get the section content from the server, and if it "does not make sense", like the example in comment #2, get and edit the whole page.
Comment 46 ignored comment 44, hence making the priority value reflect reality again. If there are further good arguments to give this higher priority, feel free to convince the *developers* to set a higher priority again.
Mike Christie has a suggestion: Edit the whole page, but only display the chosen section. By this I don't think he means "discard" everything except the section, but instead just to cover up the other parts. We're already scrolling to the chosen section, so this would add maybe a gray or white block over everything above that (or perhaps collapse it), and ideally everything below it, too. This would help people who are using section editing to keep them focused on their chosen tasks, rather than because of beliefs about performance or edit conflicts.
Re comment 52: I agree that show/hide would be nice for the uneditable sections. More importantly, if this behaviour is implemented, please make it a preference option. I often use "edit beta" on one section in order to fix a problem I see in the section just above it; I'd hate to lose that capability.
Another thought on the preference: currently clicking on a section edit gives a pre-filled edit summary including the section. Whether this happens should depend on the same preference. If I have "section-editing" set to yes, I would get the pre-filled edit summary and other sections hidden; if I have it set to no, I would get no pre-filled edit summary, and I would see the whole article, as happens now. This would help avoid the (common) situation where the edit summary is misleading when a section edit is clicked.
No, it definitely shouldn't be a preference – instead, it should be possible for everyone to "expand" the editing area from the one section to the entire article.
(In reply to Tim Starling from comment #49) > > * Editing by section blocks users from editing other areas at the same time > > that the notice flaws in after they've entered editing, for very limited > > added-value. > > For large articles, I think the added value would be very large indeed. > People don't want to wait tens of seconds to make a small correction, and > it's likely that VE performance causes many edits to be abandoned. > > Perhaps there are other solutions for the performance issue, but it seems to > me that this is a fairly obvious approach, especially for bandwidth > reduction. For what it's worth... I did a non-scientific poll and asked the Hebrew Wikipedia community what are the people's reasons to avoid VE. Precisely this suggestion came up several times.
