Ball Game Update: Final! Winter Show!

This is a post about the final updates to our ball game and the 2017 ITP Winter Show.  For more about the project’s conception and prototyping, look here, and for our planning process, look here, and for some on our fabrication, look here, and again here.

Final User Testing

Our in-class discussion and feedback for our final project presentation focussed on opportunities for increasing subtlety and complexity in how we presented information.  April and I aspired to create a game which didn’t require any instructions — one in which the game’s interface afforded exactly what the users could and should do.  In practice, the game required a single instruction:

  • shoot for your own goals (rather than your opponent’s goals)

This could have perhaps been solved with a painted playing area (one half being red and one half blue), or some other related design choice, but in the time we had left, it was solved with an on-screen instruction.

Additionally, we would have liked to have the game’s reset and (planned) menu options (for choosing between planned single and 2-player modes, difficulty levels, high scores, etc.) to all be accessible through the game’s goal interface (i.e. menu options could be chosen by shooting for specific goals), but we again did not have time to fully implement this.

Winter Show

After presenting our final in class, we had one last opportunity to user test at this year’s ITP Winter Show.  We updated our project based on our in-class feedback, focussing on making our serial Arduino to P5.js interface and physical game more robust to hold up to the several hundred visitors for the show.   While debugging, we simplified the serial protocol so that the “hello” portion of the handshake reset the game on the p5.js side.  This allowed the arduino to be reset directly (using a big red arcade pushbutton attached between its reset pin and ground), rather than through a p5.js interface.  In practice, this meant our code was simpler on both the Arduino side:

and on the P5.js side, which recognized this “hello” function as a cue to reset the game:

Of course, using this method, rather than use the much more complex protocol we had previously used, in which our p5.js sketch had control over all of the Arduino’s goal-states (which control the LEDs as well as the scoring) was a decision driven by need rather than desire.  Our previous serial communication protocol was buggy and this work-around seemed best suited to fix it.  If I were to continue with this project, however, I would re-implement p5.js control over the arduino, such that all of the game logic was contained in one place and could be more easily connected, changed, and iterated upon.

Additionally, if I were planning the project’s next phase, I would work on:

  • increasing interactivity with respect to goal-state changes and scoring:  I could imagine a number of modes in which the goals responded actively to scoring to benefit either the first or second place player.  For instance, goals switching colors after every score would benefit the second place player while having scores turn off an opponent’s goal would benefit the player in first place.
  • managing chaos: while the bouncing ping pong balls were fun in class and at the Winter Show, that particular aspect of the game didn’t lend themselves to any sense of containment or order.  Without a dedicated game space, or a net setup like I put up at the Winter Show, chaos rules.  Perhaps this game is not meant to be portable, and should be used with a net, but I would be interested in cheap (in terms of less complexity while building, not just cost) solutions to this problem.  I can foresee using less bouncy balls and/ or creating angles on the faceplate and goals which redirected incoming balls downward.
  • dialing in the interactions: ideally, this game wouldn’t require a screen, or at least wouldn’t require anything resembling a sentence on screen.  I can imagine this working if we added more visual and aural cues for the player in terms of blinking goals after a score, more sound cues, spoken countdown and game over cues, etc. and would increase the overall smoothness of the game experience.

All of that said, the reaction at the Winter Show was very positive!  Our setup was packed the first day with children (who often played three or four games in a row) and — after some brief repairs — was packed again on the second day!  It held together remarkably well through several hours of sustained use, and was reliable in its score-keeping, serial communication and p5.js sketch.  For whatever reason, we sometimes needed to reset the Arduino several times before the p5.js sketch reset, but it worked reliably enough that I never quite tracked down this bug’s source…  Anyway, here are some photos from the show:

Carnival Ball!

This is a post about the last stage of our arcade / carnival game construction and coding.  For a bit more about the project’s conception and prototyping, look here, and for our planning process, look here, and for some on our fabrication, look here.

After last week’s user testing session in class, April and I focussed our last week of work on improving two aspects of our construction and design:

  • Physically, it was important that the ping pong both didn’t bounce out of the goals and reliably returned to the players.  Because ping pong balls are designed to bounce (and do this quite well), this proved to be more of a challenge than expected.
  • In terms of the code, it was necessary that the goal sensing/ score detection worked without fail.

Physical Construction:

At first, I made several attempts to design goals which worked reliably (didn’t allow bounce-out) from 1/4″ luan.  My process involved mocking up the panel shapes with cardboard, cutting them out of luan, and gluing them together.  The angles were designed to redirect the forward motion of the ball downward.  Despite my cardboard mockups working quite well, however, luan ended up being much too spring-y of a material to reliably avoid having the balls bounce out.  So, I cut our final goals out of cardboard, which has just enough sponginess to avoid the balls bouncing out.

 

Goal sensing:

Piezo sensors proved too noise-y to reliably sense a single goal.  So for our final version, we returned to light-sensitive resistors as a way of sensing goals.  We had moved away from this method for cost reasons, as the light sensitive resistors embedded in color sensors were quite expensive but having decided not to sense ball-color, the light sensitive resistors themselves were both reliable and cheap.  For each goal, we positioned a white LED aimed at a LSR hooked into our Arduino’s analog input.   The ball would fall between the LED and LSR and create a drop in voltage seen at the analog input pin.  In code, we used a peak detection method described here to sense this drop as a score for either the red or blue team.  Because the mounting for each goal was slightly different, we had to individually set the threshold values for the six goals.

Serial Communication between P5.js and Arduino:

Our final challenge this week was developing a protocol for communication between the p5.js sketch and our Arduino.  Our midterm project used a reliable two-way Serial protocol with a handshake method (as described here) to send scores from the Arduino to the p5.js sketch and to reset the score.  For our final, however, we had the added element of setting each of the goal states as either “red,” “blue,” or “off.”  This would indicate that a goal could be scored upon by the red team, blue team, or neither, respectively.  At first, we hoped all of the logic behind changing goal states could be handled on the p5.js side (where the rest of the game-related logic lived), and goal state information would be sent to the Arduino as a string.  In the Arduino, the goal state would be used to determine which team’s score was added to when a goal was made, and which LED’s were turned on.

This protocol worked quite well in isolation.   From the Arduino Serial Monitor, we could send strings of “gRRBBRB” to set the goal states to red, red, blue, blue, red, blue and the Arduino would switch it’s internal scoring logic as well as lighting accordingly.  However, once this was incorporated with the rest of the p5.js serial protocol, we began to notice strange behavior: goal states would be sent from p5.js to the Arduino but not change the goal states, or other failures would occur.  I believe this is due to the p5.js sketch timing — and the fact that asking the Arduino for the score (by sending an “x” serially) could happen in the middle of sending a goal state update.  I am reworking this protocol to avoid this.

 

Final Project Planning

On Planning

How do we allow creative flexibility into a project timeline while recognizing the logistical needs of getting it done?  This question comes up at some point in any project’s maturation from idea to mockup to fully realized creation.  How do we maintain a flexible and evolving understanding of the project’s goals throughout a planning process which by design tries to ‘nail things down’?  Personally, I find that planning — specific and tedious planing — is not a limiting activity, but raises questions which ultimately lead to a greater understanding of the project and how to execute on it.  The act of pre-visualization demands a more rigorous mental model of the project than I would otherwise develop and forces decisions to be made.   As long as planning is done early and often, and as long as you are willing to to discard previous plans, you will have a greater conceptual and logistical understanding of your project.

Final Idea

For our final Physical Computing project, April and I are planning to continue our midterm project of an interactive ball-tossing game.  After combining feedback we received from our class following last week’s proposal with feature ideas we have been developing, we are left with a outline for a game with a rather broad set of features and challenges.  Narrowing this feature set down into a manageable project will be our goal for the coming week.  There are aspects of the interaction we know we need to improve upon: improving ball-return, increasing goal size, and balancing difficulty for players of different skill sets.  There are features which we would like to see implemented: increasing number of goals from two to six and dynamic goals (which turn on and off).  Finally, we have several questions we would like to answer through user testing: how do players interact with the projection-based scoring system we currently have in place and could this be improved upon?  Could we / should we incorporate a storyline element in the style of pinball storylines (i.e. the storyline does not affect gameplay, but it visually interesting)?  Would it be possible to develop a single-player mode?

One of the comments we received in last week’s feedback was that the game is sufficiently complex with only two goals.  We believe, however, that having each goal have two or more “modes” taps into an exciting vein of potential interactivity between player and player, as well as between player and game.   Physically, each goal would have a ring of lights around it which indicates its current mode: active (lights on) or inactive (lights off) as well as which team it belongs to: blue (blue lights) or red (red lights).  When a goal is “active-red”, any balls which are scored through it increase the red team’s score and visa-versa.  When a goal is inactive, no scores are counted.   This allows the possibility of a single player mode in which the game responds to the player — i.e. the active goal changes every time the player scores.  It also allows for the possibility of increasingly complex and  interesting scoring mechanisms: a blinking goal doubles score, etc.  In short, we feel that this added complexity in hardware design would be well worth the potential increases in interactivity.

Nothing to it but to do it…

Of course that isn’t quite true, and because we are adding a level of complexity to the goals and are still unsure of the scoring system, I think it behooves us to build soon and use a working model for playtesting.   While I would like to playtest with a cardboard model for longer, build another model, and properly nail down the interactivity before the final project is built, our shortened timeframe doesn’t necessarily allow for that and I believe our current model is a step too far removed from what we’d like to see to use as a proper play-testing model.  Because interaction depends so much on specifics (of timing, physical spacing, and subtle allowances in the goal-lighting), it is difficult to bring our idea forth without fully building it.  That said, much of the coding work is less vital to playtesting, and can happen relatively later in the process.

Below is a preliminary bill of materials and a very preliminary timeline.

Bill of Materials:

Timeline:

 

PComp: Serial Communication

Serial Communication:

  • This week, I used a potentiometer as a game controller for a “Helicopter Game” I made for ICM.  The potentiometer was connected to an analog input pin of my Arduino Uno, which was connected Serially (through the p5.serialcontrol application) to my p5 sketch.
  • There is currently a slight delay, so I would like to switch from the ASCII to RAW protocol and try some of the techniques from this video to speed it up.

(UPDATE) Midterm Brainstorming Process

UPDATE (Oct 25, 2017):

This post is about the project concept and interaction design elements of our midterm.  For more about the construction and coding process, see Yifan’s post here.  With a midterm project idea as simple as ours — “oh!  it is kind of like Skee Ball” — we were able to delve quite deep into the details of the interaction design and execution for our game.  Because the goal was simple (to have fun), and our success in that goal immediately obvious when watching someone play, our process was not bogged down in navel-gazing or ruminations on the nature of play.  Instead, we were able to create a working prototype and watch people play!  Here is some of what we learned:

  • Either ITP students are hungry for distraction or the appeal of ball-games is even greater than I imagined.  Whichever the case,  I was glad to see that the game did have a natural draw.  Though never announced, except by the loud bounces of many missed shots, many students came by and asked to play.
  • The game’s difficulty varies drastically from person to person.  We didn’t specifically or numerically plan how difficult the game should be (e.g. “an average of 2 goals for every 3 misses”) and had no idea how difficult it would be until it was fully operational.  After our first few times playing, however, we decided to add somewhat larger “baskets” to effectively increase the size of the goal.  I believe that the size and shape of these baskets has a drastic impact on the game’s playability.  Because there is a simple and natural way for a player to dial in their personal difficulty level — by moving closer or further from the goals — the baskets simply act to assure that those balls which make it into the goal area don’t bounce out.

We spent much of our time working on the scoring system of the game, which we hoped to make as fun as the game itself.  This system has the following elements:

  • Rounds: rather than choose an arbitrary goal count for a player to reach (e.g. 5 or 10 points) to declare a winning state, we instead use a count down timer to delineate rounds.  It is no secret among arcade game designers that time restrictions increase excitement.  Also, not knowing exactly how many goals each set of players would be able to make within a given time, this also seemed a good way to avoid frustrating players for whom point-limited rounds would be either too short or too long.
  • Visuals: in addition to displaying the score visually, we show a reward in the form of an animated gif for each goal made.  This is in keeping with our aesthetic choices throughout — which prioritize fun over all else.  We would like to have this gif chosen at random from a series of gifs, such that the exact reward is new almost every time.  This has the added bonus of making the game more fun to watch for an ‘audience’ of people waiting to play.  Additionally, and perhaps most importantly with regards to the visuals, we plan to project them onto a wall behind the game.  This larger than average scoreboard should bring some excitement to the scorekeeping aspect of the game.
  • Sounds: we play a dance track from youtube’s free music library, along with sounds for goals made.

Next Steps:

This game could do a lot more to increase physical interactivity between players as well as between player and game.  Here are some of the ways we’ve discussed to push this game toward a novel interactive experience:

  • The game looks somewhat like a face, with the two goals presenting themselves as eyes and the mouth (and long tongue) making up the ball return.  We have done little to emphasize this, but fully realized, this face could present both a new way for the game to ‘play back.’  With eyebrows, the game could both emote, and potentially increase or decrease the difficulty.  The face could “spit” balls back toward the player, rather than politely letting them roll down its tongue.  The game could cover and uncover its goals randomly or according to a predictable timing scheme..
  • Scorekeeping: there is always work to be done on creating a fun scorekeeping experience.  I have never been particularly amused by pinball machines, and their excessive trailing zeros.  Just because a score is no longer 10, but 10,000,000, does not make the game 1,000,000 times more exciting.  It simply makes it harder to read.  On the other hand, bowling alley animations — terrible motion graphics held over from the early days of computerized scoring systems — hold a place that is near and dear to my heart.

 

ORIGINAL POST (Oct 18, 2017):

April and I began our brainstorming process with a surprisingly aligned set of goals for and approaches to this midterm project:

  • We knew early on that we wanted our have both a physical input and output rather than using a serial connection to a computer or display of some sort.  This decision to keep our project strictly real-world was, for me, a challenge to focus our energy on the interaction design, rather than delving too deep into the granular coding requirements of building a mixed physical-digital experience.
  • We also knew that we wanted to make a game — something approaching arcade or carnival style games: Whack-A-Mole, water gun games, Skee-Ball, etc.  Interaction though gameplay has an instant feedback loop in that is either fun or not.  Because the purpose of its interaction is clear —  to have fun — and our experience of fun (or boredom) is emotional, it is easier to analyze a game’s success than an interaction whose purpose is less specific.  A work of art has much more complex of a purpose and a solely utilitarian device (a tool) has a much less emotionally focussed purpose, so neither presents as compelling a case study as a game.

With these two goals in mind, we eventually chose to work on a Skee-Ball style game in which two players would throw ping-pong balls into two holes in a board and rack up points.  Competition can be very fun, so we baked in two elements of competitiveness into the game’s design:

  • The players would play simultaneously, throwing two differently colored balls into two differently colored holes. The implicit competition is that the players are racing to rack the most points up.  While the winning condition (first player to 5 or 10…) may well be unclear without instruction, the fact that the players are next to each other playing separately (as indicated by the color-coded gamepieces), should strongly indicate (assuming previous experience with some games…) that the players are playing against one another rather than together.
  • The players would also be given the option to throw their ping pong balls into their opponent’s goals in order to deduct points from their opponents.  This should add a second level of competitiveness between the players as well as giving the players a strategic choice on every throw between whether to increase their score or reduce their opponents.

With these goals and game elements in mind, we made up a few quick sketches on paper…

…before mocking up the game in cardboard…

and finally starting the game build it in foam core.

Unanswered  logistical & interaction-design questions:

  • How to identify whether a ball has gone through goal / how to identify balls by color?
  • How to display score?   Can this score board be physical and accurate enough without requiring a digital display?  I think the display element could provide a chance to set the character of the game aesthetically as well as reflect the scoring system to the player.  This display could be absolute (0-5 for each player) or relative (player A is higher or player B is higher):
    • If absolute, we could use two sets of motors/ leadscrews/ leadnuts to move pointers along two score-card (0-5) to indicate that first player to get 5 points wins.
    • If relative, we could use an old-school elevator floor indicator (as found above the elevator doors in the lobby floor of older buildings), which uses a sort of a semi-circular scoreboard with a 0 score position at the “noon” position.  As players racked up points, the pointer would move toward their side.  This could indicate a “win by 3” scoring condition by the fact that the pointer would  have an obvious stop at “3 o’clock” or “9 o’clock” and the numbers 1-3 would be written to either side of the 0 at the “noon” position.
  • About the option to deduct from your opponent’s points: how do we indicate to the players that this choice is available to them besides simply telling them? Perhaps some sort of colored LEDs around the holes which blink from one color to the other at a specific interval and allowed players to try for deductions (i.e. the blinking ghost mode in PacMan).  What parameters as far as scoring would encourage players to use this mode, or make this mode at least a 50/50 choice for players?  By how much should your score increase when you make it in your goal and your opponents score decrease when you make it in theirs?  2 to 1?  I want to ensure that this doesn’t (like the card game “war”) feel like the game will never end because scores constantly fluctuate up and down.

Physical Computing: Servo Control

Over the course of this week’s labs, I made a simple mechanical linkage out of foam-core, hot glue, and a bit of metal rod which uses a servo to control the angle of a camera in the up-down direction.  What I discovered was that mechanical linkages are almost completely foreign to me.  Despite that our lives are filled with them, and I can name dozens of applications for mechanical linkages in my daily life, I have very little frame of reference by which to pre-visualize their operational characteristics.  It took some time, for example, to understand how to translate the servo’s limited rotational motion to the camera unit: the rotational motion of the servo becomes a linear motion of the connecting wire, which is then pulling on a tab set apart from the pivot point of the camera, and becoming a rotational motion again.  Depending on how near the pull-tab is to the rotational pivot point, the rotational motion is either amplified (if it is quite near) or reduced (if it is further away).

I am very inspired by the work of Theo Jansen — massive “Strandbeests” which walk along the beach using dozens of legs powered by the wind. These sculptures are capable of mimicking natural — though often not bi-pedal —
gaits using mechanical linkages made from PVC pipe. Wind power is translated into rotational motion of a central shaft which powers the not-quite-linear motion of the legs. While the basic concept is simple, its execution reveals sophistication and experimentation in the path of leg transit and power-transmission from wind to leg all controlled by the lengths of various PVC pipes.

Interaction Observation

Point of sale interactions — and the systems which facilitate them — are among the most impactful and unfortunately boring interactions we have with technology on a day-to-day basis.  They are impactful because we use them for nearly every financial transaction at a store or restaurant and their usability (or lack thereof) affects our impressions of the vendor vis-a-vis trust, competence and ‘coolness.’ They are boring because their ideal state is one of being unnoticed.

Within my lifetime, I have used dozens of different POS systems: from traditional non-digital cash registers to a variety of card readers — manual entry (replete with flatbed printer), ’square’ style credit card readers or modern chip insertion readers. Within these different types of card readers, I have used dozens of different individual systems, and while each of them shares the same basic series of operations, the way these operations are broken down into steps for the customer and teller varies from one to the next.

“Gregory” Coffee App Payment:

Most recently, I have used the phone-app based payment system by the coffee shop Gregory, in which payment information is displayed on screen in the form of a QR code which is read by an accompanying reader at the coffee shop locations.

The use of this app involves the following steps:

1. Before paying, the customer loads the app, which displays a large QR code on-screen.
2. Below the QR code is a slider which indicates tip percentage, and can be slid from its “home base” of 0% to 10% and above.
3. When the teller has finished taking your order and asks for payment, the customer faces their phone screen toward the corresponding reader on the counter.
4. The reader has a strip of acrylic running around the perimeter, illuminated by a blue light. When the reader has picked up the payment information, the light changes to green to indicate payment information has gone through.
5. The app gives a notification of payment including amount. If set up, it also emails this information to the customer.

The entire interaction (less the actual order-taking) takes about 10 seconds at most.

Impressions:

I have used this system for a number of months — having been convinced to download the app by the promise of a free coffee. I had avoided these systems (which exist in many forms at many different coffee shops) since their introduction a few years ago because I feel they attempt to obscure spending and encourage less-conscious consumption through ease-of-use. My experience with the Gregory App has not disavowed me of this belief, but it is convenient:

  • It allows me to keep my wallet in my bag rather than my pocket.
  • It requires no signature.
  • It allows tip to be pre-set and retain that setting from transaction to transaction

My observations of other customers’ use of the app has revealed that:

  • Very few customers actually use the app rather than a credit card or cash.  I spent half of an hour in the coffee shop during a morning rush-hour and I was the only one who used the app and,
  • Of those I’ve seen use the app in the past, most seem to be seasoned professionals at its use.  Because the app is specific to Gregory, the only ones who use it are those who frequent this specific shop (rather than a generic payment system like Apple pay).  I suspect the limited scope is what makes the system simple to use.
  • The system requires tellers to enter the price twice — first they calculate using the iPad based cashier app and second they enter that price into the POS systems small keypad.  While this is a fairly small task, it is an example of a technology shifting responsibility to the employee because the two systems — the iPad used for most transactions and the QR code system — don’t play well together.

 

Electronics Lab

For week two of Physical Computing, we are doing a lab on basic electronics: soldering and switches.

I wanted to find a way to use a mini joystick from the electronics store in this lab.  The joystick has three possible movements:

  • forwards / backwards
  • right / left
  • pushbutton click

My first task was to discover exactly how each of these movements translated into an electronic signal.  On inspection, each of these movements had a separate set of pinouts.  Forwards / backwards and right / left had three pins each.  Using a multimeter to measure resistance, it became clear that the center pin was common, and the pins to either side corresponded to the movement in that direction.   The pushbutton click had four pins, but after measuring for continuity, it became clear that two sets of two pins were connected electrically.

 

I drew up the electrical connections in a (decidedly not standard) schematic-ish:

So, now I got to soldering.  First, I stripped my wires (which already had pin headers on one end), tinned them, and soldered up the sw

 

 

And hooked the four potentiometers (left, right, forward, backward) to four LEDs in line with a resistor:

Questions:

  • When measured with the joystick in the central position, the resistance between the center pins and each of the four directional pins is above the level the multimeter can measure (200M Ohms).  I assumed this was an open circuit.  The resistance when the joystick is pushed entirely in one direction is less than 20 Ohms.  However, when everything is connected up, the LEDs are lit (although dim).  I have two theories for why this might be:
    • I am misusing the joystick, which is perhaps meant to act as a control (with resistance measured by an Arduino or similar and mapped to a value in a piece of software) rather than actually pass current through it.
    • LED cathodes are connected on the +5V center rail, and the anode is connected to ground through the joystick.  Perhaps the anode end is at a different ground than the ground of the circuit… but that still leaves an open circuit with a LED lit…
  • I attached a number of LEDs in parallel to the pushbutton function on the joystick. Only some of them light up when pressed.  If I have (1) red and (2) blue LEDs, only the red will light up (which, I assume is due to lower resistance) until the red  is pulled and both blue LEDs light up.  What is the limiting factor here?  Is it the current put out by the power supply?  How would I light up all three LEDs?

 

What is Physical Interaction?

What is physical interaction?

In Chris Crawford’s “The Art of Interaction Design,” we are presented with a concise definition for interaction: “a cyclic process in which two actors alternately listen, think, and speak.”  This definition is general to all types of interaction and does not mention the means by which this interaction happens.  “Listen, think, and speak,” in this case can refer to any sort of interaction, not just verbal.  In our course on Physical Computing, however, we are particularly interested in physical interaction between humans and some sort of machine or computer.

Imagine two or more disembodied thinking entities floating in the ether, unable to speak or otherwise translate their private thoughts, emotions and wants to one another.  Without any means to interact physically (or telepathically), they cannot begin to conceive of one another.  It is only when you place these thinking entities within a physical body — either human, animal or machine — that they can translate their inner reality into a mutually intelligible physical form.  As these entities can now communicate externally (through speech, gesture, touch, musk, etc.), they can also make an effort to understand and respond to the communications of others.  Physical interaction is the means by which we both share our inner reality externally and respond to this sharing from others.  The limits of this interaction are the limits of our mutual inputs and outputs: a computer without a microphone cannot possibly respond to verbal commands any more than humans can respond to infrared signals.

What makes for good physical interaction?

In class, we were challenged to reject the idea of an intuitive interface — an idea that minimizes our unique experiences and unfairly assumes a shared experience or behavior — and instead focus on actually understanding those for whom we will design our various projects.  Indeed, that intuitive interaction is a fallacy should be obvious to anyone who has tried to explain how to use a specific piece of software to someone unversed in computers.  That said, those qualities that makes a certain interactive design or interface feel intuitive to its user are desirable.  What are these qualities?

— The results of our actions should be immediately apparent through some physical feedback.  Through consistent feedback on our actions, the underlying logic of the interaction becomes much easier to learn.

— The type of physical interaction should match the intended effect: moving a computer mouse is a good example of this: both the physical object and the digital avatar slide.

Examples of non-interactive digital technology?

— While a radio receiver may be somewhat interactive (in that we can adjust a knob and have the volume change accordingly), radio as a system is not interactive in that it is a one-way stream of data.

— GPS is a similar example of a non-interactive one-way stream of data accessible to its user through an interactive interface.

Questions:

What else makes certain interfaces feel intuitive?  Do they simply map a new set of commands onto an existing behavior?  Why is it that an arrow pointing up indicates almost universally that we are meant to go forward (and not upwards)?