Last modified: 2014-11-17 11:07:20 UTC
Quoth requester: If I can't read the article, because the "page settings" box is large and un-draggable and hides all the article, how can I see what defaultsort or categories I want to add (especially as for defaultsort I probably want to copy and paste all or part of the article title).
The idea of the dialog being modal is that you aren't multi-tasking with it at all. As far as adding a category or changing the default sort of a category directly from some other mode (such as reading, or editing paragraph text) we should look at those workflows rather than dissolve the intentional model-ness of the dialog. For example: - Perhaps categories could be edited at the bottom of the page, rather than inside a dialog. - Maybe the category editor could use some other kind of UI container that isn't modal. etc.
Makes sense.
(In reply to comment #1) > The idea of the dialog being modal is that you aren't multi-tasking with it > at all. This isn't asking for multi-tasking, it's asking for the ability to drag the dialog out of the way so that you can get context for the single-tasking, err, task. :-)
If I want to add "Category:1917 births" and "Category 1987 deaths" to an article, is it undesirable multitasking to expect to be able to see the lead sentence which says "'''Joe Bloggs (1917-1987)...", rather than having to remember the two dates? Or if I want to assign "Category:Villages in ..." for some area whose placenames are unfamiliar and have difficult spellings? Please let me see the article while adding categories: a simple way would be to let me drag, or shrink, the dialogue box which at present totally obscures the article text. (I was the original reporter of this bug on 21 June, and the response above seems to misunderstand its importance.)
Any movement on this? Low-priority according to the development team, I accept, but it's a pretty important chunk of the editing workflow for a lot of tasks.
How hard is it to make the dialog box moveable? Really? There is what, one parameter that needs to be changed? If this were a really hard problem, it would be understandable that the VE team was deferring this for more important things. But it's not that hard (I hope; if so, that bodes poorly for VE), and it impacts LOTS of editors. Yes, it affects the dialog box for page settings, when doing categories. But there is the identical problem when adding a caption for an image (Media settings dialog; might want to know how something in the article is spelled) and possibly for the other dialog boxes (for example, in the Media dialog, searching for an image where the search term has an unusual spelling). Even better would be the ability to copy/paste from the main editing window to a field in the dialog box. I realize that has potential ramifications for loss of focus - it would be undesirable for the dialog box to disappear *behind* the main editing window. Still, in Mac OS X, the "Force Quit Applications" dialog box is moveable, and the user is able to copy text from other windows, but the dialog box remains on top of every window until it is closed. (Excessive, actually: the ideal is to have the VE dialog box float on top of the main editing window, ONLY.) But we (as in, Wikipedia editors) would settle for a really minimal solution, initially - just make the dialog boxes moveable. Please?
Six weeks on from first request it's depressing to see this is still "low enhancement". Example: stub-sorting a Russian icehockey player, I open the dialog box to remove the existing stub tag and then go to the dropdown menu to add "Russia-icehockey-bio-stub", only to discover that there are separate stubs for wingers, goalies, etc. I didn't notice what he was. I have to quit the dialog box, find he's a winger, re-open it, re-delete the old stub, return to the dropdown menu to add the new stub template. The inability to move or shrink the dialogue box makes ordinary routine wikignoming harder work. But I suppose the target market of newbies don't do things like that, and we established editors can be trusted to struggle on regardless (some of us, perhaps a diminishing number), however ignored our needs may be? Yes, I could abandon VE and this wouldn't trouble me any more, but I'm trying to help by persevering in using it to help you debug it. In return, how about a little attention to one of the first issues I raised?
Prioritisation of work is done on how much it interferes with people using the software, not how long ago it was first mentioned as an issue. For example, bug 4 (!) is from 2004. I'm sorry that this is getting in the way of your use of VisualEditor, but I think that adding copy and paste support (for example) should happen first. I could "upgrade" the importance of this to "high" but it wouldn't get the code written any faster. :-(
Two months since there's been any comment on this ... I admit I've pretty much given up using VE (too tedious because of this and other problems, plus some stuff going on in Real Life which makes me want to reduce Wikistress). Any chance of it getting fixed some time? I'm sure I'm not the only person affected.
(In reply to comment #9) > Two months since there's been any comment on this ... I admit I've pretty > much > given up using VE (too tedious because of this and other problems, plus some > stuff going on in Real Life which makes me want to reduce Wikistress). Any > chance of it getting fixed some time? I'm sure I'm not the only person > affected. Some time? Yes. Soon? No. In my view, it's not as important as fixing things like copy-and-paste or adding citation template quick-add support or editing tables.
Let me know when this is fixed, because I'm not going to stress myself by using VE until then - it just makes my everyday editing too much like hard work. When it's fixed (and perhaps a few more of my long-standing complaints - hidden comments, red links appearing as red, etc), I might carry on with debugging your system. Till then, why should I bother?
Understandable. You will receive a bugmail notification once this bug report is fixed.
The change review window is also too small to be useful for some editors, especially if a lot of changes have been made.
Please see https://upload.wikimedia.org/wikipedia/commons/d/d9/Wide_edit_window_%28Proposal_for_Wikimedia_VisualEditor%29.png for an example of what a wide window might look like for reviewing changes.
Moving to the OOjs UI product as that code is now shared.
*** Bug 67952 has been marked as a duplicate of this bug. ***
Why is this languishing at low priority? Fixing something that is preventing the editor from reading the thing he is editing is HIGH priority.
(In reply to Spinningspark from comment #17) > Why is this languishing at low priority? Fixing something that is preventing > the editor from reading the thing he is editing is HIGH priority. "High" priority would mean that it's more important than editing tables, editing in Chinese, or editing galleries. "High" priority is not appropriate for this relatively minor and very complex enhancement request.
Just to be clear, this is a DESIGN TEAM problem, because it's a problem with the OOjs UI, which VE uses, but which is under the control of the Design team. The issue is that the OOjs UI WindowManager lacks a resizing event. That issue affects every use of windows in the OOjs UI, not just VE's use of windows. Why isn't this bug showing on the list of problems that the Design Team is considering (https://bugzilla.wikimedia.org/buglist.cgi?keywords=design&keywords_type=allwords&list_id=335932&order=changeddate%20DESC%2Cvotes%20DESC%2Cpriority%2Cbug_status%20DESC%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=--- )? (I got that list via https://www.mediawiki.org/wiki/Design ) Relatedly, why is the priority for fixing this bug being set by the VE team, rather than by the Design team?
(In reply to James Forrester from comment #18) > (In reply to Spinningspark from comment #17) > > Why is this languishing at low priority? Fixing something that is preventing > > the editor from reading the thing he is editing is HIGH priority. > > "High" priority would mean that it's more important than editing tables, > editing in Chinese, or editing galleries. "High" priority is not appropriate > for this relatively minor and very complex enhancement request. You can't edit anything, tables, Chinese or galleries, if there is big immovable box in the way.
> You can't edit anything, tables, Chinese or galleries, > if there is big immovable box in the way. This isn't really true: you can close the box. With the box open (and movable), you can *see* the content on the page, but you still can't edit it. When you've got a dialog box open, but all your typing ends up on the page underneath the box, then we call that a bug. The problem here is that (depending on the size of the box and the exact location of your cursor when you open it), what you need to *see* on the page might be covered up by the box. "Open box, realize that you've forgotten how to spell something, realize that the box is covering up that word, close box, check spelling, open box again, finally type" is not as efficient as "Open box, drag it out of the way, start typing".
I would like to avoid adding moving and resizing to dialogs, because I believe it solving the problem in the wrong way. At it's root, this is a workflow problem. Making the dialog resizable and movable does not adequately address it. More of these processes should be non-modal, especially authoring edit summaries. This would allow users to contribute to edit summaries as they work, rather than having to write them at the very end, when the changes they've made are so temporally distant. Even if the dialog is movable an resizable and movable, the contents below are only visible through a semi-opaque mask and the contents cannot be scrolled because the modal dialog is capturing events (on purpose, it's modal).
(In reply to Trevor Parscal from comment #22) > I would like to avoid adding moving and resizing to dialogs, because I > believe it solving the problem in the wrong way. At it's root, this is a > workflow problem. Making the dialog resizable and movable does not > adequately address it. > > More of these processes should be non-modal, especially authoring edit > summaries. This would allow users to contribute to edit summaries as they > work, rather than having to write them at the very end, when the changes > they've made are so temporally distant. > > Even if the dialog is movable an resizable and movable, the contents below > are only visible through a semi-opaque mask and the contents cannot be > scrolled because the modal dialog is capturing events (on purpose, it's > modal). This is a good point, but I dont think, its related to this enhencment. You are right, that if I am doing a lot of different changes and/or editing the article several minutes, I forgot, what I was doing. But how this problem is related to the fact, I cannost drag the DW avay to see what is behind?
(In reply to Trevor Parscal from comment #22) > I would like to avoid adding moving and resizing to dialogs, because I > believe it solving the problem in the wrong way. At it's root, this is a > workflow problem. Making the dialog resizable and movable does not > adequately address it. > >.... You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable. If I want to add a stub template for a Russian footballer, and then discover that not only do I need {{Russia-footy-defender-stub}} but that it's subdivided by date of birth, I need to be able to look at the article and find his date of birth to use {{Russia-footy-defender-1960s-stub}}. If I want to add a defaultsort, I need to be able to copy the surname, and then the forename, from the text of the article. How should I adjust my workflow? For the foreseeable future, I've adjusted my workflow by abandoning any attempt to use VE as it makes my editing too difficult.
