Batch move & delete

[PX7057]

I would like to have:
Batch move: moving more than one track at a time. So you mark all the tracks you want to move and pull them to where they are. If a track is between the two marked ones, the moved tracks get put together with no gap in between.
Batch delete: mark and delete multiple tracks at a time.

[6arms1leg]

thats a feature im missig, too.

So you mark all the tracks you want to move and pull them to where they are. If a track is between the two marked ones, the moved tracks get put together with no gap in between.

? hmmm, maybe the easiest way is to handle this just like all the email uis do: a small checkbox next to the item and an "action button" (move, delete, etc) for all marked tracks. but thats not for me to decide...

[devsnd]

? hmmm, maybe the easiest way is to handle this just like all the email uis do: a small checkbox next to the item and an "action button" (move, delete, etc) for all marked tracks. but thats not for me to decide...

I don't like that solution at all, but this might be the only way to get it done on mobile. (But there won't be an action switch, I don't like the idea of an almost CL-Interface in a webapp)

We're definitely will try to get a more desktop feel for the application; But it's true that drag'n'drog combined with selection is hard to get right.
Most file managers even suck at it, and this is (most of the time) their only focus. So for me, I'd rather go with modifier keys; Pressing CTRL will put you in single selection mode, shift will get you in batch selection mode, I will add a "trash bin", to which the tracks can be dragged, so that it's easy delete multiple tracks at a time.

[6arms1leg]

I will add a "trash bin", to which the tracks can be dragged, so that it's easy delete multiple tracks at a time.

but to get this right, the trash bin must always be visible -- independent of the scroll position (like the little ^ top button). and i also propose to do so with all the other elements (search function, options, logout, playlist-tabs). but thats another issue. <- see edit below

i hope there will be an alternative to dragndrop to the trash bin, you know im not good with the mouse. i prefer buttons. maybe just klicking on the trash bin (or the already existing delete button) after marking tracks?

EDIT:

and i also propose to do so with all the other elements (search function, options, logout, playlist-tabs). but thats another issue.

just realized that the ^ top button works around this problem. if all ui elements were staying on top of the screen, they would probably take up too much space to display tracks and search results, especially on smart phones. so never mind.

[tilboerner]

Is this still an issue? If so, I'd like to know if it matters in specific contexts, where it can be solved without creating the ability to mark arbitrary lists of items. Is there anything the tracks to be added/deleted have in common? Can you describe a typical use case?

[6arms1leg]

yes, this is still an issue i think. you cant move more than one track at a time, which is annoying. sorry, didnt get the rest of you questions... please re-phrase your questions in simplified english. 🚸

[tilboerner]

Sorry, my head's full of weird constructs, sometimes. I'll try again.

Your The original request was to mark a block of tracks, to be able to add or remove them in one go. We currently have Add all to, Clear queue, Remove played, which do similar things, but only for some blocks.

These actions don't work for you in all cases, or we wouldn't be talking here. You must be encountering blocks of tracks where these actions don't apply, but something similar should. In situations like this, what makes the tracks so special that Add all to won't work, but they are still displayed as a block?

Would it help if adding/deleting single tracks were really easy/fast? What makes it difficult/slow?

I'm trying to find out if we can solve the issue without extending the UI in a big way. That's why I'm trying to separate the problem from the proposed solution; the ability to mark arbitary (blocks of) tracks might be overkill.

[6arms1leg]

ah ok, thanks.
there is one thing in particular, that annoys me:
imagine you create a playlist with several albums in it. now, that you have your new playlist, you figure that you want to rearrange a few of those albums within the playlist. two albums that are rather far down at the bottom should be moved near the top of the playlist.
now, you dont want to move those two albums track by track, but repeating the whole process and recreating that long playlist -- but this time in the correct order -- isnt a pleasant solution either.
the easiest way would be to mark all tracks of those two albums and move them to the top all together.

[tilboerner]

Thanks for explaining! Does that happen often, though? I guess I'm using playlists in a different manner, so it still feels like a rarely needed use case to me.

Three ways to handle the situation come to mind:

1. Allow nesting of playlists. (Sorta like: Playlists can contain playlists, because they are a form of "MediaItem", and Playlists can contain Mediaitems.) Yuck! Spotify allows having playlists in the queue, if I'm not mistaken, but still: yuck!
2. Tracks in the situation you describe share a common path prefix. That could be used by a "mark similar" tool, a bit like the magic wand in photoshop, which might be easier to handle for the user than introducing something like a vi visual mode to mark stuff... :magic_mushrooms:
3. In fact selecting multiple tracks, by whatever means (clicking a special checkbox, dragging (and scrolling!), ...).

I still don't like any of it. As I wrote, to me it seems like a making a major change for a minor convenience. My vote goes to wontfix.

[6arms1leg]

[...], so it still feels like a rarely needed use case to me.

thats different with me. although i dont create playlists that often, it almost happens every time i do create a playlist.

Allow nesting of playlists. (Sorta like: Playlists can contain playlists, because they are a form of "MediaItem", and Playlists can contain Mediaitems.) Yuck! Spotify allows having playlists in the queue, if I'm not mistaken, but still: yuck!

ha! have a look at #218.

I still don't like any of it. As I wrote, to me it seems like a making a major change for a minor convenience. My vote goes to wontfix.

i certainly see your point. i wouldnt mind if this issue gets a wontfix, i just dont want this issue to be dismissed because its difficult to pull off. if it was a useful feature, it should get implemented at some point. im not the one who does the work, though. 😁

how about a "long click" to imitate the behavior of [shift] + [left mouse click] in most file browsers? that way a user can select an "interval" of tracks from a playlist, by long-clicking on one track and then another to select all tracks between those two.

well, guess thats not perfect either. if nobody else cares, im fine with a "wontfix".

[devsnd]

please dont bring up #218 again...!

but i think we should have all of it. selecting and moving multiple items is a cool thing and the right thing to do. Further drag and drop from the mediabrowser to the playlists would be great.

we need a working "tech demo" for desktop and mobile before I consider integrating it into CM.

There's something on stackoverflow, but most demos are buggy/weird, but it's a good start:
http://stackoverflow.com/questions/3774755/jquery-sortable-select-and-drag-multiple-list-items

We've basically revamped jplayer playlist already, so i'd be fine to go ahead and throw out even more of it and reimplement it with CM in mind...

[tilboerner]

@6arms1leg

ha! have a look at #218.

:D and almost no crack involved! how peculiar. 🚬 :squirrel:

@devsnd

drag and drop from the mediabrowser to the playlists

Drag and drop all around! Every track should be draggable to any place that can contain tracks. I've thrown tons of tracks out of playlists-in-creation which should have gone into a different playlist right away.

selecting and moving multiple items is a cool thing and the right thing to do

Only if we can do it without tieing knots in people's fingers or brains. In the wrong environment, this stuff seems hard to get right - have you tried any of these extensions that let you select multiple browser tabs?

But I like the "long click" idea @6arms1leg came up with. It's not very discoverable, but people who've cut and pasted on their smartphone know it's a thing.

[tilboerner]

Forgot:

We've basically revamped jplayer playlist already, so i'd be fine to go ahead and throw out even more of it and reimplement it with CM in mind...

I'm all for keeping jPlayer intact and building an adapter interface around it that does what we need. Which totally means more of our own code for playlists and stuff, but less getting elbow deep in 👽 guts.

[devsnd]

I'm all for keeping jPlayer intact and building an adapter interface around it that does what we need. Which totally means more of our own code for playlists and stuff, but less getting elbow deep in 👽 guts.

Just for the record: I want to keep jPlayer untouched as well, but jplayer.playlist is an extension to it which we already have strongly modified.

[tilboerner]

Oh, alright then. I wasn't aware of the extension-ness - always thought of it as deeply entwined with jPlayer itself. I'll gladly replace / gut / enslave anything that doesn't reach into jPlayer to tickle its internals and is no dependency of jPlayer core functionality. No sense in building a wrapper around that. 🔪