At any one moment, hundreds of people are checking the app for day-of availability, and all of those people—whether they are serial refreshers or opening the app for the first time in an hour—have the chance to secure whatever shows up at that moment. Some will be content with the selection they see, while others will refresh the app hoping for something different (and not necessarily “better”—believe it or not, one of the FastPasses I’ve looked for and got by refreshing was for the much-maligned Voyage of the Little Mermaid, which had unusually long wait times during one visit). Would you prefer that people not be given the option to look again?
The better example is that the grocery store added express lanes and self checkout for people with a few items so the other lines can stay reasonable.
You're comparing apples and elephants here.
Is there really no spectrum between these two extremes? You don’t have to “refresh constantly” in order to continue getting FastPasses after you’ve gone through your prebooked three, as well as after each subsequent day-of selection. Why wouldn’t someone in this position check the app (without repeatedly refreshing) just to see what’s on offer at that moment rather than shrug and resign themselves to standby lines for the rest of the day?
I agree. And considering it’s a chronic problem that’s been going on for years there’s not really an excuse at this point. If nothing else, the burden should be on ops to have the basics for the queues ready to go when a new ride opens - shade, for example. If you know the queue is going to be outside just get some umbrellas or shade structures out there out there.
Disney is adding a 3rd track to Space Mountain just for FP? Sweet!
Or another couple of theatres to FoP?
Actually I think that is how it works a lot of the time when I go. They only use FP on one of the tracks and the other is standby.
I'm not saying you have to use it for every ride. We went during a 9/10 crowd level, used our 3 FP's per day that were pre-scheduled, and then maybe used it once or twice per day after that. Most rides had available times immediately after our 3rd FP. The only one I remembered having to refresh more than once was Soarin'. But that was because we couldn't do Frozen Forever and Soarin on the same set of FP's (our daughter was 6 at the time so we FF was a priority lol).
Well in your example, those aren't worthless to you. But in the context of the discussion, just because I CAN get a FP because there are some rando rides available, that doesn't make them valuable if I am not interested in going to those attractions. Ironically the ones you highlight really didn't need FP... until they added FP
As have I, are we gonna compare CVs next?
There is no explicit need for the user to have a refresh as used here. You'd never find a UX spec that showed the user 'Ok, if the attraction doesn't show up in the user's query, they will keep changing times over and over between similar times repeatedly until it does pop up'. It's just people exploiting the architect's choice of which data to filter out on the client vs what data to filter on server, and if it's cached or not. They chose to give the client only a smaller dataset of positive answers instead of letting the client have a larger dataset to pivot through on its own. Lightweight and low complexity for the client. It's what everyone would do if you can count on server load to scale as needed and you are not tasked to optimize the query. They could have also implemented cached responses so the client wouldn't have to retrieve a new list at all if you've recently accessed that time. But they probably figured it's not worth the tradeoff of complexity vs efficiency gained because they wouldn't expect a user to be doing.. exactly what people do in the 'refresh trick' are doing and no one required to shelter the server from such repeated queries.
Obviously providing alternatives and allowing the user to change their passes based on current availability is functionality the app should have, and does. Spamming the current availability response at a high frequency is not what the interaction designers would have set out to do... nor is it their flow for 'how to find a FP'. They designed it so the user picks an available alternative, modifies their search window, or give up and stick with what they have.
Yet before you said 'you'd never do that to your users', so which is it? We all know client side caches are a thing and used all over for good reason. But as outlined before, it's a question of tradeoffs and if there is no explicit requirement and you are told capacity is endless, devs are gonna take the shortest path with the least number of permutations. 