Talk:VisualEditor/status

"demo"

Hi. About this edit: "Instance" feels jargony and unspecific, and "deployment" is confusing because "deployment" usually refers to the action of deploying software, not the particular instance. I don't really see the problem with the word "demo"; it's the word usually used on software websites for the "instance" of "working code" that lets users test the software's functionality. The Oxford Dictionary gives a similar definition: "demo: a demonstration of the capabilities of something, typically computer software or a musical group". This doesn't seem to conflict with being "working code". Maybe I'm bikeshedding, but "demo" seems unambiguous and specific. guillom 12:56, 1 August 2012 (UTC)

It's a very awkward word (at least, in British English) for this concept. The OED lists as a noun the process-of-demonstration - there is a strong implication of being shown something by someone, not being allowed to use it yourself. Our deployment isn't a guided walk through what it might be, and what we provide isn't a process, it's a static noun. Would "Early version" work for you? Jdforrester (WMF) (talk) 16:36, 1 August 2012 (UTC)

Yes, that sounds like a good compromise :) guillom 17:56, 1 August 2012 (UTC)

Fixed. :-) Jdforrester (WMF) (talk) 18:00, 1 August 2012 (UTC)

How to change an archived status update once it's been posted?

MW 1.22wmf19

In [1], I tried to correct a number of mistakes in the text. I had noted most of these at en-wiki, as requested by Jdforrester, but no action was taken to correct the status page or to indicate where I was wrong (one dev checked some of my conclusions and posted Bugzilla requests for them, which was a good thing to do and indicates that at least some of my concerns or remarks were correct).

My changes were reverted as “trolling”, but despite repeated requests no one could or would argue what was wrong with them (apart from the claim that “I” wasn’t allowed to edit that page for unclear reasons).

So I’ld like to propose my changes here instead.

• "There was no time for basic testing, but we'll let the different Wikipedia language versions do that for us." This is evidenced by the fact that WMF is only now trying to hire a QA tester for VisualEditor, by the fact that basic testing would have found these problems and errors, and by the Engineering goals: "In the next year, we'll build out a whole new function in engineering: community-driven software testing."
• "You can now drag-and-drop some more elements in the same buggy fashion that this was implemented for files - references, reference lists, templates and other "nodes" should all be moveable with the mouse according to the original release text, but in practice only some are, and some aren't." The same bugs that apply to file moving (difficult positioning, positioning in the middle of words, no scrolling beyond the current screen while dragging, …) also apply to template (…) moving. Furthermore, some of the things promised in the status text are not available or not in all circumstances: I have provided evidence that reflists can’t be moved, and that many templates can’t be moved either.
• "Blanking the contents of a heading, pre-formatted block or other formatting block was said to have been improved to delete the block rather than leaving it empty, which is consistent with how OpenOffice and Google Docs behave (bug 50254). But of course, this as well isn't true: blanking the contents of a heading now creates an empty header, but without the nowiki elements. It doesn't delete the block at all." See test at [2].

There may be more errors in the release text, I haven’t tested all of it and some things were not clear to me as to what was supposed to be solved; but of the above three, which ones are completely or partially incorrect, and why? And why can’t the correct bits not be included, before this release reaches most other wikis? Fram (talk) 09:56, 1 October 2013 (UTC)

Hey @Fram: ,

Sorry for not seeing your comment until now. Feel free to use {{ping|Jdforrester (WMF)}} to get my attention if you want me to respond more quickly in future. This is why I didn’t see your comments on the English Wikipedia's technical sub-page of their Village Pump (until your editing here brought them to my attention).

I'm sorry that you feel that we ignored your feedback - it's helpful, though I would agree with others that there are more productive and less confrontational ways that you could have expressed it.

You are right that this page (like all of the /status pages on this wiki) is not very well sign-posted as an archive of announcements. This means that the page shouldn't be retrospectively edited, as it is disrespectful to people who received the original announcement to re-write history. I know that this is standard practice on other wikis too, but it isn't labelled clearly enough here, because most editors of the wiki are 'regulars' who have learnt these local rules over time.

We welcome you continuing to point out any issues you encounter in using VisualEditor (or any of the rest of Wikimedia's deployed code). I understand that you have been very helpful in pointing out several issues and suggesting improvements. Raising issues is most usefully done through Bugzilla, or at the appropriate feedback page on the language Wikipedia you are using. Editing across several wikis makes it very hard to follow what you are trying to highlight, and slowed me from being able to address your concerns until this morning - my apologies.

In terms of feedback you do provide, it is particularly unhelpful to throw around false accusations like "There was no time for basic testing", when what you mean (and would be more constructive) would be a comment along the lines of "I've tried it out and it doesn't work for me". Of course, we do test quite extensively, though are always looking to improve on this. I'd be happy to talk in more detail about our testing strategy for VisualEditor (and I discussed it in our office hours yesterday).

In case you are unaware, we are holding another office hour at 00:00 2 October 2013 (in a few hours' time). Would be happy to see you there if you're available.

Jdforrester (WMF) (talk) 19:08, 1 October 2013 (UTC)

I had written an eloquent reply, and then my computer crashed... Second attempt! @Jdforrester (WMF):

You had, when you posted the status at en-wiki, specifically requested feedback at en:WP:VPT and en:WP:VEF, and I posted feedback at both. I also pinged you a bit later. These were the more productive and less confrontational ways that I tried, but I didn't get any response on those (Qgil of the WMF checked my errors and filed Bugzillas for them, which was good, but no one commented on what to do with an incorrect status report for a release that still had to be deployed to most wiki-versions). I probably should have tried something else then than what I did here, but no one give any indication that they were taking this seriously or where and how I should raise the issues (which were quite urgent considering the Thursday rollout, not something to bury in Bugzilla). So I did it myself, with the known results (including a hard to justify block yesterday and an impossible to justify topic ban and threat with indef block today, for the latter two of which no explanation has been provided).

While "I tried it out and it doesn't work" (the "for me" part is superfluous) is obviously correct, it is hardly sufficient. You (plural, WMF) may have tested this, but then you have done this so badly that the difference between testing and not testing has become negligible. The problems I found were predictable (known bugs for files are now also bugs for templates and the like) and/or very, very easy to find. The toughest part for me was finding a page here with a reflist; once I found one, it was soon clear that the reflist was not movable. On the other hand, the first page I tested here had a template that couldn't be moved, and I found some others on other pages soon afterwards. The "header" problem can be tested on any page, it never works. These were basic elements of the status announcement, not some minor, obscure aspect no one would think of. If you (WMF) communicate that X is solved, and a simple test shows that X isn't solved, and the same applies to Y and Z, then the conclusion "no one has tested this" may be incorrect but is obvious. If you did test this quite extensively, then you did it in the completely wrong manner, and need to seriously reconsider your approach here.

How to proceed now. It is clear that you don't want to change the announcement. On the other hand, you will now deploy this to many wikis, with a list of known problems but an announcement that states that these things work. This will create a lot of extra work, with people testing things, noting them at their local feedback pages, and then perhaps noting that these things were already in Bugzilla before they had received the software update. This will not make people happy, at a time when VE is already controversial and the WMF not very popular (in this regard). So perhaps some interim extra announcement, an errata list, an "updated status report" can be produced, indicating what was wrong with the previous status update, which parts are still correct, and why this cockup has happened. (The other possibility, to delay the update until these issues are solved, is probably too controversial).

Not communicating to the other wikis in some way that your previous status report had multiple rather fundamental errors seems to me to be unaceptable though.

As for the open hours, thanks for the invitation, but I don't like IRC, I prefer to have my discussions on-wiki, and it is too late in the evening for me anyway.

(Note that most of the time, when I am stating "you", I am talking about the plural you of the WMF, the devs, Mediawiki people; not you in person.) Fram (talk) 20:10, 1 October 2013 (UTC)

[ec] @Fram:

You had, when you posted the status at en-wiki, specifically requested feedback […] I also pinged you a bit later.

Yes, and I didn't get around to the ping until after you had edited here; sorry about that.

While "I tried it out and it doesn't work" (the "for me" part is superfluous)

Sorry, this is not actually true, sadly. VisualEditor is a hugely complex system of hundreds of parts, many of which depend on browser behaviours which are (politely) irregular in how they act. Something working in one way in Firefox 22 isn't a reliable indicator that it works that way in Firefox 23, let alone working in Chrome/Opera/Safari. For some aspects, particularly related to keyboard interaction (which is of course critical to VisualEditor), the brokenness of the browser landscape stretches to flavours and versions of operating systems and input methods. I would dearly love for the behaviour of your browser to be identical to that of everyone else's (amongst other things, that would let us un-blacklist Internet Explorer and allow ~ 15% of our users to edit), but sadly the manufacturers of browsers aren't very good at agreeing standards in these areas, let alone sticking to them.

You (plural, WMF) may have tested this, but then you have done this so badly that the difference between testing and not testing has become negligible. […] If you (WMF) communicate that X is solved, and a simple test shows that X isn't solved, and the same applies to Y and Z, then the conclusion "no one has tested this" may be incorrect but is obvious. If you did test this quite extensively, then you did it in the completely wrong manner, and need to seriously reconsider your approach here.

Yes, this is sadly true to an extent. When the team (including me) build and test things before release, we use a number of testing strategies (again, see my comments during Monday's IRC office hours for more detail). However, the "chrome"-y parts of the system - those that affect users most and which are also in some way the most complex - are much less well tested than they should be. I have asked our (relatively) new QA team to work with us to improve this for VisualEditor as a priority, part of which has been the expansion of the team by looking to hire a QA person dedicated to the team, as you noted.

How to proceed now. It is clear that you don't want to change the announcement. On the other hand, you will now deploy this to many wikis, with a list of known problems but an announcement that states that these things work.

Well, sure, but you weren't editing an announcement. You were editing (as the top of the page states) an archive of an announcement that had gone out four days earlier.

So perhaps some interim extra announcement, an errata list, an "updated status report" can be produced, indicating what was wrong with the previous status update, which parts are still correct, and why this cockup has happened. […] Not communicating to the other wikis in some way that your previous status report had multiple rather fundamental errors seems to me to be unaceptable though.

That's a possibility, though because of the drama here and otherwhere I've still not had the necessary two-three hours to go through your comments and work out what you were expecting to happen, what actually happens (and with what browsers), and how my comments as to what was working were either (a) wrong or (b) mis-understood (or a combination of the two, of course).

Jdforrester (WMF) (talk) 23:51, 4 October 2013 (UTC)

We are close to the rollout to the other wikis now. Any updates on if and how the corrections to the status report will be posted? Fram (talk) 14:06, 2 October 2013 (UTC)

@Jdforrester (WMF): Apparently, what was described as being solved with the headers was bug 50100, but the link pointed to the actually solved (more or less) bug, 50254, which only accounts for a small sub-problem of 5010, and isn't really solved anyway. Fram (talk) 09:22, 4 October 2013 (UTC)

@Fram: Yeah, sorry for the confusion caused by my use of "deletes" rather than "clears" (I was trying to simplify the wording, as this gets translated into dozens of languages, and clearly I simplified too far). However, as you can see, I very clearly linked to bug bug 50254 and not bug 50100, which I agree is not fixed, and my poor wording misled you into thinking I was claiming was fixed. Jdforrester (WMF) (talk) 23:55, 4 October 2013 (UTC)

Moving comments out of line so that they are readable. Jdforrester (WMF) (talk) 00:59, 9 October 2013 (UTC)

[A bug for you isn't a bug for everyone]

All my bugs have been confirmed by others, usually quite rapidly. So yes, the "for me" part is superfluous. That it may not be a bug for everyone doesn't mean that it is only a bug for me. I don't use exotic browsers or OS or skin, the problems I encounter are the problems many people will encounter. Fram (talk) 07:21, 7 October 2013 (UTC)

[We should test more]

Thanks. Fram (talk) 07:21, 7 October 2013 (UTC)

[Feedback is sought on the direction of VisualEditor rather than wordsmithing of the announcement]

If there was any indication at all of where this announcement was prepared, discussed, ... or if there had been any indication that the requested feedback had received any attention and lead to any changes in the announcement or follow-up announcements, I shouldn't have searched for where to change this myself. The "archive" is the page linked to from the announcements on en-wiki and elsewhere, and that page just gives "status", which should indicate the current status as currently known. Claiming that it is an archive is really a cop-out: "Here is a copy of the weekly update for the VisualEditor project. This is to make sure you you all have as much opportunity to know what is happening, tell us when we're wrong, and help guide the priorities for development and improvement:" but please don't bother us with any problems in it, we're not going to fix it or communicate the errors in any way or shape. Fine, but then don't expect anyone to read it or take it serious please. Fram (talk) 07:21, 7 October 2013 (UTC)

@Fram: The announcement is written by me, here, in a single edit, and posted immediately. It is not a collaborative process, in the same way that all statements by one participant in a dialog isn't collaborative. Editing others' comments is considered very poor form, and this is, effectively, a comment from me. Feedback is of course taken seriously. You will see that I have altered the text I sling at the top of the text in the latest courtesy post to the English Wikipedia's Village Pump, to clarify this. Jdforrester (WMF) (talk) 00:59, 9 October 2013 (UTC)

@Jdforrester (WMF): Usually, comments are signed. If you had signed the comment, I wouldn't have changed it, but posted my comment after it. On wikis, usually everything that isn't signed is changeable by everyone (excepting user pages basically), and we are usually encouraged to do so. So the "untoucahble" sapect of the status could be made clearer at least. That still doesn't give a solution (or even a hint of a solution) on how to deal with errors, omissions, ... in these status updates. Any thoughts? Fram (talk) 07:51, 9 October 2013 (UTC)

https://meta.wikimedia.org/wiki/Tech/News/2013/40

@Jdforrester (WMF): So, yesterday, [3] is posted to enwiki (and other locatins presumably), containing the same errors (e.g. You can now move [...] list of references"). What's the point of providing feedback if it isn't acted upon, and where does one have to go to get these things changed? Fram (talk) 07:05, 3 October 2013 (UTC)

Archive

This page should not be edited because it is an archive / official statement. Fine, but where does it get prepared? Where can we give input before it becomes official and set in stone for eternity? Fram (talk) 07:07, 3 October 2013 (UTC)

E.g. MediaWiki 1.22/wmf20, which will be posted to all wikis in a few hourst time, is still empty. How is anyone supposed to give feedback to this if it isn't available before being communicated, and can't be changed after being communicated? Fram (talk) 11:21, 3 October 2013 (UTC)

MediaWiki 1.22/wmf20 is created using a script by whomever is deploying, which is usually Reedy. You can just look at the commit history from which it is generated from. For the VE extension, you'd look at [4]. MediaWiki core would be [5]. Legoktm (talk) 18:44, 3 October 2013 (UTC)

Thanks. And the update to the "status" page is just created by Jdforrester or someone from the WMF, without discussion or possibility of changes? Fram (talk) 06:45, 4 October 2013 (UTC)

@Fram: Yes. For clarity, the request for feedback on wikitech-ambassadors (and the English Wikipedia's Village Pump) is not asking "please note errors in this announcement", it's asking for feedback on the subject (i.e., is the team focussing on the things that matter to you?). This is the first time (to my knowledge) that the status update has been a source of confusion or doubt. Jdforrester (WMF) (talk) 00:00, 5 October 2013 (UTC)

"Is the team focussing on the things that matter to you?" No, that's why we had an RfC of which the major requests (opt-in and enabling wikitext) were rejected immediately. With that out of the way: have you ever had any feedback on the status update at all, negative or positive or otherwise, until now? Otherwise, why bother with it? Anyway, let me know when any mechanism for finding and correcting errors in the status updates have been found. I'll not bother testing them until then, there are enough bugs to be found without it. Fram (talk) 07:21, 7 October 2013 (UTC)

2013-11-07

"The supporting code needed for the forthcoming rich pasting was extended further to ensure that corruptions occur" (emphasis mine). Refreshing honesty here, or perhaps that was not really what you intended? :-D Fram (talk) 13:54, 15 November 2013 (UTC) @Jdforrester (WMF):

@Fram:

Fixed

. BTW, the ping template doesn't work if you don't sign the statement in the same edit – I only saw this whilst getting ready to work on the page. Jdforrester (WMF) (talk) 23:07, 21 November 2013 (UTC)

Ah, that sucks. Do you know if this is intentional or some bug? @Jdforrester (WMF): Fram (talk) 10:42, 22 November 2013 (UTC)

@Fram: I believe it's intentional to stop (e.g.) a list of users pinging everyone in the list. But yes, it sucks. Jdforrester (WMF) (talk) 12:54, 22 November 2013 (UTC)

OK, thanks! Fram (talk) 15:31, 22 November 2013 (UTC)

Fram and Jdforrester (WMF), see bugzilla:53132#c16. Helder 14:33, 28 November 2013 (UTC)

@Jdforrester (WMF): In that same update, I read "An incompatibility between VisualEditor and the deployed Parsoid service that prevented editing categories and language links was fixed." I can't judge whether that is true or not, but since it makes no difference whatsoever to editors wanting to edit language links in VE (which didn't work and still doesn't work), I don't think it is wise or useful to add such things; either one incompatability was fixed, but there are still others preventing this, or the incompatibility wasn't fixed, or it had no effect on languages and only on categories. Please make sure that what is communicated in the status updates is tested to assure that it really does what is promised. Fram (talk) 13:32, 28 November 2013 (UTC)

@Fram: Hey, sorry, can't parse your statement – or at least, I think I've got the wrong end of the stick. It appears that you're requesting:

• … for me to only mention fixes that you personally can judge to be true or not;
• … for me to never mention changes you don't care about - a list that clearly includes fixing editing on wikis which don't and won't use Wikidata, but have their own editing of language links; and/or
• … for me to say "BTW we tested this! OMG1one11!" after every statement in the updates, as if that weren't trivially obvious. :-)

… or maybe something else? Apologies for my confusion. Jdforrester (WMF) (talk) 17:49, 2 December 2013 (UTC)

@Jdforrester (WMF): If, after all that has happened, you still believe it is "trivially obvious" that you (devs, WMF) tested things, then I fear that this is hopeless. It is trivially obvious that the testing you do is completely inadequate. But no, I don't want you to say any such thing, I want you to actually do it, so that your status updates more closely reflect reality (remember "switch to wikitext now works!" Oops, not for Firefox...)

And if you believe that this is about Wikidata, then you are wrong as well. There are plenty of articles on enwiki that have "real" language links, using the old, pre-wikidata code. It is impossible to edit these in VE (but not a problem in wikitext) on enwiki. The text of the status update very strongly gave the impression that this was solved. Now, you go on about "fixing editing on wikis which don't use Wikidata", which was not what was said in the status update at all. The problem is not that I don't care about these changes you mention, the problem is that you mention a change I do care about, but that it doesn't work, and that you now claim that that change was not intended for enwiki and most other large wikis, as if that could be understood from the status update in any way.

It is obvious that you don't want any changes, criticism, ... of your precious status updates, but please remove "My job is to help make sure the VisualEditor team understands what the community wants and needs, is focused on the things that matter, and is engaging with and understood by the community." from your user page if this is the kind of response you give. And spare me your fake "apologies", if you really were confused and wanted to have a clarification, you should have communicated that in a completely different way. Fram (talk) 09:19, 3 December 2013 (UTC)

@Fram: I'm sorry regretful that my statement above clearly annoyed you. I'm sorry saddened that instead of saying things constructively like "BTW, editing language links outside of Wikidata is useful too!", to which I might have responded "You're right, bug 52105 about adding the ability to edit via Wikidata is only part of the task, so I've created bug 57929 for this purpose". I'm sorry unhappy that you continue to mis-construe statements I make falsely, and then complain when I point out your misunderstanding. And I'm particularly sorry concerned that you continue to think that making personal remarks at me and others is a helpful way to engage in making VisualEditor better. Jdforrester (WMF) (talk) 16:30, 3 December 2013 (UTC)

@Jdforrester (WMF): Yeah, you're right, your statement with what you thought I requested clearly wasn't a personal remark but a constructive list of good faith suggestions which I mis-construed. Just like your comments on your talk page at enwiki, where you rejected my claims completely, only to be shown that they were correct and your indignation utterly misplaced, were also my fault. You are entirely blameless. I am very sorry. Really. No, really really. Oh well, it was worth a try... Back to the actual business instead of this attempt to sidetrack it?

You still haven't explained what the supposed fix for language links, announced in the 7 November statsu update, was supposed to have fixed. It wasn't for Wikidata language links, and it wasn't for non-Wikidata language links, so perhaps, kindly, inform me of what that statement was about, instead of casting aspersions to my motives and playing the misunderstood martyr. Then, reread my statement about these language links, and tell me, straightforward, what was wrong with it, and where I was right and the status update was wrong (incomplete, unclear, ...). Then perhaps we can have a constructive discussion. You hve filed a new Wikibug, fine, but you haven't indicated which bug was fixed (if any) at the status update. Fram (talk) 20:51, 3 December 2013 (UTC)

Still too hard? @Jdforrester (WMF): "An incompatibility between VisualEditor and the deployed Parsoid service that prevented editing categories and language links was fixed." Please provide an example of something wrt editing language links that didn't work in VE before this fix, and that does work now. Anything, anywhere, on whatever wiki you like. Fram (talk) 10:51, 4 December 2013 (UTC)

Perhaps I can answer for James, and he will correct me if I'm wrong:

There was a problem involving language links. The bug has no immediate effect on the ability of any Wikipedian to edit those links, because editing interlanguage links has been disabled there for other, unrelated reasons. However, it eventually would have prevented that editing, and it did prevent category editing. Fixing this bug was important:

• today to people who edit Wikipedia/Wikimedia sites, and want to change categories,
• eventually to people who edit Wikipedia/Wikimedia sites, and will want to edit interlanguage links, and
• today to people who are not Wikipedia/Wikimedia editors.

Fixing this bug does make interlanguage links editable on some wikis—just not, apparently, on any project that you personally have access to. You will probably never be able to personally verify that this bug was actually fixed, unless you set up your own private, multilingual wiki at home. Whatamidoing (WMF) (talk) 18:57, 4 December 2013 (UTC)

Thanks. Fram (talk) 09:46, 5 December 2013 (UTC)

Considering that there were no private wikis vith VE enabled (since this was only announced as a possibility in the VE newsletter for November), can you give an example of any wiki where this thing actually did make any difference? Otherwise, while for WMF internally it is important that this is fixed, it makes no sense to communicate something externally that no one will see any difference from (the language links, I have no problem with the communication re: categories), but that will confuse the heck out of most people reading this. Fram (talk) 09:50, 5 December 2013 (UTC)

Of course there are private wikis running VisualEditor. Office.wikimedia.org is one such wiki, and it has been running VisualEditor basically since the first day it was possible. Whatamidoing (WMF) (talk) 16:14, 5 December 2013 (UTC)

The text "Support for private wikis: If you maintain a private wiki at home or at work, VisualEditor now supports editing of private wikis, by forwarding the Cookie: HTTP header to Parsoid ($wgVisualEditorParsoidForwardCookies set to true) (bug 44483). (Most private wikis will also need to install Parsoid and node.js, as VisualEditor requires them.)" from the November newsletter gave a different impression. Fram (talk) 08:21, 6 December 2013 (UTC)

@Fram: My apologies for being busy. Whatamidoing (WMF) has it exactly correct. VisualEditor is not deployed just on Wikimedia wikis, and some of the fixes we add don't immediately effect Wikimedia wikis (as well as the reverse). Jdforrester (WMF) (talk) 19:10, 4 December 2013 (UTC)

Then making the status update a bit more complete would help avoid such misunderstandings. Adding the bug number (if any), or indicating where a fix has any effect (in cases where the effect is limited to some small subgroup of all VE deployments) would give a better impression than this "we have fixed interlanguage links" message which turns out to apply only to a small number of people or sites. Remember that this status update also makes it way to the newsletter, where e.g. [6] states the same message: " An incompatibility between VisualEditor and the deployed Parsoid service that prevented editing categories and language links was fixed." Is this Newsletter compiled specifically for en-wiki? Or is it sent to other places as well? It certainly gives people at enwiki the strong impression that language link editing is now possible in VE. People shouldn't be mocked for reporting this. A reply like "Oh, this only applies to wikis of type X, not to wikipedia versions, sorry for the confusion" would have been more than sufficient. Fram (talk) 09:46, 5 December 2013 (UTC)

No, it's not specifically for the English Wikipedia. It is for users who happen to be at the English Wikipedia, and it tends to focus there, but it covers more than the English Wikipedia. That should be pretty obvious if you consider the fact that it mentions things like private wikis, non-English Wikipedias, and Mediawiki.org. Whatamidoing (WMF) (talk) 16:14, 5 December 2013 (UTC)

Good to know. It still would be a good idea in status updates, newsletters, and so on, to indicate which things are general improvements, and which only applies to limited groups, so that people don't have to test everything to see if it applies to them as well. The status update concerning language links gave no indication whatsoever that this was not about either Wikidata language links, or old-style language links, but about something else most people reading the update would have no interest in. Fram (talk) 08:21, 6 December 2013 (UTC)

2013-12-05 (MW 1.23wmf6)

Is it something that happens only to me, or have you really implemented a new version that scrolls to the bottom of the page when opened in VE? Was this intentional or (if I'm allowed to say this) just something that should have been obvious with the most basic test, but somehow wasn't noticed? FF25, W7, nothing fancy or unusual. And no, this didn't happen in earlier versions, and doesn't happen when I use VE on enwiki... Fram (talk) 08:51, 6 December 2013 (UTC)

@Fram: Thanks for spotting this regression in Firefox, now filed as bug 58089 – you're quite right, not sure how this slipped through. :-( We're working on a fix right now and will push it out to MediaWiki (etc.) so that it doesn't impact any production wikis. Jdforrester (WMF) (talk) 19:20, 6 December 2013 (UTC)

@Fram: … and bug 58089 is now fixed in production here; sorry about this, and thank you for spotting it. Jdforrester (WMF) (talk) 00:12, 10 December 2013 (UTC)

Doesn't seem to be the only problem though... If you insert a reference, the cursor doesn't go straight after that ref (or with a space inbetween, which would be ideal), but moves back to the start of the page... You still "see" the new ref as the central point of view, but when you start typing, you do so at the top of the article, not at the ref... Fram (talk) 08:59, 6 December 2013 (UTC)

@Fram: Yeah, this is also a regression (bug 58090), seemingly related to trying to fix the initial selection of the first node in a document on load. We'll also get this one fixed. Jdforrester (WMF) (talk) 19:20, 6 December 2013 (UTC)

@Fram: … and bug 58090 is now fixed in production here (but not in the wmf5 branch that it also appeared in); sorry again. Jdforrester (WMF) (talk) 00:12, 10 December 2013 (UTC)

As for the "rich text pasting", this was my first test, taken from VisualEditor/status#2011-05-16. The result is not really the same...

For my second test, I decided to take a random article section at enwiki, and paste it here (without templates, infoboxes, references, images, just a text section): this is my sandbox vesion here, and en:Gregor Schneider#Life and work is the original. Again, they are clearly different. Please also watch the result at my sandbox in wikitext mode, and compare to the original; these as well are clearly different, with many more short lines after the VE treatment. Fram (talk) 10:37, 6 December 2013 (UTC)

@Fram: The bug with the link appearing wrongly ("[[https://www.mediawiki.org/wiki/User:Trevor_Parscal|Trevor Parscal]]" from your diff, bug 58136) was due to a last-minute change – we've fixed it now in production here. On the topic of your pastes getting huge numbers of erroneous new lines added, I can't reproduce here (on Chrome or Firefox) – what browser are you using? Jdforrester (WMF) (talk) 00:12, 10 December 2013 (UTC)

FF25 on W7. Fram (talk) 09:26, 10 December 2013 (UTC)

@Jdforrester (WMF): So, if these issues are not solved, are you going to release this to other wikis tomorrow and to other wikipedias like enwiki on Thursday or not? I presume from your comment above that you won't, but it isn't really clear to me. Fram (talk) 17:11, 9 December 2013 (UTC)

@Fram: You're correct, were there major bugs like this still present we would have pinned production to the older version of VisualEditor rather than letting it roll out; however, AFAIAA the major bugs have now been addressed (thank you again for highlighting some of them). Jdforrester (WMF) (talk) 00:12, 10 December 2013 (UTC)

2013-12-12 (MW 1.23wmf7) – Incomplete?

...so we want to make it ...? Helder 11:44, 15 December 2013 (UTC)

Not the only problem with the update. The link in the first sentence, "the wider MediaWiki 1.23wmf7 branch deployment", links to /wmf6 instead of /wmf7... And the "o" at the bottom should probably be either an "o-oh" or a "d'oh! ;-).

Anyway, if they want feedback on the toolbar: the most obvious problem with the new "A" is that it doesn't have a "down" button, unlike the other menus. A second issue is that you believe (perhaps correctly) that bolding and so on is used less than linking, then it should be placed further to the right. Fram (talk) 10:47, 16 December 2013 (UTC)

@Helder.wiki and Fram: Unfinished sentence and mis-link fixed, sorry. Jdforrester (WMF) (talk) 19:31, 16 December 2013 (UTC)

I'll pass along the comments.

Relative use isn't the only consideration for position. If people are used to seeing text formatting before linking (and they are, if they use Google Docs, MS Word, or most other word processing software), then this order might make the most sense. Whatamidoing (WMF) (talk) 16:52, 16 December 2013 (UTC)

Perhaps you shouldn't compare with word processing, but with website designing? We are not creating word documents here. In e.g. Word 2010, even the "more" options (images and the like) are shown before linking, and we aren't following that example either... Fram (talk) 18:25, 16 December 2013 (UTC)

Ideally, editors at Wikipedia will be writing encyclopedia articles (which is largely a word processing task), rather than designing websites. Consequently, the devs should be looking at what works in Google Docs, MS Word, Apple Pages, and similar word processing software (and above all, what works well and what works poorly in the wikitext editor), rather than what people do with Google Sites, Dreamweaver, and similar web design software.

As I said, "relative use isn't the only consideration" (emphasis added). Relative use is one consideration, but there are other valid and relevant considerations. What people are accustomed to from similar software is another consideration. Neither of these, nor any of the other considerations, is a trump card. The devs are not cloning Word 2010's toolbar merely because a fraction of our users is accustomed to that. Word 2010's toolbar may work well for the average Word user, but what editors do in Wikipedia articles is different from what the average user of a word processor does. For example, VisualEditor needs to emphasize linking because the typical developed Wikipedia article contains dozens, and sometimes hundreds, of links. By contrast, Word does not, and probably should not, emphasize linking as much, because the average MS Word document contains only zero or one links. It would not make sense to exactly copy the design from a product that is optimized for a somewhat different type of composition. Whatamidoing (WMF) (talk) 19:19, 16 December 2013 (UTC)

I think it would be best to simply look at what makes the most sense for Wikipedia editing, without making it deliberately complicated of course. Looking at existing software is not useless, but taking it into consideration too strictly limits us too much. Fram (talk) 20:50, 16 December 2013 (UTC)

Basically I agree, therefore I like this shrinking of all character-level formatting into one button. I would propose to do the same for lists and indent: put all 4 of them behind the same button. If possible, make the button act as one of them (configurable per wiki, by default "bullet list" which seems used most by far) and an arrow next to is opening the menu with all 4 possibilities. This would free up more space on the toolbar, which I would strongly suggest to use for direct access to the Language and Transclusion functions. At least the latter would eventually become a menu, to be configured on a per-wiki basis, with e.g. up to 8 or 12 often used templates directly accessible (e.g. on WP:fr we use templates to properly format numbers with units, centuries, etc. We cannot expect anyone going through the full Transclusion interface as it exists now to do this tens of times per page).

By the way, I notice that the Language functionality generates HTML directly: I hope that this is a bug? Although the implemented HTML code corresponds to what is currently done in most wikis, this VE Language functionality should generate wikitext instead, to respect the specificities implemented on some wikis (e.g. look at the Lang template on WP:fr which provides more functionality than the corresponding template on WP:en). As a conclusion, 1.23wmf7 implements a welcome move and I hope the concept will be extended to match specific requirements of the various wikis instead of those of just a few of them ! Klipe (talk) 09:30, 17 December 2013 (UTC)

@Klipe: Thanks for your feedback. Some quick thoughts –

• I agree that we should demote the four structure items (eventually to be a few more, e.g. tables and definition lists) to a single button with a menu. Having the menu also be a button (in this case, the bulleted list item) seems like it could be a little confusing. We should experiment and see what works. This was going to originally part of the change, but I wasn't happy with the original concept for the icon, so we held it back.
• Yes, we should make the menus in the toolbar consistent – I think the icon with a small down-arrow on the side is a reasonable action for the text style menu to make it more consistent with the "Insert" menu, and the structure menu should do the same.
• I disagree that the formatting menu ("Paragraph v") is the same kind of tool as "make this bold" or "indent this list" – if the cursor is on a blank line, you don't necessarily know if it's going to be a sub-heading 2 or a sub-heading 1 until you type, and you probably want to know at a glance.
• We are planning to promote inserting a reference (which is a very common task) onto the toolbar, with a drop-down menu to insert a reference with one of a few (local sysop selected) citation templates; I was going to put this next to the link button (ahead of all the other insertion buttons).
• Doing the same for transclusions – having them promoted to the toolbar with a quick-insert menu of common templates or other transclusions – could be a good way to achieve the same effect, though there are questions about how much we want to encourage template abuse. :-)
• I am not sure that we should promote the Language tool to the toolbar, as on many wikis it is only very rarely used. Of course, this is a bit of a chicken-and-egg situation – if we put it on the main toolbar, it will definitely get used more. Is that a good thing to encourage, given that it makes wikitext more complicated for non-VisualEditor users?
• The language inspector inserts HTML attributes like is used on many of the wikis that particularly asked for this, because there is no standard wikitext form. Inserting different wikitext for different wikis would be very confusing for users and make the system complex and slow. Theoretically we could introduce (yet) another wikitext syntax that re-implements the "lang" template, but that would be adding more complexity for everyone. This probably is worth waiting for global templates to allow us to expect and use the "lang" template as needed.

Thanks again. Jdforrester (WMF) (talk) 20:11, 17 December 2013 (UTC)

Archive

James, this page is well above the size that some readers can load. Have you considered archiving it and starting afresh in the new year? Whatamidoing (WMF) (talk) 23:44, 17 December 2014 (UTC)

@Whatamidoing (WMF): Unfortunately we can't ever archive this page without breaking how MediaWiki.org tracks projects' updates. :-( We've been talking about exploring the use of Phabricator for these release notes instead, but that functionality isn't switched on yet for me to test (and the Phabricator team are rather busy with more important things). Jdforrester (WMF) (talk) 18:43, 18 December 2014 (UTC)

Recent updates

VE has its own roadmap page, maintained by James. The last q review was in April, although from now on linking them won't make so much sense, since they have become so high-level. --Elitre (WMF) (talk) 11:43, 24 April 2015 (UTC)