I spent about 6 hours on prototype 5, but the time sped by with little notice. Call it being 'in the groove,' call it 'flow', or simply call it (my preference) 'play.' Let's just say I was a man on a mission. Let me set the stage. It was a rainy Sunday afternoon and evening here in Georgia -- no temptation to go outside. I also had had a great bike ride in the morning which cleared my mind and helped me focus on what I wanted to accomplish in the next prototype, largely due to the "quickee field test" held on Friday. It really helped me identify and prioritize a bunch of things that needed immediate attention. The game is now at a point where I am not limited to just showing people the project, but actually having them sit down and try it. I'm at that great point where people can give me reactions to an actual product, despite the fact that it is far from finished. But that's good because their feedback will steer me in the right direction. There is such a big difference between getting reactions from people based on explaining an idea to them versus feedback from their interactions with the product itself. I also felt the product was at a point where I could tap the power of the Internet to get feedback from other people given that the prototypes and the project's "story" resides on the web. So, I decided to announce my project on the ITFORUM listserv before leaving work on Friday. It was a strange and somewhat unnerving feeling to make the announcement. After all, up to that time the only people who knew about the project were those in the Studio classes and a few of the faculty at UGA. But now I had gone truly public. Quite an obligation. I now had a need to improve the user interface of the project so that people not within the sound of my voice could really make sense of it. In other words, the next prototype needed to be able to communicate what's going on without needing me sitting there pointing out what to do and what's going on. Now, I'm not saying I accomplished this in this prototype, just that it was clear that this was the direction I needed to take.

Again, the little field test on Friday afternoon, coupled with a little time for "mental incubation", really helped to point the way. The following topped my mental list: 1) add labels to the various arbitrary screen graphics to clearly define their function; 2) add graphics to indicate the 'upcoming curve' in the roadway; 3) add an introductory section that orients the user to the game and its goal; and 4) improve the graphic of the "first person" bicycle graphic at the bottom of the screen. As it turned out, I did all this plus adding the programming for the bicycle gears -- it all just sort of happened. Hey, when you are on a roll, it's best to take advantage of the situation (you just hope your family understands).

I knew all along that prototype 4 needed to have me, in person, explain what was going on to anybody who tried it. But it was clear that there were several things about the game that I had already begun to take for granted. A designer needs reminded often about what it is like for someone to see a product for the first time. Elements that seem so simple and straightforward to the designer can be bewildering to someone sitting down to the game for the first time. A designer must cherish such feedback and avoid any tendency to get defensive. Any confusion experienced by a well-intentioned user speaks volumes about the design. So, I took careful note of those game elements which caused problems and later I tried to recollect where I found myself explaining critical bits of information to the user so that they could make sense of the game and the moment-to-moment interaction. Again, it's always amazing to me how quickly a designer soon forgets what experiencing the product must be like to someone who hasn't been thinking about it or working on it for the last few weeks!

Changing the pedaling keys. I changed these from J and K to Z and X, respectively. Ultimately, I still want to give the player the opportunity to choose these two critical keys. But the programming is not obvious to me (it'll make for an interesting evening's project sometime soon). For now, I felt it was important to spread the distance between the two hands. Since the arrow keys are on the right, it made sense to choose two keys toward the left bottom of the keyboard, hence the decision to choose Z and X.

Adding screen labels. I must admit that I have long felt that one's design is a failure if you have to include text labels everywhere. I've been influenced a great deal by Donald Norman's work. Norman has written about the design of everyday objects, such as bathroom fixtures, kitchen stoves, VCRs, and even vending machines. His view is that if someone found the need to post a sign on something, then it's a clear indication that the object's design has failed in some way (otherwise, you wouldn't need the sign). The next time you are at your place of work or study, take a look for all of the various signs posted on coffee makers, copying machines, etc. (One of the Norman's favorite examples is a postage vending machine at a local post office that had long confused customers by its strange way of giving -- and sometimes not giving -- change. The problem wasn't a malfunction in the machine, but actually a design characteristic! It's a long story. But the postal employees decided to put a sign on the machine that began with the sentence "Think before you use this machine." Wow, what a concept!)

My little game, unfortunately, needed some of those little signs we call labels. If you've read earlier journal entries, you know that I've been unsatisfied with the hill gauge from the start, so the fact that this element needed a label didn't surprise me. The crude graphics used in other parts of the game, not surprisingly, also don't convey well the instant message of what's going on. An example is the roadway graphic. I'm confident that when the graphic is improved, the label can be removed.

Of course, another way of looking at a label is as a very teeny tiny bit of instruction. If you have a literate user pool, the labels act as quick way to "teach" the function or role of a screen element. (Of course, you don't have this luxury with non-readers.) I'm thinking that the display of labels could even be a function that a user could turn on or off -- a type of scaffolding. Once you finally figure out what the hill gauge is telling you, the labels would be unnecessary.

Communicating upcoming curves. This was also a very difficult design challenge, again due to the limitations of my approach of depicting the 3-D world of the real Nowhere Road on the 2-D computer screen combined with my own limitations in programming ability. It's interesting and important to note that the map does convey this information. After all, I actually used the map as a programming aid to determine the points at which the road should curve left and right. To determine these points, I slowly moved the red dot on the map, jotting down on paper the location (via the variable "distance") at which the dot turned left and right. But this map provides only rough predictions of the upcoming curves. I would need to build another map that zooms in as though a camera were about a hundred feet about the biker's head. I think the ideal solution would be improving the graphic showing the first-person view of the road ahead. That is, have the roadway graphic show what lies ahead, just like it does in real life. Great idea, but the programming task seemed too daunting for me. I may revisit this idea, perhaps by turning the roadway into a BMP sequence that shows upcoming "bends". All in all, it was clear to me that the solution needed to be situated in this first person graphic since that's where the player's attention seems to be directed. Although my solution does not involve representational graphics (i.e. a new and improved roadway), it at least involves graphics in the form of an arrow moving horizontally across the first person view indicating the direction and magnitude of the upcoming curve. The programming was easy -- it uses the same technique as that used to animate the hill gauge. I just had to set up a new variable (called "nextcurve") that is assigned the value of the upcoming stretch of road.

I played around with this graphical pointer for quite awhile, finally deciding that it was also necessary to depict information as to the direction and magnitude of the road's curve upon which the bike's tires were actually rolling. This way, the player can quickly compare the two arrows with just a glance to determine what's coming up. This is similar to the information provided by the hill gauge. Hey, at least I have some consistency between these two gauges. All three dimensions of the biking experience are conveyed through these two gauges. It is also becoming clear to me that I need to change the screen design by moving screen elements so that they are closer together. It now seems so obvious to me that the hill gauge needs to be placed right next to the first person view. I'll do that in the next prototype.

I'm being very careful with my use of color. I decided that a good way for the player to quickly distinguish the current from the upcoming terrain is through two distinct colors for each kind of information. I think red is best for the current terrain because I feel red conveys the message 'pay attention to me NOW', whereas green is far enough from red on the color wheel to, thus distinguishing it as "the other".

Constructing an introductory section. All games need directions. Usually, people learn sophisticated board games, such as Monopoly or Risk, by playing the game under the tutelage of experienced players (such as parents or older brothers and sisters). Take a look at those directions printed on the underside of the box lid sometime -- pretty intimidating! I wanted something that quickly gives a new player the goal and purpose of the game, gives them the core information about what keys to press or how to use the mouse, and gets them properly oriented visually as they begin. If the game is any good, they will soon learn the rest just by playing it. As Donald Norman might put it, there is some information that must be viewed as "knowledge in the head" (i.e. knowing that one needs to press the z and x keys to pedal and press the arrow keys to steer), whereas other information can be placed in the game design itself and learned through its playing (he calls this "knowledge in the world"). Most of my time was spent building a clear explanation, using animation, of the location and significance of the red dot on the map, the route to be followed, and the ultimate destination. This was fun to construct. I also wrote an opening screen giving a verbal description of the game's purpose and what keys to press. (Audio could easily be added here to either supplement or replace the text.) Figuring that the player might want to revisit this information while the game is playing, I also made this a "perpetual interaction" via a pull-down menu making the directions accessible throughout the game. Obviously, these directions will change as needed in later prototypes.

Improving the bicycle graphic in the first person view. After thinking about it, the need for this improvement was a no-brainer, but amazingly, I had already grown accustomed to the "stick figure-like" graphic of the bike I had hastily drawn a few weeks ago. I've improved this, albeit with my own limited graphical skills. (I'll eventually need some help by someone with graphic ability, unless I can find some good clip art to employ.) Rob Branch had a good idea that at least the top of the tire should show in order to really show how the bike is pointing and to accentuate the illusion of a bike rolling down the road. Others have since commented about the need to get some arms and hands on the handlebars. So, the present prototype is but a step along the way to improving this graphic.

Changing the bike's gears - a start. As I played the game to test the changes, I simply found myself wanting to be able to change gears, so I decided to give the programming a go. I love these sorts of programming challenges, so once I started, it was fun to work it through. These little programming challenges are leisure activities for me. I'm weird, I know. One design decision was to not allow the player to skip gears so as to be consistent with how a bike really works. When riding a real bike, there is that satisfying "click, click, click" as the gears change. Of course, you can change gears quickly while you ride, but the chain really has to go up and down the sprocket. Experienced bikers who "are one" with the terrain, the bike's speed, and the pedaling rhythm can do this very fast. But if you find yourself caught with the wrong gear at a distinct change in terrain, you have a problem. (This happens sometimes to me when I don't catch a traffic light just right, so I go from top speed to 0 in a few seconds and don't have time to shift down to a low gear in anticipation of the light turning green.) Anyway, the gears work pretty well, though I will need to do a lot of tweaking in the next few weeks. One positive consequence of adding the gears is that you can really get some speed up while riding the bike. You can reach a top speed of 25 mph in fifth gear while you can only go 5 mph in first gear. I also added the first elements of the idea that you need to be in the right gear for the terrain. This needs a lot more work, but if you play the game you will notice that if you are in a high gear (say 5th) and hit a big uphill grade, your bike comes to a stop. It's just like driving a car with a manual transmission. The car will stall if you try to go slowly up a steep hill in 4th or 5th gear.