[Feature Request] Add ability to re-order queued songs

[snogrammer]

Thank you for all your hard work. We love using your app!

1. Common problems that do pop up when singing with larger groups is the ability to reorganize songs that are within the queue. I'm not sure if I completely missed that functionality on my end, but if not, it would be huge if that could be an additional feature.

2. The other request is less of an issue, but just a nice-to-have. Since accounts are able to be created by anyone, would it be possible to allow access by username-only for non-admin accounts? Very minor, but also makes it easier when dealing with our non-technical singers 😄

[bhj]

Hi, appreciate the feedback! Can you elaborate on the issues you run into with large groups?

I do have some ideas for per-room settings which is what #2 would fall under, so will keep that in mind. Thanks!

[snogrammer]

I guess it's related to all singers actually, not just larger groups. But having the ability to move songs up in priority within the queue.

From what I can tell right now, if I add a song to the end of the queue that I REALLY want to sing for my next song then I would need to delete all the songs that are queued prior to that song. Then go back and add the removed songs back, instead of just having the ability to re-order my song queue and move songs around in the queue without needed to remove.

Thank you again! It's a great service!

[bhj]

Thanks and agreed, depending on the implementation this will probably be a post-1.0 feature, but I would like this as well.

[crosstopher]

Having hosted my first karaoke-forever powered party last night, I believe that queue re-ordering is sort of a critical feature. I think an option to have it be 'admin-only' or open to everyone would be nice, but at least enabled for admins. The very common problem situation is someone who, upon opening the app for the first time, queues up 5 songs while everyone else is getting their situation sorted. then it's tricky to make sure everyone gets a shot without deleting all their new stuff. definitely related to another issue about needing to be able for an admin to jump forward and back within the queue at will, in order to keep everyone happy.

[consolecwby]

Just curious if this has been addressed yet. I have been hesitant on hosting a party because of this issue.

[bhj]

@consolecwby Which issue are you referring to? Just to clarify, this:

The very common problem situation is someone who, upon opening the app for the first time, queues up 5 songs while everyone else is getting their situation sorted.

does not actually happen, as the queue is not first-come-first-serve.

[mik3y]

(Longtime lurker, first time caller! Love this project.)

I'm working on a change to address this issue, and just wanted to mention it here ahead of lobbing the PR over the wall, in case there is major directional feedback.

Here are three modest issues we ran into while hosting a party, that relate to this issue:

1. Surprise re-orderings. What would happen is a non-recent-singer would add a track to established queue, only to find they're up immediately next - sometimes in a matter of seconds! This was a sort of dual-whammy of bummer to two people: It minorly terrified the timid participant who just added the track ("oh crap, I have to go NOW?!"), and on the flip side cooled the mojo of the person who was expecting to be next ("hey what i got snaked? i was all hyped and ready!")
   • (I can see solutions for this that don't require what I propose.)
2. No support for a "reorder" operation. OP's original idea here. Our example: For the "whales" of a queue — those that have several songs queued at once — it's great that the fairness algorithm makes sure they don't drown out others. However, sometimes as one of those whales, you change your mind and want to sing a different song first. (Or you simply find, in the library, a better choice for "next" for the current moment.) It would be great if folks could say, "I changed my mind, let me sing item 5 before item 9".
   • The workaround here is to delete all your queued songs, then re-insert in preferred order
3. Guest account starvation. A handful of folks ended up sharing a tablet for getting their songs enqueued; which of course meant that N guests only get to go 1/N as frequently as a "real" user. At worst, it would be nice if an admin could reorder things.

Happily, I think there is a modest common solution to all of these: Set & use a position value server-side, in the queue table. My change adds this column in a migration; shifts the "fairness" logic to be applied on queue insertion; and updates clients to use server-side order as-is. Please shout if you see major issue with this approach.

Thanks again to @bhj + contributors - super fun project!

[bhj]

Big thanks for the kind words and thoughtful comments @mik3y!

1. I agree this can be surprising at first. Newcomers being able to sing ASAP is a pretty core feature though, and if queue positions are locked in at ToQ (time-of-queueing) :) are we not back to them potentially waiting a long time? I'd like to keep the queue order as a view on top of the first-come-first-serve DB table, but that doesn't preclude having other views. Open to suggestions for sure.

2. I plan to add a "make next" option - it won't be perfect, and the fairness algorithm will still apply, but it should cover 90% of the use cases here.

3. The shared device situation is interesting; we need some way to differentiate users, but having to sign out and back in for each handoff isn't great, whether using guest accounts or not. Definitely thinking about this though.

[crosstopher]

I really appreciate the development of this thread and I apologize for my inaccurate comment about multiple consecutive songs above. I hadn't fully experienced the 'smart queue' functionality at that point, and appreciate the 'fairness' piece that goes in to how the next song is currently determined. And I definitely agree with the points about guest accounts/shared devices, etc - at more informal karaoke parties it can be difficult to convince folks they need to go find their own phone, create an account, etc, no matter how ready and willing they are to sing. (In fact, I've found that 'willingness to sing' is often inversely proportional to 'can perform specific operations on my phone'.)

These both seem to point at a spectrum of events where KF could be used. At one end is a bunch of strangers, each with their own phone, running the show amongst themselves. For that, the current model does great at ensuring equity. The opposite would be if someone is being a full-on KJ, managing the queue, taking 'guest' requests, etc.. in which case a whole new set of features is required for smooth operation.

My personal experience is heavily slanted towards the later, but somewhere in the middle is the dream - an admin role that can add/reorder at will to make any necessary corrections to keep the party flowing (the perfect 'next song' request even if that person doesn't have their phone handy, the person who should be moved up, the person who just went to the bathroom, etc) - while still allowing an admin to step away from the system for a while (users can still browse/add/reorder their own tracks) and have the party run itself in a relatively fair way (the smart queue ordering).

Trying to cover such disparate use cases (and there are probably several more that would be worth hearing about!) has a big impact on overall scope/design/roadmap of course, so I want to be respectful of the original direction of this project (and available development bandwidth). At the same time, I'm super excited and impressed about the technical guts of the project so far and how well the network/playback/multiuser capabilities work. I'd love to be able to use KF for the full-on KJ hosted stuff too.

Anyway, thanks again for setting this all in motion and look forward to contributing how/when I can.

[bhj]

Thanks @crosstopher, and you're exactly right, there is friction between the app being designed to act as the KJ, and a KJ wanting complete control. My goal for v1.0 is to make the former case the best it can be without impacting the latter (hopefully even improving the latter a bit). For example, the "make next" button on an upcoming song could become "add again" on a past song, so if one is skipped for whatever reason it's at least easy to add again.

Hopefully some KJs will be receptive to the "whoever's gone the longest without singing is next" strategy; I think it's a strength but some will surely find it a weakness.

[bhj]

Hey all, v1.0 has been released and has some new features to address these excellent points:

• Once a user is told they're "up next", their slot gets locked-in and won't be pre-empted. So if someone joins and queues their first song, they'll be behind the already "up next" user instead of bumping them. This should help the "shy guy/surprise syndrome" while still getting newcomers near the front.
• Users (and admins) now have a "Make user's next" button, for the "just found this and want to sing it ASAP" use case. Note that it does not affect a user's place in the queue; the fairness algorithm still applies.
• Users (and admins) now have a "Re-queue" button. If someone is skipped for any reason, they are two taps away ("Re-queue" + "Make next") from getting back to where they were.

While this won't cover 100% of cases, I think for now it's a good balance between complexity and flexibility. Thank you to everyone for contributing to this thread!