Wikipedia:Requests for comment/Syntax differentiation in editing window

Source: Wikipedia, the free encyclopedia.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Questions posed by this RfC

  1. Should the text editor have a function to color syntax specifically associated with references (i.e. all text within <ref> tags, including tags) so it can be differentiated from other text within the article?
  2. Should this functionality be turned on by default for all users?
  3. Should other forms of syntax be uniquely colored as well (e.g. headers, Wikilinks, infoboxes, etc.)?

Prior discussion

The proposal, in a more basic form, was previously discussed at the village pump per this discussion. A total of 14 editors explicitly supported the proposal and zero editors opposed it. It was also suggested that this be brought to RfC to get a wider response from the community. A unique project page was created because implementation of this function will affect nearly all editors who use the text editor.

Comments from the proposer

The motivation behind this proposal comes from my own participation at The Teahouse, an initiative by the WMF to engage new users in an effective and inviting manner. Many such questions I have encountered there deal with the confusion of trying to get references into articles or how to edit articles with many references in them already (e.g. [1],[2],[3], [4]). The other place I've encountered difficulty in the referencing system is the new user feedback dashboard. This particular proposal actually came from a user who had a bad experience and suggested that it would be incredibly helpful to create a different font color in the text editor for references and regular text.

One other note, there is already a program by Remember the dot (found here) that highlights many different kinds of syntax that could be used for this proposal. However, some editors expressed that its current state would be problematic because 1) It highlights too much text at once and some editors have expressed that this might be confusing, 2) Making changes would require customization of the program, which some (but not all) users would be prepared to do, and 3) The program is only reliably functional in Firefox, and has unreliable or no functionality in other web browsers (see known issues), and 4) Computers with insufficient memory may find editing to be a sluggish task, and when a lot of highlighting is required, the program terminates. Still, I use the syntax highlighter, and to be quite frank, I think it's nothing less than amazing, so I think it can be repurposed or implemented in some form. I, Jethrobot drop me a line (note: not a bot!) 23:33, 20 September 2012 (UTC)[reply]

Differentiating reference text

Rendering reference text in a different color would have multiple benefits for all editors, regardless of their degree of experience with Wikipedia. First, new editors creating a new article who are unfamiliar with reference text would quickly be able to differentiate between explicitly displayed text and reference syntax. Second, new editors who edit existing articles would be able to more quickly parse and identify sections of text-- this would make articles more accessible and less daunting to new editors. Third, for experienced editors who are editing articles with hundreds of references (e.g. Barack Obama), the same idea applies: Parsing through the article, tweaking references, and finding specific sections or sentences would be much easier. Some editors at the village pump discussion also considered that implementing this function may increase editing participation due to ease of use of the editing interface. Furthermore, the function would be implemented as a gadget, and could be turned on and off by individual users under their preferences.

Support: we should differentiate reference text

Lol. Foraging through the jungle of wikitext foliage our fearless hunter spots the reference and aims carefully... --Timeshifter (talk) 05:25, 22 September 2012 (UTC)[reply]

Oppose: we should not differentiate reference text

  • Oppose - It would be fine to add this type of functionality to an existing gadget like wikEd or as a new standalone gadget, but adding this to the default text editing interface would detract from its simplicity. Edit: Furthermore, I have found wikEd to be incompatible with some browsers on some systems, and therefore turn it on/off depending on my needs. Enabling functionalities that may not be compatible with all browsers would just have the opposite of the desired effect upon newcomers and discourage them. —JmaJeremy 21:08, 23 September 2012 (UTC)[reply]
Do you drive a car? Imagine a world with traffic lights which instead of colours, had the words STOP, WAIT, GO. Now imagine a world where traffic lights are red, orange, green.... Kudpung กุดผึ้ง (talk) 23:41, 23 September 2012 (UTC)[reply]
Unfortunately the cost to install those lights results in a road that sometimes flickers between existing and being washed out entirely. -— Isarra 00:20, 24 September 2012 (UTC)[reply]
Somehow I doubt someone (or a group of someones) would force an implementation -- one that would affect pretty much all editors -- that would "wash out" entirely were it to impact a significant number of users. Sure, some bugs might come up, but they already come up with lots of things on Wikipedia and they get dealt with. This perceived fear of something that hasn't even happened yet seems ungrounded to me. Or in metaphor terms, why would someone install a fantastically broken traffic light, if they know it's broken beyond repair? I, Jethrobot drop me a line (note: not a bot!) 00:41, 24 September 2012 (UTC)[reply]
Because their boss threw a tantrum and agreeing to it was the only way to get him to shut up. -— Isarra 04:25, 24 September 2012 (UTC)[reply]
Of course, we could say that about any new addition that has the potential to carry risk to usability. And if that was our response to potential improvements, it's unlikely Wikipedia would have grown at all. But I think if enough people, like you and I'm sure many others on here, care about reduced usability from differentiating syntax, risks can be minimized and prevented. More importantly, the implementation doesn't exist yet. So asserting that it won't work without an actual program is premature. I, Jethrobot drop me a line (note: not a bot!) 04:52, 24 September 2012 (UTC)[reply]
My response is what it has been all along: confusion. Why are people voting to turn on something that hasn't been implemented? This particular part of it I certainly have no objections to, however. There was just this shiny metaphor... -— Isarra 07:32, 24 September 2012 (UTC)[reply]
OK. I think we're just going to have to agree to disagree on this one. I, Jethrobot drop me a line (note: not a bot!) 07:47, 24 September 2012 (UTC)[reply]
Isara, these are the kind of negative approaches and comments that stall RfCs and prevent progress on Wikipedia - I suggest first understanding the use of this feature objectively , and worrying yourself about the implementation later, rather than just voting per 'I don't like it'. Kudpung กุดผึ้ง (talk) 05:15, 24 September 2012 (UTC)[reply]
Out of curiosity, would you also say I were standing in the way of Progress were I pointing out that it is premature to vote on how many unicorns every new user gets because despite the fact that we have consensus to give them unicorns, we don't actually have any unicorns yet? -— Isarra 06:39, 24 September 2012 (UTC)[reply]
I'm saying that participation in RfCs should at least be objective - irrespective of the fact that I think this would be one of the best enhancements to the editing environment at least since my 7 years here. Kudpung กุดผึ้ง (talk) 06:45, 24 September 2012 (UTC)[reply]
Objective is considering all sides of the matter - that includes technical feasibility. -— Isarra 07:32, 24 September 2012 (UTC)[reply]
No, objective is considering the benefits vs disadvantages of the product from the point of view of the editors who would use it, and that is how new ideas at Wikipedia pass from the proposal stage through to final implementation. Whether it is technically feasible or not is not up for discussion here - unless you are on the WMF developer team and you're already looking for reasons to stall the RfC. Kudpung กุดผึ้ง (talk) 09:16, 24 September 2012 (UTC)[reply]
I personally feel a certain skepticism that the colors will prove helpful rather than distracting--most other use of color in thWP is glaring and inappropriate. But it is reasonable to let them be tried DGG ( talk ) 23:28, 25 September 2012 (UTC)[reply]

Discussion of differentiating reference text

Default functionality for all users

Turning on text differentiation for references by default would target newer users who, arguably, would benefit from it most on the basis of accessibility. Newer users may not consider to use it if it is left unchecked as an option under "gadgets" under their preferences. Again, the function could be turned off by any user at any time.

Support: differentiated text for references should be turned on by default

Oppose: differentiated text for references should not be turned on by default

I note elsewhere that you support this as long as it is not default. I don't think this is going to be enabled yet as default in core MediaWiki. It might be enabled as a default gadget. That means both registered and IP users would see highlighted reference wikitext. Registered users would be able to turn it off since it is a gadget. --Timeshifter (talk) 01:58, 24 September 2012 (UTC)[reply]
  • Oppose. There is no implementation yet. How the heck can we decide if it should be turned on by default? What if it causes the editing window to load much more slowly (like wikEd)? What if it doesn't work reliably? This part of the RfC is premature, IMO. Kaldari (talk) 07:03, 29 September 2012 (UTC)[reply]

Discussion of default functionality

  • This isn't going to work. Javascript syntax highlighters never entirely work, and certainly not without side effects, regardless of how brilliant the implementation. As there is no implementation as yet, this vote is at best moot and at worst paving the way for enabling broken functionality, since there is no telling what side effects this will have. -— Isarra 16:00, 21 September 2012 (UTC)[reply]
  • I agree with Isarra. We can get consensus to ask developers to implement this tool without having to decide right now, without seeing the actual implementation, whether to turn it on by default for everyone. If / when the functionality is developed, that can be handled rather simply via another proposal at VPR. No need to rush to a decision on that right now. wctaiwan (talk) 08:30, 24 September 2012 (UTC)[reply]

Differentiating other kinds of syntax

There are other forms of syntax that are fairly pervasive on Wikipedia articles, particularly Wikilinks, infoboxes, headers, and many others. While this question is not intended to immediately extend the proposed function, it opens the idea that this function, with future consensus, could be expanded to fit other kinds of common syntax. Participants who support this idea are free to specify which kinds of syntax might be useful to differentiate under the Discussion header.

Support: we should consider differentiating other kinds of syntax

  • Weak/Conditional Support the key word being "consider". I'm all for a more clear editing interface, and there are a few ways that further differentiation would help. But it really is a case by case basis. Really we should be striving for WYSIWYG because that would maximize the clarity of the syntax in most cases. Shooterwalker (talk) 01:02, 21 September 2012 (UTC)[reply]
  • Support. For the same reasons as I support the other proposals, above. A study should be undertaken to see how to optimise this. It's a highly technical matter; but it should not be left in the hands of the tech-head high-priestly caste, as far too many decisions are for the Wikipedian infrastructure. Editors who frequent WT:MOS, for example, include professionals who are not necessarily coding gurus but who are expert in the design and management of such interfaces. NoeticaTea? 03:41, 21 September 2012 (UTC)[reply]
  • This is worth investigating, even if nothing comes out of it. Syntax highlighting benefits all editors, including those who don't want to put up with the VisualEditor. MER-C 04:35, 21 September 2012 (UTC)[reply]
  • Strongly support: the more syntax is highlighted, the easier editing is. — Dmitrij D. Czarkoff (talktrack) 12:31, 21 September 2012 (UTC)[reply]
  • Support/Comment I use a text editor called Programmer's Notepad in place of the default notepad. This program has various modules for various languages, but one of the amazing features is the pairing of brackets/parenthesis. Each opening bracket is paired with the respective closing bracket as one colour. This would be profoundly useful for editing templates. - Floydian τ ¢ 15:45, 21 September 2012 (UTC)[reply]
  • Strongly support: as I said above, WikEd syntax highlighting is a blessing for new users, and the more we can get that functionality available as a default, the better. It's sad to see a user build up enthusiasm for contributing to Wikipedia, click "edit" on an ordinary article, then be confronted with Infobox syntax and have to scroll through it before they see something they can parse as text. More than just "consider", please. MartinPoulter (talk) 18:01, 23 September 2012 (UTC)[reply]
  • Support as nominator, with reasoning above. I should also note that I've found this to be highly useful using the text highlighting program I discussed at the top of this proposal. I, Jethrobot drop me a line (note: not a bot!) 04:57, 24 September 2012 (UTC)[reply]
  • Support Because this puts us on the slippery slope to the text editor becoming a vim emulation, and that's a good thing.... ;-) GaramondLethe 06:19, 24 September 2012 (UTC)[reply]
You mean Emacs not vim. Why use vi?. :) Bgwhite (talk) 07:32, 24 September 2012 (UTC)[reply]

Support other syntax differentiation, but in a different gadget

Oppose: we should restrict text differentiation to references only

Discussion of differentiating other kinds of syntax

It would be nice to be able to either switch each component independantly, or choose our own colours for each component, with a reasonable default that is sufficient to identify, but not so in your face as to be distracting. Acessability for visually impaired should be considered. Selectable colurs may be sufficient for this purpose. A toggle button that can be flipped while editing might be nice too. • • • Peter (Southwood) (talk): 05:35, 21 September 2012 (UTC)[reply]

Not hugely user friendly, but no matter what you'll be able to change it with a user css file while you are logged in. Gigs (talk) 16:41, 28 September 2012 (UTC)[reply]

Implementation

Can we see the implementation before deciding if we want this on for everyone by default? People appear to have been voting purely on the intent of the thing, which is certainly fine when deciding whether or not to go into development, but it doesn't really get us any further than that since at this point we simply cannot know how it is going to work cross-platform or what side effects it may have, both generally and on more specific subsets of systems.

Mind, if this were something else, that wouldn't be such an issue, but scripts mucking with the text box tend to be buggy by their very nature, not in the least because every browser handles forms and javascript differently, and every OS handles input differently. This is why there are all these wonderful rich text workarounds on other sites that never entirely work as expected, and while this isn't anything that fancy, the inherent problems are the same. That Remember the dot and Cacycle had to come up with rather unexpected workarounds just so the highlighting in their scripts (that syntax highlighter and WikiEd) didn't break browsers' undo/redo is a perfect example of that. -— Isarra 08:08, 21 September 2012 (UTC)[reply]

  • Your concerns are, of course, legitimate, but I doubt any implementation will be available at all without substantial support on this RfC. If this is something like this is requested at bugzilla, it is likely to fall on deaf ears unless there is strong consensus coming from a large number of editors because they say they are strapped for resources. So until that happens, I'm afraid there won't be any specific implementation available to see or test. The only other possibility is finding other individuals on Wikipedia who have the skills to begin making such a function, which I have been trying to do. I, Jethrobot drop me a line (note: not a bot!) 08:16, 21 September 2012 (UTC)[reply]
    That's fine, and a consensus that we want to go forward would be needed regardless; I guess what I'm afraid of is that somewhere down the line someone will take the current discussion on whether or not to turn the theoretical thing on by default and use it to get something tangible and buggy turned on for everyone. Because that sometimes happens. -— Isarra 08:57, 21 September 2012 (UTC)[reply]

Could we get a comment from a developer as to how technically feasible the feature looks to them, especially when combined with existing features? -— Isarra 16:00, 21 September 2012 (UTC)[reply]

  • I'm going to see if I can contact someone from bugzilla to comment here, though I find the interface hard to navigate and difficult to identify someone who might be willing to participate here. Until then, I think it's fair to say that something would not be implemented for all users if it caused major bugs. I imagine it would need to go through alpha and beta testing. I, Jethrobot drop me a line (note: not a bot!) 19:47, 23 September 2012 (UTC)[reply]
    • I wish that were so, but considering what has happened with pending changes, it would seem that major bugs are not necessarily a blocker at all if there is accepted consensus for the concept. -— Isarra 20:47, 23 September 2012 (UTC)[reply]
  • Nobody has posted an example here, so for the benefit of those who have never seen syntax highlighting, here is a simple piece of HTML as seen in a web editor
    . Even if the <ref><ref /> tags were coloured it would be a huge step in the right direction. This RfC is looking for a consensus - it would be inappropriate here to begin discussing the technical implementation here, but I'll hasten to add that this would be an implementation for the benefit of all Wikis. I would guard against asking Bugzilla for input at this stage, let's get a strong consensus for it first. Kudpung กุดผึ้ง (talk) 00:27, 24 September 2012 (UTC)[reply]
Agreed. And for that matter, it seems overly conservative to me to oppose this on the basis of an implementation that doesn't actually exist yet. I, Jethrobot drop me a line (note: not a bot!) 00:34, 24 September 2012 (UTC)[reply]
Thanks for the example, Kudpung. Yes, it should make editing easier. Support. Yopienso (talk) 07:18, 24 September 2012 (UTC)[reply]
Editing with AceWikiEditor.

I'm glad to see syntax highlightening being discussed, as I find it makes working with references a lot easier. Some time ago I wrote together a simple gadget to do syntax highlightning on Norwegian Wikipedia, called AceWikiEditor, since it's using the Ace editor. It's quite rough, and has not been updated for some time, but can be tested using

mw.loader.load('//no.wikipedia.org/w/index.php?title=MediaWiki:Gadget-AceWikiEditor.js&action=raw&ctype=text/javascript&maxage=21600&smaxage=86400');

The idea was stolen from the CodeEditor project. The advantage of this approach is that Ace is well-tested and works across browsers, but on the other hand it does have issues with complex characters, which really makes it a no-go. It's also a unnecessary heavy package to load, so I really like the simplicity of Remember the dot's implementation, and it would be great if we could work towards a stable release enabled by default. One feature that could be borrowed from AceWikiEditor is a toolbar button to enable/disable syntax highlightening. – Danmichaelo (talk) 12:08, 26 September 2012 (UTC)[reply]

I added that to my common.js page, and it's brilliant! It does have a downside: it changed the font and made it smaller, which is really annoying. Still, this looks really good. The color choices could be better, but already it makes editing much easier. :) • Jesse V.(talk) 22:22, 26 September 2012 (UTC)[reply]
Wow! Thanks for mentioning this; it is indeed really cool. GaramondLethe 23:11, 26 September 2012 (UTC)[reply]
Yes, thanks enormously for bringing this into the discussion. I haven't tested it yet, but it proves that it can be done whichever software solution is ultimately developed for it. How we ever lived without it for so many years is an enigma. Kudpung กุดผึ้ง (talk) 02:23, 29 September 2012 (UTC)[reply]
I have used AceWikiEditor for a few days and came away fairly impressed. An issue that definitely needs to be resolved is speed--it takes seconds to load, and if I start typing things before it finishes loading, it would reset the cursor position when it has finished loading, which is undesirable. It also seems to interfere with Firefox's Find feature, which makes it difficult to get to and replace specific text. Generally, it has done a lot to reduce my scepticism, but these are things that should be fixed in final the implementation. wctaiwan (talk) 05:36, 5 October 2012 (UTC)[reply]

References

  1. ^ a detailed reference template
  2. ^ another one
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.