What is a Queue?

Before we do anything at all, let’s define Queue. The word has a very specific meaning in computer science as well as math; but being definition sticklers does not benefit us here, so we are ignoring that. Queues are everything that’s conceptually like lines at a checkout.

Converting this metaphor to the world of software and user interfaces, we mean anything that is some kind of list of same-ish elements where it makes sense to talk about a specific element being “next (in line)”. Some examples: Songs on Spotify that are destined to play next, the YouTube video that will play automatically after the current one (and all the others following after that), the list of notifications in the Swipe-down menu of your phone.

Why am I writing this?

I am currently building a personal productivity app which merges habits, to-dos and learning flash cards and crucially boils this mess of prompts and reminders down to one single task at a time. Building this includes building the algorithm that does exactly that: Ordering the users items and deciding which card to show next. Easy enough? Well, I am now rewriting this algorithm for about the 3.5th time. High Time to note down some learnings or at least tools for thinking to keep this number single digit.

Infinite Queues vs. Finite Queues

In a learning context, you usually have queues with a defined length, which also end. Whether you have physical paper cards with vocabulary on them or use DuoLingo, you work through something like 20 cards and then get a satisfying “Good Job! Your are done for the day” either literally displayed on the UI or generated by the reward center of your brain. This is nice, clean and enables us to use some sweet UX tools like progress bar. There are some disadvantages of course, for example that your user is not likely to do more following the obligatory leaning back in her armchair satisfied that the daily quota is done. But mostly, this type of queue just can’t handle everything. Let’s look at a different use case.

Consider Spotify, or some other music streaming service of your liking. Chances are, after the record of your choice finishes, you will get another song. And another. Obviously, there is a queue working tirelessly in the background, but it does not seem to be an ending one. You would be moderately confused to mildly annoyed if songs would just stop after 20 continuations. Well, maybe you would not be. After all, Spotify offers an option to disable autoplay of “related” songs and a vinyl connoisseur will likely tell you that the finiteness of a physical record dignifies it. Fair enough. But apart from that, if your use case lends itself to this kind of queue, you have to think about it very differently.

Bonus thinking material: Are super market queues infinite?

How many items do you show/have?

Another consideration is the question about the number of items next in queue that you expose or even generate at a given time - let’s look at two extremes. When a Netflix show ends, as they occasionally do, the UI will show exactly one TV show that it not just recommended fir you to watch, but will in fact automatically start after an unfairly short amount of seconds. Unsurprisingly, I don’t actually know how Netflix implements this feature technically, but conceptually, this may be considered a queue: We have quite big pool of shows you have not watched, we order them by likeliness-to-enjoy (or something) and show the first one. Obviously, the number of queue items exposed to the user is: One. Maybe you could argue that one or two alternative recommendations on the screen wouldn’t hurt, but not much more.

Now the opposite: An email inbox is kind of vaguely a queue (don’t fight me). Here however, you obviously show the user every last item in it. Maybe you want to cutoff the list after like 500 items to keep your hardware temperature within spec (the cool kids call this pagination), but not much earlier.

Where do you fall on this spectrum? I can’t tell you, but let me give a way-too-in-depth-example of why it matters. Music streaming queues feel like an infinite queue with only one exposed item at a time, and they are, but also they kind of are not. Spotify for example requires just one click and then promptly shows you the next thirty-five songs due to play. This is a useful feature, for example when you add a lot of songs to your queue and then feel the need to do some low-budget mixing by ordering them into some kind of flowing musical experience. However, I now met multiple people including myself who at one point thought their Spotify queue was broken - with always the same backstory: They (/me) had accidentally added a ton of similar songs to their queue (easily done by selecting a record instead of a song with the same name, for example) without realizing. Subsequently, the queue ambivalently spit out samey song after samey song, giving the quite annoying impression of a relative telling the same story at every family dinner. Evidently, the mental model of operation used here was that the queue was of length one and thus should pick each next song dynamically. The correct model, the queue being something obediently walking down list with defined elements one can edit, move and delete was not even considered by most users. The moral of the story? Think about and experiment with what kind of queue server your users best. What do they expect? Which weird state could happen? How to resolve them?

Technical Implementation Of Queue Length

As if all this is not weird enough, we also have to keep technical aspects and UX aspects separate. For example, how many items in your queue we generate (or have up our sleeves) is not necessarily equal to the number of items you expose to the user. Spotify presumably needs a sizeable number of “next songs” ready to be accessed at any time, to prevent awkward loading in case the user starts rapidly skipping songs, but this does not inherently force them to show more than one song (the one playing right now) to the user. The following questions have to be answered on a technical level and are influenced but not determined by your respective UI-choices:

• How many items does a queue have?
• When are new items generated? (might be when the number of items is below a point, once a day…)

Dynamic Queues

May God help you if your queue has to change while the user interacts with it (think of people cutting in line). Just inserting items can be fairly straightforward, this is why most music streaming allow you some kind of “Play Next” function resulting in your chosen song being crudely wedged between the current one and the planned next one. But if I “queue” a rock song into my current queue of classical music, should the rest of my queue adapt and become a bit more heavy in lyrics and riffs? Sounds cool, but there is a reason that (I think) no music service does this, and it is complexity. Let’s say we implement this feature. Now: What if some items can be changed (auto picked songs) and some should not be changed (specifically user-picked songs)? What if the user goes backwards in the queue? What if you are trying to maintain some kind of balance, like 50% songs the user already knows and 50% new ones? This is an unholy can of worms. Sometimes you do have to get the can opener, though: I found that the alpha testers of my productivity app became very frustrated when they added new cards which then only appeared after the currently generated queue (sometimes hundreds of cards) were done. A queue with a length of one is appealing here, because every single item that gets picked can be chosen with all the data points you deem relevant.

Edge Cases, So Many Edge Cases

If you haven’t encountered the term before, and edge case is what happens when some relevant parameter is extreme. Does your car open when it is minus forty degrees outside (pick any scale you want except Kelvin)? Can I sign up to your app when I have no residential address? That kind of stuff. For queues, we have the usual suspects: Empty queues, or a queue with millions of items. They aren’t too mean; just don’t forget about them. But counterintuitively, the nature of items and their quantity drastically alters the behavior the user expects from the queue as well. In other words, edge cases emerge! A user who shuffles a playlist with three songs may expect other things to happen than someone shuffling a playlist of 23,134 songs. A queue of videos is different than a queue of music videos. This is presumably why YouTube branched off YouTube music, which may seem like a weird, self-cannibalizing move. For my productivity app, I thought of nice ratios of to-do cards vs. learning cards, but what about users who only have one of the two types, or vastly more of one type? If a user has a deck with thousands of Spanish words and one with 200 countries and capitals, in what ratio should cards of the two decks occur?

Extensive paper sketches of trees and tables and of course user research are the answer here. As always, think about whether the complexity is worth it - not only in development pain, but also in its danger to create edge cases which are more painful than the added niceties are nice.

Queues Are Hard To Communicate

In the first iteration of protoyping my productivity app I named my queue, well, “Queue”. Nobody clicked it. This is quite obviously a bad name for an action button (as it does not contain an action), but what would you name it? And I am not the only one with this problem: The context menu for a song in YouTube music has both “Play next” and “Add to queue”, sharing almost the same icon. The first queues to song immediately, the other one at the end of the queue. Which means the end of the explicit queue, as in the one made from songs the user specifically queued with one of the aforementioned buttons. I think. I would have to check. Do you see what I mean? Queues are a common occurrence, but that does not mean that they are either to understand or to describe. By the way, operations on queues are just as painful - here is an article from the Spotify dev blog describing all the things that may be meant by “shuffle randomly”.

Again, consider what your users know, expect and are willing to learn. If you aren’t talking to cashiers, computer scientists or linguists, avoid the word “Queue”.

Some Kind Of Conclusion

Since this is more a collection of ideas than a lyrical epos, I wouldn’t know what kind of conclusion would fit here, except maybe: Queues are fun, but mean. Enjoy with caution.