There’s a new trend emerging with new apps. A typically British tradition, queuing has managed to find its way into digital downloads, turning what was once a free and open marketplace allowing users around the world to download an application instantly, into what you would more commonly associate with the analogue, real world , waiting. App waiting lists are becoming more and more common.
There are many reasons to create app waiting lists, but some even go so far as to prevent users from downloading the app at all. We take a look at a couple of examples to see just why you would bother limiting the number of downloads in a given time, or limiting the number of downloads altogether.
In February, calendar app Tempo and inbox management app Mailbox launched, but quickly set up download waiting lists. More recently, cloud-storage app Loom did the same. This resulted in thousands of users joining a queue in order to successfully download the application. This turned into a bit of bad PR, with users frustrated that they were being made to wait. But there was a good reason for the delay.
With apps such as these, with the potential for massive amounts of data to be moved around by any single user, it is important to ensure that the total user base does not exceed the capacity of the server. In other words, making users queue up for a service ensures they do not overload the system. Even with all the testing that apps go through and with very detailed projections based on even large data sets, it is still difficult to project a users activity.
For instance, one of the early users of Mailbox shifted 40,000 messages to his inbox at once. That, combined with the rest of the user base using the app all at once in the mad rush immediately after an app is made available was far too much for the server to cope with. So, to avoid crashes, the developer has two options. They can either throw money at the problem, increasing their data capabilities, but this can be an expensive solution to a short term problem which will become unnecessary in the long term. The other option is to slowly introduce more users, bringing up the need for a queue system.
The benefit of this is that the server will not crash and, despite a fewer number of users being able to use the service at once, it ensures that at least some users will have access rather than none at all.
Naturally, this is a pain for the waiting users. And with cloud-based services pushing and pulling data becoming more common, these queues may also become more common.
The other way of controlling your user base is to release your app to a limited number of people. There are numerous methods of doing this, with geographical limitations, specific device qualifications or even simply first-come, first-serve. The purposes, though, are very different.
The most infamous example of this type of release is Jay Z’s Magna Carta Holy Grail app. Infamous maybe for other reasons, which we have already discussed, the app was only available to the first one million Samsung Galaxy S III, Galaxy S 4 and Galaxy Note II users. The app enabled these users to unlock Jay Z’s new album of the same name, three days before its traditional release.
It’s obvious what was being attempted. By limiting the release, hype was generated about the app and the album, leading to more and a more concentrated demand for the album. It was a marketing drive, designed to promote a feeling of exclusivity. Fans would be desperate to be one of that million privileged users to have access to the album before anyone else (other than the other 9,999,999 privileged users…)
Did it work? Yes. The app was probably one of the most talked about apps of the year, even before the concerns about privacy and the hacked Fourth of July version. But many commentators were talking about it because it was limited. Then again, that only added fuel to the fire, increasing the feeling of exclusivity to users lucky enough to own one of the Samsung devices.
The inevitable happened, with pirated copies appearing on torrent sites for users to download on any Android device. It enabled thousands of users to flock to it to see what the fuss was about. As a marketing gimmick, it worked. It suffered lots of criticism, but that only added to the already numerous column inches.
The thing is, it was Jay Z’s app. A limited release isn’t guaranteed to generate interest. First, it must have a genuinely sought after name attached to it. A limited release probably wouldn’t help a Steve Brookstein app grab headlines, for example.
Before you decide to limit your app’s release or create an app waiting list, ask yourself and your app developer “is this necessary and/or beneficial.” That’s really a question you should be asking yourself before every decision anyway. With more cloud-based apps, queues may become more prevalent, but that’s not because it’s trendy , so don’t go jumping on the bandwagon.
Users , it’s also helpful to remember this: queues are so everybody has continued access to a service, even if you have to wait a little while. Limited releases are to generate hype.They are designed to benefit the provider, not the user. Magna Carta Holy Grail would suggest the download of limiting releases isn’t worth it, unless you’re Jay Z.
Photo Credits: HighTechDad and Adam Glanzman