OOjs UI: Dialogs should be repositionable/draggable
Open, StalledPublic

Assigned To
None
Priority
Normal
Author
Ironholds
Blocks
T59437: Allow the VE dialog for math elements to be movable and resizable
Subscribers
01tonythomas, Aklapper, Eloquence and 18 others
Projects
Tokens
"Like" token, awarded by TheDJ.
Security
None
Reference
bz49969
Description

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).

bzimport added a project: OOjs-UI.Via ConduitNov 22 2014, 1:49 AM
bzimport set Reference to bz49969.
Ironholds created this task.Via LegacyJun 21 2013, 4:52 PM
TrevorParscal added a comment.Via ConduitJun 21 2013, 5:28 PM

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.

Ironholds added a comment.Via ConduitJun 21 2013, 5:30 PM

Makes sense.

Jdforrester-WMF added a comment.Via ConduitJun 21 2013, 5:30 PM

(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. :-)

PamD added a comment.Via ConduitJun 30 2013, 9:42 PM

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.)

Ironholds added a comment.Via ConduitJul 15 2013, 9:54 AM

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.

John_Broughton added a comment.Via ConduitJul 27 2013, 11:32 PM

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?

PamD added a comment.Via ConduitAug 2 2013, 7:14 PM

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?

Jdforrester-WMF added a comment.Via ConduitAug 2 2013, 7:44 PM

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. :-(

PamD added a comment.Via ConduitOct 2 2013, 11:19 PM

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.

Jdforrester-WMF added a comment.Via ConduitOct 2 2013, 11:24 PM

(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.

PamD added a comment.Via ConduitOct 23 2013, 10:07 PM

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?

Aklapper added a comment.Via ConduitOct 24 2013, 12:20 AM

Understandable. You will receive a bugmail notification once this bug report is fixed.

Whatamidoing-WMF added a comment.Via ConduitNov 28 2013, 2:17 AM

The change review window is also too small to be useful for some editors, especially if a lot of changes have been made.

Whatamidoing-WMF added a comment.Via ConduitDec 16 2013, 6:00 PM

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.

Jdforrester-WMF added a comment.Via ConduitDec 16 2013, 7:34 PM

Moving to the OOjs UI product as that code is now shared.

Jdforrester-WMF added a comment.Via ConduitJul 16 2014, 1:41 AM
  • Bug 67952 has been marked as a duplicate of this bug. ***
Spinningspark added a comment.Via ConduitAug 11 2014, 12:19 PM

Why is this languishing at low priority? Fixing something that is preventing the editor from reading the thing he is editing is HIGH priority.

Jdforrester-WMF added a comment.Via ConduitAug 11 2014, 3:45 PM

(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.

John_Broughton added a comment.Via ConduitAug 11 2014, 4:58 PM

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?

Spinningspark added a comment.Via ConduitAug 11 2014, 5:12 PM

(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.

Whatamidoing-WMF added a comment.Via ConduitAug 11 2014, 8:05 PM

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".

TrevorParscal added a comment.Via ConduitOct 21 2014, 8:11 PM

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).

Juandev added a comment.Via ConduitOct 26 2014, 3:14 PM

(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?

PamD added a comment.Via ConduitOct 26 2014, 6:15 PM

(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.

matmarex added a comment.Via WebDec 5 2014, 3:10 PM

I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)

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.

I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Here's a rough mockup – note the docking icon on the right. Thoughts?

Ironholds removed a subscriber: Ironholds.Via WebDec 5 2014, 3:17 PM
Spinningspark added a subscriber: matmarex.Via WebDec 5 2014, 3:23 PM

...and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Even if the dialog window is very large, it can still be pushed out of the way by dragging it until it is nearly completely off screen.

matmarex added a comment.Via WebDec 5 2014, 3:24 PM

Indeed, but in this use case you then have to drag it back on-screen to input the category name or whatever.

matmarex edited the task description. (Show Details)Via WebDec 5 2014, 4:06 PM
matmarex set Security to None.
PamD added a comment.Via WebDec 5 2014, 5:07 PM

Looks as if it might work: I don't know the term "dock" but I think you mean what I'd call "minimise"? So click on that icon, the dialog box shrinks to an icon, I read what's behind it: I hope I can copy text from it, eg to fix a DEFAULTSORT? Then click on the icon to restore the dialogue box and carry on. Yes, could be a great solution. Probably better than my original suggestion, many moons ago, of dragging or resizing. Thanks.

Spinningspark added a comment.Via WebDec 5 2014, 5:54 PM
In T51969#821594, @PamD wrote:

I don't know the term "dock" but I think you mean what I'd call "minimise"?

No, dock does not mean the same as minimise. Docking is fixing the dialogue to one edge of the window, rather than plonking a popup in the middle of the window. In the mockup example the dialogue is docked to the bottom of the window. Applications often give the user a choice of which edge they want to dock to, but I don't know if that is what is propsoed here.

For me, this would work if the window could still be scrolled while the dialogue was open, thus uncovering any content hidden by the dialogue (or even off the boundary of the window at the time the dialogue was invoked).

John_Broughton added a comment.Via WebDec 5 2014, 8:32 PM

The discussion is complicated by the unnecessary "Options" menu on the left side of the dialog box. (I believe this is the only place in VE where selecting a choice from a top menu results in a dialog box that shows all the other choices on that menu; that would make sense if an editor were likely to want to do two or three page-related things at once, but in fact he/she almost certainly does *not*.) While redoing the entire approach to how the three-line (should be "Page") menu choices work is probably outside the scope of this topic, I will note that what the requester needs (access to all the text on the page, *while* the dialog is open) is applicable only to two choices - categories and default sort.

For those two menu choices, categories and default sort, I suggest that the dialog attach itself to the right side of the window, taking up 1/3 of the width of the window, and that the left side - the text on the page - be scrollable. (If it's easier to program, then perhaps the dialog should be attached on the left, with the scrolling done on the right.) For the other menu choices, a normal modal dialog box is fine.

Whatamidoing-WMF added a comment.Via WebDec 8 2014, 3:56 AM

Making the dialog one-third the width of the screen is only going to make sense on a desktop system. One third the width of a smartphone screen is not going to be functional (the entire dialog box would be a couple of centimeters wide).

TrevorParscal added a comment.Via WebDec 9 2014, 10:22 PM
In T51969#548465, @PamD wrote:

(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.

I am not saying it's a problem with YOUR workflow, I'm saying it's a problem with the workflow we are providing you. I'm admitting we have failed you, and because we didn't understand how you actually use the software we modeled the workflow around our imagined way you might use the software.

In my view, editing categories should not be a modal experience. The category editor should simply be embedded at the bottom of the page in place of the category listing. If we do anything to try and get the dialog out of the way temporarily, we will still not be able to let you select text behind the dialog without breaking the entire concept of a modal dialog. By placing the category editor at the bottom, you are free to scroll around and select whatever you like. This is the experience you have with the Wikitext editor, and there's no reason we can't continue to provide it.

Jdforrester-WMF added a comment.Via WebDec 10 2014, 1:55 AM

In my view, editing categories should not be a modal experience.

Not necessarily modal. The HotCat gadget that this partially replaces is already effectively-modal too, for instance.

The category editor should simply be embedded at the bottom of the page in place of the category listing.

That's T52239: VisualEditor: Alternative way of editing categories, at the bottom of the page, similar to HotCat.

Jdforrester-WMF added a comment.Via WebDec 10 2014, 1:57 AM

I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)

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.

I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Here's a rough mockup – note the docking icon on the right. Thoughts?

Eurgh. I really don't like the dockable model of modals. It feels like failure. I'd prefer instead that we provide secondary non-modal ways to do things people want to do that isn't modal. As @Whatamidoing-WMF says, this isn't going to work for anyone that doesn't have a huge desktop screen to use.

John_Broughton added a comment.Via WebDec 10 2014, 2:48 AM

I agree that the dockable model is trying to modify something where we might better look for alternatives. For example, one way to create a new category might be to highlight some text, then select (say) Insert > Category. That could open a dialog (for example, to allow a different sort key than the default, and to offer the opportunity to create a category if one being created didn't already exist.

This isn't perfect, of course - if a particular category didn't exist (as text) on the page, the user would have to add it, create the category, then delete the unneeded text. Still, maybe it's better, and at least it's something to think about.

matmarex changed the task status from "Open" to "Stalled".Via WebDec 18 2014, 5:59 PM
matmarex placed this task up for grabs.
Krinkle removed a subscriber: Krinkle.Via WebDec 19 2014, 6:32 PM
TheDJ awarded a token.Via WebFeb 17 2015, 7:33 AM
Eloquence added a subscriber: Eloquence.Via WebFeb 19 2015, 10:57 AM

Add Comment