VisualEditor: When user types in '[[' in the page or another DOM input widget, pop up a reminder that they're using VisualEditor
Closed, ResolvedPublic

Description

When a user inserts [[links]] or {{templates}}, VisualEditor automatically wraps them into <nowiki> tags. Experienced contributors who are very used to using this syntax sometimes add it inadvertently.

It would be a nice touch to show an unobtrusive warning to remind users that they need to use VisualEditor's menu to insert links, templates & other wikisyntax. LiquidThreads does this well when users insert their signature manually with ~~~ into their post


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49686
https://bugzilla.wikimedia.org/show_bug.cgi?id=50527
https://bugzilla.wikimedia.org/show_bug.cgi?id=50601

bzimport set Reference to bz49820.
gpaumier created this task.Via LegacyJun 19 2013, 2:20 PM
Thryduulf added a comment.Via ConduitJul 3 2013, 9:33 AM

Why is this marked low priority? It is causing problems on the live wiki with people unable to figure out why their edit has not worked - the VE hides the nowiki tags it has inserted so its impossible to determine the cause unless one knows about this feature (which I've not seen in documentation) or uses the misnamed edit source.

Ironholds added a comment.Via ConduitJul 3 2013, 9:43 AM

"What Chris said". I'd like to know the rationale for the priority rating on this; it's the biggest source of article corruption.

Ironholds added a comment.Via ConduitJul 3 2013, 1:46 PM

*** Bug 50581 has been marked as a duplicate of this bug. ***

Soni added a comment.Via ConduitJul 3 2013, 2:39 PM

I have already suggested bug 50527 as a possible solution to this problem. An automatic tag and then manual correction would be a simple-to-implement interim measure, if not long term.

TheDJ added a comment.Via ConduitJul 3 2013, 7:02 PM

And bug 50093 for an alternative [[ suggestion.

Eloquence added a comment.Via ConduitJul 5 2013, 1:03 AM

A permanently dismissible first-use reminder may be sufficient. I suggest we try that and see if it significantly reduces incidents of wikitext insertion. See bug 50601 for discussion.

gpaumier added a comment.Via ConduitJul 12 2013, 7:17 PM

(In reply to comment #6)

A permanently dismissible first-use reminder may be sufficient. I suggest we
try that and see if it significantly reduces incidents of wikitext insertion.
See bug 50601 for discussion.

Habits die hard. When you've been entering wikitext manually for the past 12 years, it's _really_ hard to change your habits. I really doubt a "first-use reminder" will be enough; I still expect people to add [[ inside VisualEditor in 5 years. All drivers learn what the speed limits are before they get their driving license, but there are still speed limit signs on the roads :)

A guided tour is indeed a great idea, but _in addition_ to an always-shown-when-wikitext-is-detected warning, not as a replacement, imho.

John_Broughton added a comment.Via ConduitJul 12 2013, 8:58 PM

(In reply to comment #4)

I have already suggested bug 50527 as a possible solution to this problem. An
automatic tag and then manual correction would be a simple-to-implement
interim
measure, if not long term.

Bug 50527 proposes that the edit go through, WITHOUT warning the editor of his/her mistake; instead, the edit summary gets a tag showing that a problem exists with the *completed* edit. Given that the software can detect this error, it makes more sense to give the editor who made the mistake a chance to fix it *before* the edit is completed - ideally, not to allow the edit to be completed with the error intact within in. That way, (a) the editor is more likely not to make the mistake again, and (b) if the editor who made the mistake fixes it before finalizing his/her edit, there is no need for a second (corrective) edit (and no need for someone to be monitoring recent changes for the tag proposed in bug 50527).

bzimport added a comment.Via ConduitJul 14 2013, 11:30 PM

ignatzmice.wiki wrote:

(In reply to comment #7)

(In reply to comment #6)
> A permanently dismissible first-use reminder may be sufficient. I suggest we
> try that and see if it significantly reduces incidents of wikitext insertion.
> See bug 50601 for discussion.

Habits die hard. When you've been entering wikitext manually for the past 12
years, it's _really_ hard to change your habits. I really doubt a "first-use
reminder" will be enough.

Yes, this. I recognized the problem first time I did it, and it still happens.

gerritbot added a comment.Via ConduitJul 15 2013, 2:21 AM

Change 73569 had a related patch set uploaded by Catrope:
Warn users when they are typing wikitext

https://gerrit.wikimedia.org/r/73569

gerritbot added a comment.Via ConduitJul 15 2013, 2:30 AM

Change 73569 merged by jenkins-bot:
Warn users when they are typing wikitext

https://gerrit.wikimedia.org/r/73569

Jdforrester-WMF added a comment.Via ConduitJul 15 2013, 2:31 AM

Feature to do this is now merged and will be deployed tomorrow.

bzimport added a comment.Via ConduitJul 16 2013, 4:39 AM

pearley wrote:

Just tried this out - seems to be an issue. If you are scrolled down far enough on an article, the warning is never seen. It's tied to the top of the page. You can go all the way through the save process and only see the message once the new version loads. I suspect this might be reducing the effectiveness of the notice. (FF 22, OS 10.6.8)

bzimport added a comment.Via ConduitJul 16 2013, 4:49 AM

ignatzmice.wiki wrote:

The little box is not nearly obtrusive enough. It should be a popup (like the "are you sure you want to thank this user?" popup) that says the same thing as the warning, but requires confirmation (even a sole "OK" button would be fine, so long as it actually disrupts the editor's typing).

Jalexander added a comment.Via ConduitJul 16 2013, 5:06 AM

I'm reopening this as it seems to be the best place. There is definitely an issue with the warning being only on top and so you really don't have to be scrolled down that much before you don't see the warning.

TTO added a comment.Via ConduitJul 16 2013, 6:36 AM

Actually this is a general problem with jsMessages is general. They should be placed at a fixed position on the page.

Esanders added a comment.Via ConduitJul 16 2013, 11:11 AM

Created MW bug for position fixed. Due to the possibility of false positives, having a blocking confirmation box may be too obtrusive.

Esanders added a comment.Via ConduitJul 16 2013, 11:12 AM

Depends on bug 51432

bzimport added a comment.Via ConduitJul 16 2013, 11:26 AM

ignatzmice.wiki wrote:

(In reply to comment #18)

Created MW bug for position fixed. Due to the possibility of false positives,
having a blocking confirmation box may be too obtrusive.

I dunno. I don't see a lot of false positives coming out of Filter 550. If you're really concerned, there could be a setting in the VE prefs to turn it off. (I definitely would NOT want a "don't show again" in the popup itself—too easy to get rid of it without clearly understanding what it means.)

He7d3r added a comment.Via ConduitJul 16 2013, 1:00 PM

What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?) pointing exactly to the position where the wikitext was found?

bzimport added a comment.Via ConduitJul 16 2013, 1:09 PM

ignatzmice.wiki wrote:

(In reply to comment #21)

What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?)
pointing exactly to the position where the wikitext was found?

That might work pretty well too, especially if the balloon is a prominently "warning" color (as suggested somewhere by someone). I personally would be in favor of a big in-your-face notification, but I accept that not everyone will.

matmarex added a comment.Via ConduitJul 16 2013, 1:45 PM

(In reply to comment #19)

Depends on bug 51432

This was already reported as bug 50870, adjusting.

bzimport added a comment.Via ConduitJul 16 2013, 4:43 PM

kwwilliams wrote:

The continued flow of markup errors shown by http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 is a pretty good indication that the warning either isn't obtrusive enough or clear enough. We're still seeing about 20 articles an hour corrupted because of this.

I think this really needs a positive checkoff dialog, and the article shouldn't be saved until the editor has agreed that he really wants strings of brackets and pipes in his text. Having these in legitimately is an extremely rare case, especially for a novice editor. I'd block the edit with the edit filter if I could, but VE isn't able to display edit filter messages properly.

He7d3r added a comment.Via ConduitJul 16 2013, 5:22 PM

Another possibility: provide a side by side view of the two options the user has, and ask for confirmation:
https://en.wikipedia.org/w/index.php?oldid=564535137#bug49820

Kipod added a comment.Via ConduitJul 25 2013, 10:55 PM

(In reply to comment #24)

The continued flow of markup errors shown by
http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550
is a pretty good indication that the warning either isn't obtrusive enough or
clear enough. We're still seeing about 20 articles an hour corrupted because
of
this.

there was a problem with the message (it opened at top of page instead of top of screen), because of bug 50870. since this bug is fixed, the message will become more effective (afaik, this fix was deployed on July 22).

personally, i think that the right solution is outlined in bug 51897. however, ATM 51897 is marked as "low". if you think like i do, maybe you should lobby to bump up the priority of 51897.

peace.

John_Broughton added a comment.Via ConduitJul 25 2013, 11:13 PM

If it's not one thing, it's another ... The popup message is now visible no matter where in a page the wikitext is being entered. So that's progress.

The popup is still too inconspicuous for my tastes (and a great opportunity for A/B testing), but that's not what I'm posting about. My concern is with the link that the popup message includes (the label is "wikitext"; the target is [[Help:Wiki markup]]). If that link is clicked, the system asks the user whether he/she wants to leave the editing page. That's a bit user-unfriendly.

I realize that smarter users can right-click and then open the link in either another tab or a new page, avoiding the question of whether they want to leave their editing session. But if we're aiming at the average user, it would be great if this link were pre-defined as opening another window, so that a simple click on the link didn't result in a perturbed user.

gerritbot added a comment.Via ConduitJul 30 2013, 10:28 AM

Change 76701 had a related patch set uploaded by Esanders:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701

Esanders added a comment.Via ConduitJul 30 2013, 10:39 AM

(In reply to comment #27)

If it's not one thing, it's another ...

Welcome to software development.

He7d3r added a comment.Via ConduitJul 30 2013, 1:12 PM

(In reply to comment #27)
...

I realize that smarter users can right-click and then open the link in either
another tab or a new page, avoiding the question of whether they want to
leave
their editing session. But if we're aiming at the average user, it would be
great if this link were pre-defined as opening another window, so that a
simple
click on the link didn't result in a perturbed user.

Reported on bug 52093.

gerritbot added a comment.Via ConduitJul 30 2013, 4:24 PM

Change 76701 merged by jenkins-bot:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701

Jdforrester-WMF added a comment.Via ConduitJul 30 2013, 4:55 PM

The issue that caused this to be reopened (bug 52093) has been fixed and will be deployed soon; consequently, reclosing this.

Mattflaschen removed a subscriber: Mattflaschen.Via WebDec 3 2014, 5:37 AM

Add Comment