Page MenuHomePhabricator

Create a draggable dialog window for Codex
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):

I was kind of surprised to learn this was not reported before, so reporting it now. Dialog windows in Codex should be draggable and should probably be draggable by default on large screens (probably not on mobile).

See also T434355 for making non-modal dialog windows.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

  • Gadgets for taking notes (and needing to copy something to the window). Here it might also be important to be able to move away the window, so that notes can be to the side of edit window, or to copy text from below the window.
  • Checking refs in the editor (and needing to be able to interact with the editor below the window). Default gadget on plwiki for refs. Again might need to not only be non-modal, but might neeed to move a way the window to one side or the other.
  • Write about current article when submitting a nomination (for deletion, for a medal, for did-you-know column). This window is big, so moving the window is especially important.

Benefits (why should this be implemented?):

Good for active editors and other power users who still use PCs daily. Note that on PCs (and Macs), most windows are actually non-modal. Also note that while readers tend to use mobile devices, active editors still tend to use desktop computers or laptops to edit Wikipedia.

For example, at the moment I see 73 mobile edits out of 500 actions (486 edits in total) on enwiki on RC (link below). That is about 15% mobile edits and 85% other edits (taking 486 as 100%). It is a random sample, but this is also what I hear from active editors at conferences: people do make edits and perform other actions on mobile, but these are relatively rare – typically when waiting for a train, etc., or when there are no other options for them. Most of the time active users use a larger screen on which windows are not taking the whole screen.

https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&limit=500&days=14&urlversion=2

Event Timeline

Here is a solution I landed on in my workaround for diaggable windows:
https://pl.wikipedia.org/w/index.php?title=MediaWiki:Gadget-SimpleDragDialog.js&oldid=79642176#L-117

I'm using window.innerWidth < 420 as the mobile threshold. Below this width, window maximization is disabled and the window is stretched to both sides of the browser window/screen.

This seems to be about Codex, thus adding the Codex project tag

I'm pretty much like T434144#12196588 - you listed some situations above (thanks!); it's unclear to me if in these situations, the initial position of whatever a 'dialog' currently shows could already be improved, so moving a dialog window should not be needed anymore.
Asking as I've seen many modern applications move away from draggable/moveable dialogs as they can get in the way when interacting with the content displayed in the application itself. Instead such dialogs have been moved to static positions like a bottom bar, or in a top right position in LTR context.
But I can also understand that this is a quite different UX interaction concept which may not fit here.

I'm pretty much like T434144#12196588 - you listed some situations above (thanks!); it's unclear to me if in these situations, the initial position of whatever a 'dialog' currently shows could already be improved, so moving a dialog window should not be needed anymore.
Asking as I've seen many modern applications move away from draggable/moveable dialogs as they can get in the way when interacting with the content displayed in the application itself. Instead such dialogs have been moved to static positions like a bottom bar, or in a top right position in LTR context.

Yes, this is more or less what we do for Cat-a-lot. Cat-a-lot floats in the bottom-right corner, and you can minimize it to the title bar. There are many problems with that, though.

  1. Skins: you cannot be sure that a particular edge is free of other elements from the skin.
  2. Other gadgets: you cannot be sure that other gadgets are not already using that edge. Obviously, elements overlapping each other, especially position:fixed elements, are problematic.
  3. Implementation: all gadgets need to implement this on their own, which is less efficient. We, as the Wikimedia movement, do not have that many JS devs, and even fewer very good and dedicated JS devs. There are still problems with gadgets not being fixed after changes to icon sizes (T414805), I mean I just fixed one this week.

So some central management of minimization might be required. I guess that is yet another request: T434359.

Also, if you want to enhance editing, you cannot (or should not) place a form inside another form, as this can cause problems with validation and other weird interactions. For example, resetting a form might reset more fields than you intended. That is the reason I couldn't put refToolbar above the main textarea of the editor. There are also many different editors (WikEd, CodeMirror, the VE-based 2017 wikitext editor, etc.) and there might no element which you can use as an anchor or container to your gadget's form...

So even if putting a form in one fixed place would be better than putting the form in a draggable dialog, it is not really feasible when you want to support various editors and skins, and thus support many editors in their work.

Draggable dialogs would be useful for my mass redirect creator gadget. Sometimes the page intro contains aliases for the page title, but there are no redirects with those names. In that case, I open the gadget to create the redirects, but because I can't move the dialog, I can't see the article text underneath it to check the aliases.

image.png (993×753 px, 138 KB)

Very important feature.
Gadgets with dialogs but for interacting with content needs ability to return to the content or even interact with it. There is no reason to block using what is back the window.
The reason to implement this in main code is because it can be useful in multiple gadgets and not re-invent the wheel.