4.0.0 internal playlist drag and drop behavior

[freakingmayhem]

Hi Ian (and/or whomever). I'm curious if you think the internal playlist drag and drop behavior carried over from 3.8.5 still makes sense in 4.0.0, now that the real-time visual indicator of dragging and dropping is gone.

The behavior made perfect sense pre-4.0.0 because you would watch the dragged items slide up or down in real time, (anchored by the specific item that was clicked) and you could visually process how it was displacing the index as it went. I don't personally feel like this logic works anymore in 4.0.0 without the visual feedback of the items sliding in real time.

I've attached an example GIF of an interaction that I think would baffle and possibly infuriate a new user who was unfamiliar with the old "sliding" behavior. In this example, they are attempting to move the first album in between the second and third album. After they notice there was a problem, they try to fix the split-up album by dragging it back together.


Again, this made perfect sense pre-4.0.0 because you could see exactly where the items were moving.

I don't know if you've considered it, but I think it would feel the most intuitive to switch to more traditional drag and drop logic at this point, where the entire dragged group is simply placed directly above or below the drop target, without regard to which specific item was clicked. It could continue to use the existing logic that results in "drop above the target if they're moving up the list, and below the target if they're moving down".

I was thinking that it could even display a single color_listhover bar, on the side of the drop target where the items will be moved. I don't know exactly how nicely this would play with skinning, but here's a mock-up of that:


Does anyone have any thoughts on this? I do love me some options, so if you're reluctant to change it I feel it could be an option at least. It's difficult to watch that example gif and see it making sense without the dragged items sliding anymore.

Thanks for reading, and for the great software.

[Ian @ un4seen]

Agreed. Here's an update for you to try:

    www.un4seen.com/stuff/xmplay.exe

Please let me know if you see any problems with it.

[freakingmayhem]

Hey nice! I've checked it out and it seems to work as expected in all of the few tests I've done.

However, my big concern is that the insertion side still doesn't feel intuitive. It makes sense when dropping to an adjacent item, but beyond that it becomes difficult to guess visually. That's why I was thinking about making use of the pre-existing UI elements to create a sort of "insert here" line like one of these examples.



Do you consider that to be on the table at all? I don't know enough about skinning to know whether you'd be able to confidently select a color/scaler that would work correctly across all skins. But it makes sense to me if you use something that is already expected by the skin like color_listhover, but drawn only on the destination edge (or on that edge of both the hovered file and the next file over).

I believe I would still feel this way even if dropping was locked to one specific side. I think it's uncommon to find software where you can re-order a list that doesn't include a line indicator at the insertion point. In most cases, I'd imagine when they don't draw a line (and also when they do) they determine the drop side based on which side of the item you are hovering over. Something to think about either way I guess.

[freakingmayhem]

I realized something else I meant to write about the XMPlay drag and drop behavior.

XMPlay is currently unable to drag files into Discord (neither in the Electron app, nor in a browser). XMPlay can drag files into every other application and web site I've tested, and Discord is able to see dragged files from every other application I've tested. Specifically, the point of failure is on the dragover itself, so Discord does not know to show feedback or preventDefault. Looking into it a little deeper, the method from XMPlay 3.7 and earlier is able to do it.

I'm not knowledgeable enough about the topic at all to be able to speak very well about the problem here. Even after a lot of debugging attempts, I wasn't able to pinpoint anything. The most I am able to say is that it seems like every other application I tested provides larger variety of different data formats than XMPlay when dragging.

I suppose you could chalk this up to being a Discord issue rather than an XMPlay issue, but I thought I'd share.

[Ian @ un4seen]

I don't know enough about skinning to know whether you'd be able to confidently select a color/scaler that would work correctly across all skins. But it makes sense to me if you use something that is already expected by the skin like color_listhover, but drawn only on the destination edge (or on that edge of both the hovered file and the next file over).

"color_listhover" is disabled in some skins, or set to the same/similar colour as the background, so I don't think that can be reliably used for this. But using the text colour should work. Here's another update for you to try:

    www.un4seen.com/stuff/xmplay.exe

Let me know if you still see any problems.

[freakingmayhem]

"color_listhover" is disabled in some skins, or set to the same/similar colour as the background, so I don't think that can be reliably used for this. But using the text colour should work.

Ahh, I see. I'd been trying to look at it in terms of "what can we use that the skin authors would 100% expect to already be in that exact spot?" to a fault, but I like your way of thinking better.

It works really nicely from trying it out, thanks! It feels very natural now, I think. Hopefully others are happy with it as well.

[Ian @ un4seen]

Good to hear that it's working well now. A new official release (4.1) is planned for next week, so you got your request in just in time