Remove 'visualeditor-enable' from $wgHiddenPrefs

classic Classic list List threaded Threaded
101 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Antoine Musso-3
Le 23/07/13 21:12, Bartosz Dziewoński a écrit :
> On a side note, I find it interesting how none of the actual VE and
> Parsoid developers replied here, apart from Roan, Chris and Subbu on
> off-topic technical issues (thanks for that).

I am myself not replying because I don't want to be involved.  I will
happily apply any change if there is a clear acknowledgement by all parties.

Meanwhile I am waiting for a consensus to form in one way or another one.

--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: VE and <nowiki>

John Mark Vandenberg
In reply to this post by Steve Summit
On Wed, Jul 24, 2013 at 6:11 AM, Steve Summit <[hidden email]> wrote:
> VE will (correctly, from its point of view) translate that to
> "<nowiki>[[pagename]]</nowiki>" in the page source.
>
> This is a likely enough mistake, and the number of times you
> really want explicit double square brackets is small enough, that
> it's worth thinking about (if it hasn't been already) having VE
> detect and DTRT when a user types that.

There is an enhancement for that.

https://bugzilla.wikimedia.org/show_bug.cgi?id=51897

IMO the current behaviour isnt correct.  There are so few instances
that nowiki is desirable, that the current VE should refuse to accept
wikitext (at least [[ and {{, and maybe ==, # and * at beginning of
line, etc ), until at least such time as they have sorted out all the
other bugs causing this to happen unintentionally.  If the user needs
to input [[ or {{ they can use the source editor.  Or the VE could
walk the user through each nowiki and either a) ask the user to
confirm they want the obvious fix done automatically for them, or b)
help them fix the problem.  Before saving.

nowiki is also being inserted at beginning of lines.

https://es.wikipedia.org/w/index.php?title=Yacimiento_de_Son_Forn%C3%A9s&diff=prev&oldid=68561708
https://fr.wikipedia.org/w/index.php?title=Joel_Lindpere&curid=5580501&diff=95038161&oldid=95037498

instead of lists

https://es.wikipedia.org/w/index.php?title=Jorge_Eslava&diff=68542729&oldid=68451155

There are 24 open bugs for 'visualeditor nowiki'

https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearch&quicksearch=visualeditor%20nowiki&list_id=219994

--
John Vandenberg

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

C. Scott Ananian
In reply to this post by Antoine Musso-3
I am a Parsoid developer.  I was participant #6 in the thread.  As noted,
reponses #14 and #16 were also from VE developers, and our contributions
have continued.  From my perspective the devs involved have done a pretty
good job of picking out technical content from the discussion and acting on
it (creating bugzilla entries and/or adjusting priorities of existing
entries).

I will note that "# of bugzilla items for a component" is not any sort of
proxy for "bugginess".  Bugzilla is used for feature planning, for
refactoring, for notes-to-self about minor cleanups, for discussion of
build/testing infrastructure, etc -- and even when it is recording "bugs",
those bugs vary greatly in severity (from "different than PHP rendering but
probably it's the old PHP renderer which needs to be fixed" through
"technically a bug but we grepped through all wikipedias and couldn't find
anyone using this particular construct" up to "OMG").  And then there are
the dups.

I appreciate Robert Rohde's quantification efforts.  I'll note that I am
currently reviewing a fix written by subbu for the single instance of "VE /
Parsoid errors" in his sample.  I thought that his point was excellent
about all the existing help pages written using wiki syntax.  It would be a
great help if the community could help update those.
  --scott

--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Chris McMahon
In reply to this post by Roan Kattouw-2
On Tue, Jul 23, 2013 at 1:42 PM, Roan Kattouw <[hidden email]>wrote:

> On Tue, Jul 23, 2013 at 12:44 PM, Daniel Barrett <[hidden email]>
> wrote:
> > Risker asks:
>
> Of course those <nowiki> tags weren't added by the editors, VE doesn't
> let you do that directly. What I think Robert was talking about
> (thanks for that analysis, BTW!) is edits where the user typed
> something like "[[Foo]]" into the editor, and Parsoid, in order to
> achieve a truthful rendering of "[[Foo]]", wraps it in <nowiki> tags.
> That's a case of "we did what the user asked us to do, although the
> user probably didn't mean that".

...


> These kinds of
> technically-correct-but-probably-not-what-you-wanted issues are a bit
> tricky. They're on our list of things to deal with though.


 FWIW, the WYSIWYG editor for the Socialtext wiki handles these cases well,
and has since at least 2007 or so.  I think Wikia is (or was) using some
derivative of this "Wikiwyg" editor.  Regardless, it might be a useful
oracle for VE behavior.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: VE and <nowiki>

Roan Kattouw-2
In reply to this post by John Mark Vandenberg
On Tue, Jul 23, 2013 at 2:14 PM, John Vandenberg <[hidden email]> wrote:

> There is an enhancement for that.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51897
>
> IMO the current behaviour isnt correct.  There are so few instances
> that nowiki is desirable, that the current VE should refuse to accept
> wikitext (at least [[ and {{, and maybe ==, # and * at beginning of
> line, etc ), until at least such time as they have sorted out all the
> other bugs causing this to happen unintentionally.  If the user needs
> to input [[ or {{ they can use the source editor.  Or the VE could
> walk the user through each nowiki and either a) ask the user to
> confirm they want the obvious fix done automatically for them, or b)
> help them fix the problem.  Before saving.
>
We disagree on that one then. VisualEditor is meant to hide wikitext
entirely. The primary focus is on people that don't know wikitext. I
agree that we should keep nowiki-fication to a minimum and get rid of
the other bugs that cause this to happen, but I think the action we
currently take when a user types in wikitext (which is to warn them
and say "this won't work") is appropriate. VE is meant to be a visual
editor, not a visual-except-with-weird-shortcuts-that-only-make-sense-if-you-know-the-legacy-markup-we-used-before-your-time
editor.

That's my opinion. Actual product direction is not something I'm in
charge of, that's James F's job, but AFAIK our current product
direction is similar to what I just said.

> nowiki is also being inserted at beginning of lines.
>
> https://es.wikipedia.org/w/index.php?title=Yacimiento_de_Son_Forn%C3%A9s&diff=prev&oldid=68561708
> https://fr.wikipedia.org/w/index.php?title=Joel_Lindpere&curid=5580501&diff=95038161&oldid=95037498
>
That's because the lines start with a space, which triggers a <pre> if
not nowiki-ed. Obviously the correct thing to do there is just remove
the space, but we haven't fixed that yet.

> instead of lists
>
> https://es.wikipedia.org/w/index.php?title=Jorge_Eslava&diff=68542729&oldid=68451155
>
Once again that's people typing wikitext into VE, which is not supported.

> There are 24 open bugs for 'visualeditor nowiki'
>
> https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearch&quicksearch=visualeditor%20nowiki&list_id=219994
>
A lot of those are parts of symptoms of other bugs, and I'm pretty
sure a few of them are duplicates. <nowiki> often appears when
something else goes wrong and Parsoid attempts to fix things.

Roan

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: VE and <nowiki>

Robert Rohde
On Tue, Jul 23, 2013 at 2:55 PM, Roan Kattouw <[hidden email]> wrote:
<snip>

> We disagree on that one then. VisualEditor is meant to hide wikitext
> entirely. The primary focus is on people that don't know wikitext. I
> agree that we should keep nowiki-fication to a minimum and get rid of
> the other bugs that cause this to happen, but I think the action we
> currently take when a user types in wikitext (which is to warn them
> and say "this won't work") is appropriate. VE is meant to be a visual
> editor, not a visual-except-with-weird-shortcuts-that-only-make-sense-if-you-know-the-legacy-markup-we-used-before-your-time
> editor.
>
> That's my opinion. Actual product direction is not something I'm in
> charge of, that's James F's job, but AFAIK our current product
> direction is similar to what I just said.
<snip>

If we accept, as a premise, that VE is aiming to eventually be the
best possible wiki editor for everyone, then I would say part of that
includes providing shortcuts and alternative workflows for some tasks.
 Often power users may want an approach that works well for them, but
isn't necessarily intended to be easily discoverable by newbies.
Keyboard shortcuts are an example of this on many platforms.

To use an obvious example, the template editor coupled to TemplateData
is snazzy and probably helpful to many users who don't know parameter
names or aren't comfortable with syntax.  That said, the template
editor is not particularly fast.  For many applications using it can
be much more cumbersome than editing the wikitext directly, assuming
you already know what you want to edit / add.

While developers can (and probably should) work on making tools like
the template editor easier to use, that isn't necessarily the best
solution for all users.  For many workflows giving power users a
limited means of manipulating wikitext directly -- without busting all
the way out of VE -- would seem to be a natural way of improving the
power user experience.  Access to wikitext within VE could be
controlled by a button, or an option, or a keyboard shortcut, or magic
keystrokes like "[[" and "{{" that just work the old way.  Any of
those approaches could work and each comes with different pluses and
minuses.  In the long run providing good usability for the complex
tasks frequently performed by power users is just as important as
providing tools for newbies (at least if we assume VE is intended for
everyone), and I strongly believe that some form of advanced shortcuts
or integrated wikitext-like mode will likely be a part of that.

It's not enough to provide a pretty visual interface.  One also has to
find ways to make that interface efficient and useful across a wide
spectrum of different user needs.

-Robert Rohde

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

James Forrester-4
In reply to this post by James Forrester-4
On 22 July 2013 18:35, James Forrester <[hidden email]> wrote:

> On 22 July 2013 11:45, Tyler Romeo <[hidden email]> wrote:
>
>> Putting all of the issues aside, I'd like to know what the reason is for
>> hiding the preference. Let's assume for a second that VE does not hinder
>> users at all, that it's JS footprint is nonexistent, and that the
>> interface
>> changes aren't that bothersome (which, to an extend, are true). Even with
>> all that, what reason is there to purposely deprive users of the choice to
>> completely hide VE if they're sure they have no intention of using it?
>>
>
> ​Adding a preference to disable VisualEditor in normal user preferences
> (rather than making it as easy as possible for gadgets to disable if people
> so chose) would be a lie.
>
> ​[​
> …
> ​]
>

>  ​Creating such a preference is a lie, and a lie I cannot endorse.
>

… and yet, here I am endorsing this. :-)​

 Because I understand the level of concern that this matter is causing, I
am changing my mind on this. For the duration of VisualEditor's "beta"
period, there will be an opt-out user preference. This will be deployed
tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta',
this preference will be removed.

As others have explained better than I, we think that users will be
ill-served by this opt-out, and I hope that as few users as possible will
choose this way to degrade their experience and deprive the community of
their input. Instead of endlessly arguing the point about this, I'd rather
my team and I spending our time working to make our sites better.

​J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

[hidden email] | @jdforrester
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Alex Monk
Thank you for changing your mind.
I might have missed something, but is there any schedule for when
VisualEditor will be considered 'out of beta'? Or is it simply a case of
the VE team deciding that it's stable enough?

Alex Monk

On Wed, Jul 24, 2013 at 2:55 AM, James Forrester
<[hidden email]>wrote:

>  Because I understand the level of concern that this matter is causing, I
> am changing my mind on this. For the duration of VisualEditor's "beta"
> period, there will be an opt-out user preference. This will be deployed
> tomorrow morning, San Francisco time. Once VisualEditor is out of 'beta',
> this preference will be removed.
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tyler Romeo
In reply to this post by James Forrester-4
On Tue, Jul 23, 2013 at 9:55 PM, James Forrester
<[hidden email]>wrote:

> I hope that as few users as possible will
> choose this way to degrade their experience and deprive the community of
> their input. Instead of endlessly arguing the point about this, I'd rather
> my team and I spending our time working to make our sites better.
>

I don't understand. Are you purposely trying to instigate this matter? All
of a sudden just because somebody prefers editing source code they're
"depriving the community". Or do you seriously believe that there is
literally nothing better than VE and that VE is the choice for everybody?

Once VisualEditor is out of 'beta', this preference will be removed.
>

What you meant to say is that when VE comes out of "beta", you'll post to
this mailing list again so we can discuss whether the user preference is
still appropriate. And if it's decided that it's no longer needed, then it
will be removed.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Ori Livneh
In reply to this post by Alex Monk
On Tue, Jul 23, 2013 at 7:22 PM, Alex Monk <[hidden email]> wrote:

> I might have missed something, but is there any schedule for when
> VisualEditor will be considered 'out of beta'?


Not so soon that we couldn't afford to let this thread die down for a bit.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tim Starling-2
In reply to this post by Erik Moeller-4
On 23/07/13 04:36, Erik Moeller wrote:
> 1) Section editing behavior - the hybrid link display is mildly
> annoying, and doesn't work for touch interfaces;

I think it's a bit more than mildly annoying, and I think it's the
main reason users are so desperate to disable VE completely instead of
simply not clicking on it.

Consider it from a cognitive point of view:

Half the time (e.g. on talk pages), the section edit link will go to
the old edit page, and the other half, it will flash an "edit source"
link at you for the 100ms or so it takes to stabilise the cursor
position and execute a mouse click, and then it will launch the visual
editor. Often, the user is punished for clicking on the wrong link by
having their browser lock up for 15 seconds.

Habit formation is cleverly avoided by changing the function of the
link depending on what namespace you are on.

I know that this crafty UI was introduced to encourage users to use
the new editor. The trouble is, this assumes that users have no idea
which editor they want to use, and thus will happily use whatever
editor the JS can trick them into clicking. But, I suspect, most users
have decided which editor they want to use before they start moving
their mouse.

I think users should be encouraged to use VE by making VE really
awesome, and by promoting its awesomeness, rather than by trying to
trick them into using it.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Rob Moen
I personally know for a fact nobody is trying to trick the user in this case.   We are simply trying to make editing easier for new editors without confusing them.  As a membwr f the visual editor team, I'm supportive of our advanced and seemingly more important editors opt-out during the beta.  


Sent from Mailbox for iPhone


On Tue, Jul 23, 2013 at 21:23, Tim Starling <[hidden email]="mailto:[hidden email]">> wrote:
On 23/07/13 04:36, Erik Moeller wrote:
> 1) Section editing behavior - the hybrid link display is mildly
> annoying, and doesn't work for touch interfaces;

I think it's a bit more than mildly annoying, and I think it's the
main reason users are so desperate to disable VE completely instead of
simply not clicking on it.

Consider it from a cognitive point of view:

Half the time (e.g. on talk pages), the section edit link will go to
the old edit page, and the other half, it will flash an "edit source"
link at you for the 100ms or so it takes to stabilise the cursor
position and execute a mouse click, and then it will launch the visual
editor. Often, the user is punished for clicking on the wrong link by
having their browser lock up for 15 seconds.

Habit formation is cleverly avoided by changing the function of the
link depending on what namespace you are on.

I know that this crafty UI was introduced to encourage users to use
the new editor. The trouble is, this assumes that users have no idea
which editor they want to use, and thus will happily use whatever
editor the JS can trick them into clicking. But, I suspect, most users
have decided which editor they want to use before they start moving
their mouse.

I think users should be encouraged to use VE by making VE really
awesome, and by promoting its awesomeness, rather than by trying to
trick them into using it.
-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Rob Moen
My apologies for the ham handed email.  I'm supportive of the opt out feature while ve is in beta.  Going forward I agree with the notion that experienced editors know what editor they want to use before the page completely loads.  I like the idea of a preference to select a default editor. 

Sent from Mailbox for iPhone

On Tue, Jul 23, 2013 at 9:32 PM, Rob Moen <[hidden email]> wrote:

> I personally know for a fact nobody is trying to trick the user in this case.   We are simply trying to make editing easier for new editors without confusing them.  As a membwr f the visual editor team, I'm supportive of our advanced and seemingly more important editors opt-out during the beta.  
> —
> Sent from Mailbox for iPhone
> On Tue, Jul 23, 2013 at 21:23, Tim Starling <[hidden email]="mailto:[hidden email]">> wrote:
> On 23/07/13 04:36, Erik Moeller wrote:
>> 1) Section editing behavior - the hybrid link display is mildly
>> annoying, and doesn't work for touch interfaces;
> I think it's a bit more than mildly annoying, and I think it's the
> main reason users are so desperate to disable VE completely instead of
> simply not clicking on it.
> Consider it from a cognitive point of view:
> Half the time (e.g. on talk pages), the section edit link will go to
> the old edit page, and the other half, it will flash an "edit source"
> link at you for the 100ms or so it takes to stabilise the cursor
> position and execute a mouse click, and then it will launch the visual
> editor. Often, the user is punished for clicking on the wrong link by
> having their browser lock up for 15 seconds.
> Habit formation is cleverly avoided by changing the function of the
> link depending on what namespace you are on.
> I know that this crafty UI was introduced to encourage users to use
> the new editor. The trouble is, this assumes that users have no idea
> which editor they want to use, and thus will happily use whatever
> editor the JS can trick them into clicking. But, I suspect, most users
> have decided which editor they want to use before they start moving
> their mouse.
> I think users should be encouraged to use VE by making VE really
> awesome, and by promoting its awesomeness, rather than by trying to
> trick them into using it.
> -- Tim Starling
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Steven Walling
In reply to this post by Tim Starling-2
On Tue, Jul 23, 2013 at 9:23 PM, Tim Starling <[hidden email]>wrote:

> I know that this crafty UI was introduced to encourage users to use
> the new editor. The trouble is, this assumes that users have no idea
> which editor they want to use, and thus will happily use whatever
> editor the JS can trick them into clicking. But, I suspect, most users
> have decided which editor they want to use before they start moving
> their mouse.
>
> I think users should be encouraged to use VE by making VE really
> awesome, and by promoting its awesomeness, rather than by trying to
> trick them into using it.
>

You could not be more wrong in this case, and it's a pretty stunning case
of bad faith on your part, Tim.

This interaction was committed by a volunteer not on the VE team.[1][2]
Ideally,VE would be good enough that we wouldn't need edit source links on
sections at all. Personally I advocated for not including them by any
method. However, people felt that it was important to give users a choice
on section edit links, and that as opposed to a dropdown or simply
displaying both links statically, using a progressive display was the more
elegant way of showing both options. MatmaRex could not have been clearer
about this on the patch.

I think everyone would probably agree that there are some annoying things
about the way it currently works, namely that it activates the display
action anytime you scroll past the section, even very far away from the
normal section edit target area. This is a detail that can be fixed. But I
can assure that the current section edit behavior was a compromise with
community developer support, to make sure that people who don't want to
edit sections with VE can do so.

1. https://bugzilla.wikimedia.org/show_bug.cgi?id=49666
2. https://gerrit.wikimedia.org/r/#/c/69984/
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Tim Starling-2
In reply to this post by Tim Starling-2
I wrote:
> I think users should be encouraged to use VE by making VE really
> awesome, and by promoting its awesomeness, rather than by trying to
> trick them into using it.

To clarify: I didn't mean to imply that the VE team were trying to
trick users. They are not. I just mean that if you consider the user
interface as a black box, solely from the perspective of how users
think during their interactions with the computer, it appears to them
as if the interface is trying to trick them. I'm trying to explain why
users have an emotional reaction to the interface.

It's well known that users react emotionally to computers as if the
computers were people. For example, people tend to be less angry with
a computer if it apologises when something doesn't work. When a
computer appears to trick you, you get angry, regardless of the
intentions of the developer.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Bartosz Dziewoński
In reply to this post by Steven Walling
On Wed, 24 Jul 2013 07:35:02 +0200, Steven Walling <[hidden email]> wrote:

> This interaction was committed by a volunteer not on the VE team.[1][2]
> Ideally,VE would be good enough that we wouldn't need edit source links on
> sections at all. Personally I advocated for not including them by any
> method. However, people felt that it was important to give users a choice
> on section edit links, and that as opposed to a dropdown or simply
> displaying both links statically, using a progressive display was the more
> elegant way of showing both options. MatmaRex could not have been clearer
> about this on the patch.
>
> 1. https://bugzilla.wikimedia.org/show_bug.cgi?id=49666
> 2. https://gerrit.wikimedia.org/r/#/c/69984/

Not true; the patch was rewritten by Trevor, and he's marked as the author. My version was showing both of the links all the time, with no animations, and I still think it's a better solution.


--
Matma Rex

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

John Erling Blad
An UI showing both edit links all the time is a much better way to do
it. I had the same discussion 20 years ago and as far as I know
nothing has changed when it comes to hidden user interactions that
suddenly (and with no explanation) changes the interaction and takes
the user with surprise. Sorry but the UI as it is now in this regard
is a complete failure. Looks cool but is BAD.

I would suggest that interaction intense actions like this in the
future should be implemented without fancy animations, hidden
information and changing interactions.

Another thing is that the community asks for some way to turn this
off, while WMF that is supposed to support the community goes against
the community. That is really BAD. If there are no real reasons to not
support what the community asks for, then WMF should have a really
really REALLY good reason for why t goes against the community. This
should not be a discussion about technical feasibility, it should be a
discussion about what the community wants.

I suggest that WMFs technical staff starts to listen more to the
community in this kind of matters, they are the one that are going to
use the features anyhow. The ongoing discussion now only alienates WMF
from the community

There are good reasons why users want to turn off VE and the most
important reason are not what most people in the thread seems to
think. Users that have learned to use a crappy direct editing user
interface tend to be faster on using that interface than more modern
WYSIWYG editors. I tried to make a few test edits whit carefully
planned actions and I could not edit as fast with VE as with the old
crappy edit page. I think this is quite common. When editors tries to
edit with the new editor they experience this and gets the feeling
that VE itself is sluggish, but the real reason is that the user
interactions slows down. The difference in editing speed i visible
even at ordinary text with only minor wikicode, but as the amount of
wikicode increases the diference grows.

I suggest that VE might be the first editing interface for new users,
but experienced users should be able to chose the editing interface
they are most comfortable with, not to say the one where they edit the
fastest.

I think it would be sufficient to remove the animation from the edit
bar, but for users that refuses to use VE completely it could be wise
to provide an option for remove the links, otherwise this kind of
functionality will be provided as a gadget.

jeblad

On Wed, Jul 24, 2013 at 10:56 AM, Bartosz Dziewoński
<[hidden email]> wrote:

> On Wed, 24 Jul 2013 07:35:02 +0200, Steven Walling
> <[hidden email]> wrote:
>
>> This interaction was committed by a volunteer not on the VE team.[1][2]
>> Ideally,VE would be good enough that we wouldn't need edit source links on
>> sections at all. Personally I advocated for not including them by any
>> method. However, people felt that it was important to give users a choice
>> on section edit links, and that as opposed to a dropdown or simply
>> displaying both links statically, using a progressive display was the more
>> elegant way of showing both options. MatmaRex could not have been clearer
>> about this on the patch.
>>
>> 1. https://bugzilla.wikimedia.org/show_bug.cgi?id=49666
>> 2. https://gerrit.wikimedia.org/r/#/c/69984/
>
>
> Not true; the patch was rewritten by Trevor, and he's marked as the author.
> My version was showing both of the links all the time, with no animations,
> and I still think it's a better solution.
>
>
> --
> Matma Rex
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

David Cuenca Tudela
On Wed, Jul 24, 2013 at 5:34 AM, John Erling Blad <[hidden email]> wrote:

> There are good reasons why users want to turn off VE and the most
> important reason are not what most people in the thread seems to
> think. Users that have learned to use a crappy direct editing user
> interface tend to be faster on using that interface than more modern
> WYSIWYG editors. I tried to make a few test edits whit carefully
> planned actions and I could not edit as fast with VE as with the old
> crappy edit page. I think this is quite common. When editors tries to
> edit with the new editor they experience this and gets the feeling
> that VE itself is sluggish, but the real reason is that the user
> interactions slows down. The difference in editing speed i visible
> even at ordinary text with only minor wikicode, but as the amount of
> wikicode increases the diference grows.


I would love if the Visual Editor could have also wikicode edition
capabilities with proper synthax highlighting.
There is the Dot's syntax highlighter as a gadget but it doesn't come close
to other code highlighters like Notepad++
Would that be possible?

Micru
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Terry Chay
In reply to this post by Alex Monk
Alex,

On Jul 23, 2013, at 7:22 PM, Alex Monk <[hidden email]> wrote:

> Thank you for changing your mind.
> I might have missed something, but is there any schedule for when
> VisualEditor will be considered 'out of beta'?

You have not missed something. There is no schedule yet for "out of beta" and it's still to early to make an accurate estimate for that.

> Or is it simply a case of
> the VE team deciding that it's stable enough?

It's not going to be as simple as this either. ;-)

Take care,

terry


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Remove 'visualeditor-enable' from $wgHiddenPrefs

Terry Chay
In reply to this post by Tyler Romeo
Tyler Romeo,

On Jul 23, 2013, at 8:55 PM, Tyler Romeo <[hidden email]> wrote:

> On Tue, Jul 23, 2013 at 9:55 PM, James Forrester
> <[hidden email]>wrote:
>
>> I hope that as few users as possible will
>> choose this way to degrade their experience and deprive the community of
>> their input. Instead of endlessly arguing the point about this, I'd rather
>> my team and I spending our time working to make our sites better.
>>
>
> I don't understand. Are you purposely trying to instigate this matter?

Whoa. Them's fighting words! :-D

> All
> of a sudden just because somebody prefers editing source code they're
> "depriving the community".

I prefer editing in source mode (at least based on my edit history). But I don't feel the need to turn on this preference. I didn't find it too hard to click "Edit Source" after the first day. We are not talking about people who prefer to edit source at all. We are talking about people who find clicking "Edit Source" so inconveniencing that they need to enable a gadget to remove it completely from the UI. Unless you really want to go all phoenixoverride on how 2.9K is the end-of-wikipedia-as-we-know-it.

For full disclosure, the VE team reports to me so maybe that makes me biased. I don't know. I think this makes me embarrassed and a little guilty that I don't use VE more. :-D

> Or do you seriously believe that there is
> literally nothing better than VE and that VE is the choice for everybody?

You may not have meant it, but this is a fallacy of False Choice. What is being talked about isn't "forcing" people to use VE, but hiding VE from the UI completely. There's a lot in the UI on the wikis, I have never used, nor plan to, so really this sturm and drang among engineers about what makes correct UI or good product design. Engineering has weighed in as to the patch as it stands, and this is a product decision. As you put it earlier:

> The real root of this discussion is whether or not the method through which
> VE is disabled is done as a Gadget or as a user preference. Both methods
> are already implemented, it's just a matter of a configuration variable.
>
> With that said, I'd like to see more points on what real motivation there
> is to force users to have a gadget to do something that an existing user
> preference already does.

Which is really a way of saying, "This isn't an engineering issue (yet), so what is the product and UI reasoning here?"

The reasoning from product (James and Erik earlier in this thread, as well as the FAQ linked to by C Scott) was well thought out in the choice to refuse this patch. Equally well thought out was the reversal of such a decision.

(By well thought out I mean better reasoned than either I personally would have made, or seen in the discussion on this thread. But then again, I'm an engineer, I don't go dictating to product mangers how to design the product or designers how to do UI. Instead I, and I expect the same from my team, to inform product managers and designers as the engineering consequences and costs. I believe if we make decisions that are informed from (but not dictated by) engineering, product, design, data and the community, we end up with a better outcome. Weird as it may sound, I assume good faith on their part and they have yet to let me, or my teams, down.)

> Once VisualEditor is out of 'beta', this preference will be removed.
>
> What you meant to say is that when VE comes out of "beta", you'll post to
> this mailing list again so we can discuss whether the user preference is
> still appropriate. And if it's decided that it's no longer needed, then it
> will be removed.

No. I may be wrong, but I think he said what he meant to say exactly as he said it.

It's a valid interpretation of good faith complaints about the VE rollout. E3 has a opt-out preference against experimental features. To the extent that VE is a beta product, which nobody denies, then it would behoove us to make a similar option available to VE for when VE is in "beta." That reasoning is very sound.

I've read the discussion on this thread, and I found none of it actually addresses the reasoning guiding the VE feature to not allow this preference. Erik has given a long discussion why, from an engineering perspective, a no-op right now would add technical debt in the future and complicate the product roadmap today. James has given a long discussion why, from a product perspective, adding the opt-out would be lying to the users about VE. All of that is nearly identical to the FAQ reposted by Scott. Even James's reversal on the opt-out is consistent with that original reasoning (same reasoning, different outcome).

What I read in direct response to those three e-mails often (not always) consisted of a lot of snark, and a fundamental mistrust of product experts to be experts in…product. I read some data and studies that were linked to that were misused and against specific admonitions by the data analysts (I prefer to think it was an accidental misreading of the studies), I read some discussions that disputed some other data that informed the reasoning that were, while factual, deceptive (e.g. taking page times on huge pages that even the best HTML editors die on). BTW, I do not think any of that was necessarily bad faith, I feel that people here, in their passion of the moment, did not read closely what was being said. I know I've been guilty of selective reading, when I am emotional.

I also read a lot of very good faith complaints and discussion. Some of it was deemed off-topic on a thread that is entirely on-topic for an engineering list. But none of this refuted the actual reasoning and a good amount of it supported it. It did, however, speak to the fact that a preference vs. none is a choice that should be re-examined. A number of my engineers took those good faith issues and lobbied on your behalf for the preference to be added. They lobbied based on the reasoning product used in their original decision.

On Jul 23, 2013, at 12:12 PM, Bartosz Dziewoński <[hidden email]> wrote:

> On a side note, I find it interesting how none of the actual VE and Parsoid developers replied here, apart from Roan, Chris and Subbu on off-topic technical issues (thanks for that).

I am glad that they stuck to actual engineering issues too. With their discipline to stick to engineering, they make me look far better than I deserve as their "manager." And, if you saw their behavior off-list on your behalf, you'd be surprised even more.

I'll take exception to them being "off-topic technical issues" on a mailing list that is [Wikitech-l]. But that's me. :-D

Take care,

terry

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123456