Are you old enough to remember when Disney World handed out ticket books for the rides? Each ticket had a letter–A, B, C, D or E–and was valid for one ride. ”A” tickets were for the least interesting rides, while ”E” tickets were for the best, most exciting rides like Space Mountain. Of course each booklet had way more ”A” tickets than “E” tickets.
I can still picture my parents flipping through our ticket books, counting how may E’s we had left. Should we ride Space Mountain again? Or wait to see if the line for Pirates of the Caribbean would go down? At the end of the day, we would ride the horse-drawn streetcar up and down Main Street several times. We always had B tickets to burn.
They got rid of those tickets a long time ago (1982 according to Wikipedia), but I still remember what it felt like the first time I realized I could ride Space Mountain as many times as I wanted. As a roller coaster-loving 11-year-old, it was pure joy. I remember standing in line with my brother for our umpteenth blast-off and talking about what a great idea it was to get rid of tickets. “Why didn’t they do this sooner?” I wondered aloud. “It makes so much sense to let people ride the rides they want to ride when they want to ride them.”
I was a real philosopher, huh?
What I couldn’t have understood at the time was that keeping tens of thousands of visitors fairly evenly disbursed across a park of that size is a logistical nightmare. The simplest solution is to give people limited access to the best rides. In other words, force the guests to use the park in a way that works best for Disney.
The lettered ticket system was replaced by an intricate system of electronic passes and limited-availability tickets. I can’t begin to imagine how complex the system was to develop. But it works; it’s fairly amazing, actually. And I still get to ride Space Mountain as much as I want.
In my experience with software projects, I too often find myself tempted to take the B-Ticket approach. I want to avoid the complexities of giving a user the experience they want. At times, it’s a budget concern. Other times, there are technical issues.
The more I design software, the more I find myself wanting to create systems that operate on a human scale. Ultimately, software must work for people; not the other way around! To create a useful tool, the user’s desires must be the primary concern whenever possible. In the real world, technical hurdles and budget constraints sometimes force us to compromise. If the user’s ideal solution isn’t viable, the compromise must be just that–a compromise.
A solution should be crafted that finds the closest fit to the user’s ideal rather than the easiest for the developer. People want to ride Space Mountain, not the Mike Fink Keel Boats. Herding people where they don’t want to go may address overcrowding. But the rides exist for the riders, not the other way around.
In this blog, I’ll be tossing out thoughts about how to write software that operates on a human scale. Please post your own thoughts and comments. There are as many ways to solve software problems as there are users. The more conversation we get going, the more we’ll all benefit. And the more our users will benefit.
Incidentally, if you happen to be a great lover of Mike Fink Keel Boats, please accept my apology for my flippant disregard. Ride them to your heart’s content. That means one less person in front of me at Space Mountain.