hi,
in visual editor, would it be possible to edit only a paragraph, when one clicks the edit link on a paragraph? if not, why not? currently an a decent laptop, clicking the "edit" link on whatever page or section takes at least 4 seconds. this is unexpectedly slow.
i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again.
rupert
---------- Forwarded message ---------- From: bugzilla-daemon@wikimedia.org Date: Fri, Aug 2, 2013 at 11:03 AM Subject: [Bug 52380] split up VE into components, clickable via links where it is applicable To: rupert.thurner@gmail.com
Andre Klapper aklapper@wikimedia.org changed bug 52380https://bugzilla.wikimedia.org/show_bug.cgi?id=52380
WhatRemovedAddedStatusREOPENEDRESOLVED Resolution---WONTFIX
*Comment # 5 https://bugzilla.wikimedia.org/show_bug.cgi?id=52380#c5 on bug 52380 https://bugzilla.wikimedia.org/show_bug.cgi?id=52380 from Andre Klapper aklapper@wikimedia.org*
Please discuss such huge design decision suggestions first with developers on a mailing list, like http://lists.wikimedia.org/pipermail/wikitext-l/ , to break them down into manageable subtasks. Even if this was a valid request, it's pretty unhandable to define when this good be "fixed". I mark your proposed solution again as WONTFIX, as bug reports should be about problems instead. Please leave it like that as the solution proposed here is not planned to be implemented by developers like that.
On 2 August 2013 12:43, rupert THURNER rupert.thurner@gmail.com wrote:
i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again.
wikitext-l has had literally no posts since early June. It's certainly not where VE discussion is going on. Why would someone asking about VE be directed there?
- d.
On 08/02/2013 07:49 AM, David Gerard wrote:
On 2 August 2013 12:43, rupert THURNER rupert.thurner@gmail.com wrote:
i tried to create a bug to discuss splitting VE up to only edit parts of a page, see below. andre klapper suggested this ideally is broken up into requirements easier to implement, and i should post this to wikitext-l. as i did not see any discussion going on there about VE i tried here. please forward if this to the appropriate channel if i did not get it right again.
wikitext-l has had literally no posts since early June. It's certainly not where VE discussion is going on. Why would someone asking about VE be directed there?
Wikitext-l used to be where we talked about Parsoid *and* VE. Now that discussion of VE has moved to wikitech-l I've altered the list description at https://lists.wikimedia.org/mailman/listinfo/wikitext-l accordingly; I reckon wikitext-l is now just for parser/wikitext discussion. Sorry for the confusion.
On 08/02/2013 07:43 AM, rupert THURNER wrote:
hi,
in visual editor, would it be possible to edit only a paragraph, when one clicks the edit link on a paragraph? if not, why not? currently an a decent laptop, clicking the "edit" link on whatever page or section takes at least 4 seconds. this is unexpectedly slow.
Section editing is bug https://bugzilla.wikimedia.org/show_bug.cgi?id=48429 . My understanding is that it's on their road map, but down the road.
I'm not sure, but I think they are also considering implementing separate category editors, etc.
Matt Flaschen
On Sat, Aug 3, 2013 at 3:56 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/02/2013 07:43 AM, rupert THURNER wrote:
hi,
in visual editor, would it be possible to edit only a paragraph, when one clicks the edit link on a paragraph? if not, why not? currently an a decent laptop, clicking the "edit" link on whatever page or section takes at least 4 seconds. this is unexpectedly slow.
Section editing is bug https://bugzilla.wikimedia.org/show_bug.cgi?id=48429 . My understanding is that it's on their road map, but down the road.
i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho, and it is 6 clicks + 5 pgdn + 75 seconds compared to 3 clicks + 1 pgdn + 14 secs. * 1 click and 15 secs to edit * 1 click to make go a away a note (see attachment at the bug) * 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 (which is imo unnecessary, should be on top as well) * 1 click and 10 secs to save
rupert.
I think we can agree that VE has some performance considerations, but if you take a look at the bug report, it's explained why it would be so incredibly difficult to implement section editing.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Aug 3, 2013 at 4:12 AM, rupert THURNER rupert.thurner@gmail.comwrote:
On Sat, Aug 3, 2013 at 3:56 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/02/2013 07:43 AM, rupert THURNER wrote:
hi,
in visual editor, would it be possible to edit only a paragraph, when
one
clicks the edit link on a paragraph? if not, why not? currently an a
decent
laptop, clicking the "edit" link on whatever page or section takes at
least
4 seconds. this is unexpectedly slow.
Section editing is bug https://bugzilla.wikimedia.org/show_bug.cgi?id=48429 . My understanding is that it's on their road map, but down the road.
i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho, and it is 6 clicks + 5 pgdn + 75 seconds compared to 3 clicks + 1 pgdn + 14 secs.
- 1 click and 15 secs to edit
- 1 click to make go a away a note (see attachment at the bug)
- 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 (which is imo unnecessary, should
be on top as well)
- 1 click and 10 secs to save
rupert.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I tried the example from the bug report on the VE talk page, it did not render properly. It is only hypothetical, isn t it?
Am 03.08.2013 17:31 schrieb "Tyler Romeo" tylerromeo@gmail.com:
I think we can agree that VE has some performance considerations, but if you take a look at the bug report, it's explained why it would be so incredibly difficult to implement section editing.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Aug 3, 2013 at 4:12 AM, rupert THURNER <rupert.thurner@gmail.com wrote:
On Sat, Aug 3, 2013 at 3:56 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 08/02/2013 07:43 AM, rupert THURNER wrote:
hi,
in visual editor, would it be possible to edit only a paragraph, when
one
clicks the edit link on a paragraph? if not, why not? currently an a
decent
laptop, clicking the "edit" link on whatever page or section takes at
least
4 seconds. this is unexpectedly slow.
Section editing is bug https://bugzilla.wikimedia.org/show_bug.cgi?id=48429 . My
understanding
is that it's on their road map, but down the road.
i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho, and it is 6 clicks + 5 pgdn + 75 seconds compared to 3 clicks + 1 pgdn + 14 secs.
- 1 click and 15 secs to edit
- 1 click to make go a away a note (see attachment at the bug)
- 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 (which is imo unnecessary, should
be on top as well)
- 1 click and 10 secs to save
rupert.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Aug 4, 2013 1:31 AM, "Tyler Romeo" tylerromeo@gmail.com wrote:
I think we can agree that VE has some performance considerations, but if you take a look at the bug report, it's explained why it would be so incredibly difficult to implement section editing.
Not really. Some sections on some pages are complex, like that example. Most sections on most pages are bog standard.
Detect the complicated cases and mark those cases non-section-editable, or mark the set of sections involved as 'must be section edited as one group'.
p.s. Try VE on 26kbps - that is all my mother can obtain currently, unless she gets satellite, which is too expensive for her - she lives ~10 kms from what is considered to be a large city in Australia. And she is over 70yo and has more than 500 edits. She is happy with the wikitext editor (and learnt it herself with the messy help pages we have) and thinks it is simpler than word processing apps (which she has to relearn regularily because they keep changing every few years).
-- John
On 3 August 2013 21:06, John Vandenberg jayvdb@gmail.com wrote:
p.s. Try VE on 26kbps - that is all my mother can obtain currently, unless she gets satellite, which is too expensive for her - she lives ~10 kms from
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
- d.
On Sat, 03 Aug 2013 22:13:34 +0200, David Gerard dgerard@gmail.com wrote:
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
I very much doubt it; however, thanks to ResourceLoader, the bandwidth is very rarely the bottleneck or even noticeable. The loading slowness comes mostly from poorly written extensions which load themselves with higher priority (ULS has this kind of problems, but I think they were since fixed) or poorly written or not RL-compatible default user scripts and gadgets (just about every single one, sadly).
On 3 August 2013 21:25, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sat, 03 Aug 2013 22:13:34 +0200, David Gerard dgerard@gmail.com wrote:
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
I very much doubt it; however, thanks to ResourceLoader, the bandwidth is very rarely the bottleneck or even noticeable.
I would strongly suggest you not declare it not noticeable until you've tried it.
- d.
On Sat, 03 Aug 2013 22:29:57 +0200, David Gerard dgerard@gmail.com wrote:
On 3 August 2013 21:25, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Sat, 03 Aug 2013 22:13:34 +0200, David Gerard dgerard@gmail.com wrote:
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
I very much doubt it; however, thanks to ResourceLoader, the bandwidth is very rarely the bottleneck or even noticeable.
I would strongly suggest you not declare it not noticeable until you've tried it.
I do my day-to-day browsing on a connection probably considered slow by American standards, 1 mbps down on a good day. Surely it's no 26 kbps, but still at the bottom end of the spectrum. I am the last person you could accuse of catering only to audiences which happen to live in high-tech areas, both in terms of loading speed and general resource-intensiveness, as the laptop I am using for browsing and development has already been considered mid-end in 2006 when it was released.
As I said in the part of my message you left out, the actual download slowness is rarely caused by either core MediaWiki scripts or extensions' ones, which go through ResourceLoader; the culprit is local wiki customizations. All RL-loaded scripts are loaded together in just a few requests to the server, minified and gzipped, with any graphics embedded in the same requests as well; however, each non-RL-compatible script is loaded in it's own separate HTTP request without minification, and each image it uses is one more request. These add up very quickly.
Try sometimes comparing the English Wikipedia to a vanilla MediaWiki; or try loading Special:Preferences and compare the loading speed to regular browsing (all custom scripts are disabled there, I think in order to make it harder to completely break your account by enabling broken gadgets). Anonymous users don't have it too bad, still, but any power-user with dozens of gadgets enabled can feel a world of difference.
On Aug 4, 2013 6:14 AM, "David Gerard" dgerard@gmail.com wrote:
On 3 August 2013 21:06, John Vandenberg jayvdb@gmail.com wrote:
p.s. Try VE on 26kbps - that is all my mother can obtain currently,
unless
she gets satellite, which is too expensive for her - she lives ~10 kms
from
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
I was there yesterday, only briefly so I didnt have time to do any perf testing, but it was clearly worse compared to the last time I did it. I suspect ULS is playing its part of the problem, but user doesnt care which feature is to blame. I am sure there are 'dialup' simulators, but nothing beats a real modem struggling to avoid dropouts when its the last connection on a fair dinkum noisey line.
Just consider what the image insertion dialog is doing, and it clear the VE is not being designed to accomodate dialup users at all. Understandable. Hopefully soon we'll be able to replace stock widgets with low bandwidth equivalents.
John
Le 03/08/13 22:13, David Gerard a écrit : <snip>
I would actually be interested to know if new Javascript, new functionality, things like the VE, etc. are routinely tested on slow connections. Is there anything like this in place?
That is a recurring issue in software development. The developers usually have buffed computer and top internet connectivity which indeed loose some optimization :-] Once upon a time, by the time you released your software, the mass market eventually reached the same spec as your (then) top of the art computer and that was not much of an issue.
Maybe we could try simulating performances using small VM with a capped network access.
wikitech-l@lists.wikimedia.org