Archive for the Category Design

 
 

Airplane Design and Customer Spaces

It seems that a lot of time and effort has been put into designing better jet engines for airplanes, for example, but relatively little has been put into designing better customer spaces within those airplanes. Perhaps some of this is itself by design (that is, airplane companies want to differentiate economy class from first class, and so intentionally make the economy class uncomfortable, barren, and so on).

Better jet engines can make a flight take less time (among other things), but better customer spaces can make a flight seem like it takes less time (because it is more comfortable, or there are things you can more easily do that will make time seem to pass more quickly), and from a customer’s perspective, the latter can be more important.

I was on an airplane recently that had a relatively simple design innovation - cup holders that folded out of the top of the seat-back in front of you. This was great, because it meant you could have a drink while not having the tray folded down and so interfering with the little space you have in front of you. This is a relatively trivial design modification that has made the “user-interface” of airplanes significantly better. (Often with user-interfaces, the best innovations are the simple ones.)

(Another obvious example of something that isn’t exactly a technology is customer service while on an airplane. I have started to disregard the cheapest air fares, and instead look to travel with companies that provide excellent customer service, because this can often add a large amount of value to a flight (if only in the conviviality of the other customers).)

Consider: if you’re paying $400 for a flight, and the flight takes 4 hours, that’s effectively $100 per hour. However, you now have 4 hours of potential value creation while on the flight. If you’re in an environment that is comfortable and so on (i.e., is conducive to you creating value), you might actually create more value than the cost of the flight. For example, if you’re able to engage in high-productivity work that will generate $400 for you, the flight becomes free. (I think this line of thought is how some people justify first-class airfares. On long flights, for example, what is a good sleep worth to you? Well, if you don’t get a good sleep how will that impact your next day? What is the potential value you could create the next day? And so on.)

Here are some simple questions that I’m sure have better answers than are currently embodied in plane design:

How do you make seats more comfortable without expanding their size (for example, changing the cushioning, changing the armrest materials, and so on)?

How do you make seats more comfortable for sleeping, or alternately can you provide things that help expedite sleep (a few examples of this are sleep guided meditation channels combined with earphones that better block the background sound of being on an airplane, and advances in head supports or head rests)?

How do you better utilize the back surface area of chairs for customer usage?

How do you increase the space available for customers (for example, can you make seats more thin by changing construction materials)?

My suspicion is that there is something irrational afoot in how airplanes are typically made vis a vis the R&D put into enhancing customer experience.

Computer Programming Metaphors

As metaphors can help people to understand unfamiliar concepts with familiar ones, it seems pretty straightforward that metaphors in computer programming can be very helpful. Since I tend to think highly visually, I have problems with computer programming (which tends to be more naturally suited to people who think “algorithmically”).

When I was studying mathematics, one of the tricks I used to turn Bs into A+s was to figure out how to turn whatever new mathematical concept or equation that was in front of me into a visual representation.

In computer programming, some of the names for concepts lend themselves naturally to visual representations. A ’stack’ is like a stack of bricks, where the first one put down is the last one to be removed, as if you are building or tearing down a wall. A ‘queue’ is like a queue of people, where the last one to be added is the last one to reach the front desk. It’s easy to think of these concepts visually. What about an ‘array’, though? It’s not really that visual (perhaps you can think of an array of things in front of you, but that doesn’t capture the importance of the concept for computer programming). Replacing it with “cubicles” might be more useful. A single-dimensional array is like a line of cubicles. A 2-dimensional array like a wall of cubicles, a 3-dimensional array like a cube of cubicles, and so on. (You can even #define cubicles array and then program with the new name.)

One set of words that is particularly ill-chosen is “compile” and “link”. Uh, guys, these are almost interchangeable in terms of what they suggest to a regular English language person. You don’t need to use an abstract word to describe an abstract process. Rather, you can bring an abstract concept to life by using a concrete word to describe it. Instead, computer programming is littered with zombie concepts - poor, atrophied words that at one point probably had some life in them.

(”Compile” is a good example of this happening. It is probably from L. compilare, which means to plunder. The link is probably from the very visceral situation of piling goods together at some point in the plundering process. This was then borrowed for the concept of putting various written materials together into a single document. Perhaps it was a lively word when this first was done, but in the current context it simply brings to mind a vague notion of putting documents together.)

I’m sure this has been done, but it would be interesting to try a development environment where you can actually insert little icons that visually represent some common functionality, such as a “for” loop (a little motor at the top with a chain with a number next to it that represents how often it will loop?).

The Game Structure of Snow-Shoveling

I have recently done a fair amount of snow-shoveling. It can actually be fairly fun. Here is why:

1. There is constant feedback on your progress.
2. Progress is usually forward-moving. (That is, you don’t have to worry about losing progress, until it starts snowing again.)
3. You can be creative in how you clear the snow and get better in your snow-clearing skill.
4. It is good exercise.
5. When you complete it, you have done something useful.

Some ways to make it more fun:

1. If you have a large amount of snow, doing it in multiple sweeps, so you can progress more quickly up the drive-way, for example. Since each sweep progresses faster than shoveling all the snow at once, this gives a greater sense of progress.
2. In addition to sweeps, don’t think you have to do all the area at once. You can often do Phase I (the first third of the drive way), then Phase II (the second third) some time later, then Phase III (the final part). (Games almost never have just one level or phase.)
3. Try to arrange things so you get social praise for it. (Most games use some form of social praise as rewards. For example, “You are the greatest ruler!” “Citizens have Praise the President Day!” and so on.)
4. Reward yourself in some other way after you have finished (or finished significant parts if there is a lot), such as having something you like to eat or drink, a bath, or what have you.

The Horseshoe Shaped Curve

I tend to spend time thinking about the structure of motivation - because the principle design problem of computer games is a motivational one. That is, how do I motivate a player to keep playing (where they often can put in hours upon hours of time and expend considerable effort while playing)?

Towards this end, a “progressive” increasing marginal tax rate (IMTR) has game psychology all wrong. An IMTR would be like giving the player smaller and smaller bonuses, or weaker and weaker additional powers, as they conquer more and more difficult levels. “You just defeated the Super-Gorgon-Platinum-DragonĀ  Level 26 Monster! Congratulations - here’s a +1 wooden shield!” (To those who have no idea what this means, you can safely assume that it is not a very good reward for the heroic feat the game player just accomplished.) Clearly, this would undermine their motivation and make them want to stop playing - rather than making them want to move further and further into the game. In other words, this sort of motivational structure doesn’t make sense as it will probably de-motivate the, in the IMTR case, taxation player.

Instead, I think that a more effective solution to the taxation problem is a horseshoe shaped taxation curve. It starts out actually quite high (say, 50%), and then its marginal rate decreases until a relatively high level of income (say, 5% at $200,000). At that point, it begins to increase again.

The practical effect of this, I think, would be dramatically different from the IMTR most socialist democracies such as the U.S. or Canada use. As you start out, the one thing that you are focused on is “How do I increase my taxable income?” because the higher your income is, the lower your marginal tax rate (at least for the foreseeable future), and so the higher your marginal net income. This is a forward-looking psychological benefit as well as a material one. As it is, many people’s focus is on how to minimize their incomes, or there is a vague unease about moving to a higher tax bracket as they consider it a diminished marginal return for often much more marginal effort - a perverse state of affairs.