Continuing in the process of creating expressive personal objects, I performed a piece called "Spinning Out of Control". I was working to express the feeling of anxiety that comes from trying to keep too many facets of life spinning simultaneously without assistance.
I'm working on a personal art project for my final in Designing for Constraints. The following is my first prototype. I feel pulled in many directions simultaneously -- with ITP pulling the hardest. The inner sphere represents me. The springs tug at me in all directions.
I developed this prototype from a simple sketch:
I built the prototype out of materials I already had in my studio:
 CD jewel case covers |  Old guitar strings and 24 gauge wire spun into springs |
 |  26 gauge wire wrapped around a still central armature |
Class feedback:
- Walls of the piece could deform under pressure.
- Piece seems performative -- it may require my performance of the object to get its point across. A video might help with this.
- Stretch the box to its limits and videotape it as it breaks
Aaron Siegel and Chris Peck and were guest lecturers in Audio Art this afternoon. Both compose works for untrained performers. This is one of the reasons I came to study at ITP. I want to design systems to enable untrained performers to collaborate musically.
Aaron's piece "Work in Manufacturing" was a percussive piece with fixed rules, but varying outcomes regulated by each performer's breathing. The rules of the piece made me feel disoriented at times because I had to keep a number of things in mind: how times I had inhaled or exhaled since beginning my current "station," how many "stations" I had completed, and the number I had chosen as my "jump" number for selecting subsequent stations.
The overall sound of the piece was intriguing, but I prefer tonal music.
Chris' piece "Worried Long" was a "choral" piece. I found it easier to appreciate the quality of the sound in this piece because it was richer and sustained. It sounded majestic as we sang it. I was very surprised at how harmonic it sounded -- even though none of us knew the intervals we were supposed to sing. Further, only about half the class was musically trained. I don't know how many of us could say that we know how to sing, but I really enjoyed the sound we created and would definitely consider it music. The dynamics were incredible and it was invigorating to belt out the slowed down lyrics with the rest of the class as we reached the climax of the piece.
I've been thinking about the discussion Amit and I had about believability. Both of the pieces seemed to have that quality. I knew nothing of the two composers beyond their remarks prior to performing the pieces, but it seemed that each piece matched the personality of its composer. Additionally, it was believable that we were creating the music together. Neither piece asked us to make an "impossible" committments in performing them. Collectively, we had all of the skills necessary to render the works. There was no need to think about which performers would be capable of properly interpreting their parts.
Improvisation
I've been thinking about musical improvisation. While it may seem on the outside like a flight of pure fancy, there is actually a systematic approach to it. My idea is that the improvisation system is composed of two main components: vocabulary and inspiration. I believe many people possess the inspiration to improvise, but few have developed the vocabulary.
I feel that vocabulary can be further divided into technique, motif, and progression.
I want to create a personal project which expresses the essence of improvisation, communicates the joy I experience while participating in musical improvisation, and invites observers to become participants in a musical improvisation. The participants will provide the inspiration and the piece will provide the vocabulary.
There are emotional difficulties to improvisation: lack of confidence and fear of embarassment, to name a few.
Randomness
Lisa suggested that randomness was perhaps a big idea to explore. We were talking about the idea that making musical expression - or more so - that the express ion of emotion (a seemingly random phenomena) through music requires a great deal of methodical / non-random- ordered, organized effort..
She wondered what sort of music might be produced it the keys on the piano were randomly arranged - tossed there - instead of their linear arrangement in ascending order by pitch from left to right. She wondered if it would be possible to make music on a randomly arranged keyboard.
Would that keyboard be reshuffled each time the performer play or even during the performance?
I cannot conceive of the possibility of developing technique on such an instrument. At the same time, I think this could have the potential to lower the barrier of musical communication between between a professional music and a beginner (or even a non musician) in a collaboration. If the professional musician do esn't have any technique on an instrument he will not be able to clearly express his ideas. If a situation of improvisation is created with musician and non musician under these constraints, perhaps they can have a musical dialogue on a level playingfield -- each able to break through his or her preconceived notions about musicality, expectations, goals...
Hot/Cold -- temperature or color
"I enjoy the rich, resonant bass tones of a Steinway piano - the warmth of those tones combined with the fragile glass-like tones of the treble notes"
Personality Types of Musicians
The Language of Music
MIT researcher Michael Hawley spoke to us in Red's class last semester about his projects and adventures. What stuck with me about his presentation, though, was his passion for live music. His presentation made me think about the idea that in the not so distant past, the piano was the home entertainment system. This sophisticated entertainment system required a nontrivial amount of learning in order to operate. What have we lost in giving up this formerly essential skill of playing the piano to merely playing the radio, CD player, or iPod?
I've been wrestling with ideas for the Final Project all week. Now it's Monday afternoon and we're going to discuss projects in class tomorrow night. The following are excerpts from my notes during the past week and a preliminary concept.
I started off listing... concrete ideas and potential questions to ask Amit:
I picked an area of interest and started mind-mapping from there... possible project ideas, audiences, and whatever else came to mind at the time:
I had a discussion with my mom earlier in the week about the design of library websites and wondered if I might like to do a project in this area. At the same time, I was also thinking about Maywadenki again and deconstructing something familiar to me: the piano.
From all possible ideas and areas of thought, I constrained myself to those which I was currently interested in: music and sound. This afternoon I began to further develop the idea of working with the piano as inspiration. An idea for a Process began to take shape, but is at this point incomplete. I liked Maywadenki's use of alphabetic characters to define their process (they have and A, B, C, D, E, F, G production process as well as the A-Z Naki nonsense machines). I wondered if I could use an acrostic of the letters PIANO to define my process.
I wrote a statement of intent for the project, but I still don't have a particular "user task" defined.
Ahn reviewed my prototype v1.1 on Saturday afternoon. The following are notes I took.
- He didn't understand that the "|30" notation indicated the current memory position
- He wanted to see the entire memory displayed as it is entered; had the idea to display each of the thirty characters as a smaller font
- He would like the < and > butons to auto repeat
- He originally thought the LED indicators meant there were three independent character sets
- I was reluctant to make any enhancements to the program... I already had so much invested in the program and tried to defend having to do more work.
- Ahn believes that reviewing the character memory would be a very useful enhancement to the prototype
- What about a pressable jog dial?
- I spent a fair amount of time explaining the operation to Ahn. This leads me to believe that the prototype as proposed is not as intuitive as it could be; one downfall is once you've entered a character, you can't go back and erase it. On the real machine you can.
After we met, I revised my software:
- Prototype now starts up in alpha entry mode which it didn't before. This gives the user a frame of reference to start from.
- Implemented auto repeat for the < and > keys
- Added "Not available" message for buttons that aren't implemented
[ Here is the latest version of the program ]
I also need to explicitly state the task I want users to accomplish, ie. "Please enter 'JACK.SMITH'"
Making a solid prototype takes time. I thought my prototype from last week was fairly solid, but now the switches won't move at all.
When I began planning my work, I had in mind something that would look like a cutaway from the side of the sewing computer:
I thought I would try to make a skin out of polymer clay in order to accomplish the feel of the real device. If I was analyzing the ergonomics of the device I would definitely concern myself with the form (and perhaps materials).
I started off by transferring the button spacing from my breadboard onto a perfboard. To do this, I took my buttons off the breadboard and punched them through the paper label that was covering them.
Once the buttons were placed with the proper spacing, I soldered them onto the perf board and ran wires. To keep things neat, I soldered a 7-conductor ribbon cable to the top of the board. I debated about whether it was better for the cable to stick out of the top or the bottom, but ultimately decided on the top so the prototype could sit flat on its side.
Three hours later, after drilling, cutting, and wondering if I should have drawn things out first, I had a solid prototype. The way I'm used to working, at least when I work with wood, is to draw detailed plans before beginning. Although I had an idea in my mind (see above sketch) of how the prototype was going to come together, I didn't know how all of the layers were necessarily going to get connected. When I discovered that I didn't have enough standoffs and the right size screws to attach them, I had to keep improvising. It reminded me a lot of playing with Legos when I was younger. I always seemed to run out of the one length of axle I needed and had to piece things together another way. In short, I wonder if it takes more time to hack something like this together, or to draw out detailed plans and then construct it.
It is definitely my tendency to want to lay things out in Visio or sink some serious time into Sketchup (even though I don't know it very well). Since I was working at home and didn't have the precision of the drill press, I felt that I might as well just improvise and keep working rather than wasting the day drawing plans I wouldn't need to use again. Yes, I would have had nice illustrations for my blog, but it wasn't worth the two or three additional hours. It's all about the constraints, right? Today's constraint was time.
After assembling the unit, I covered the button with cardboard to prevent electrical shorts. I didn't have long enough screws to go through the bottom of the IPAC2 and a sheet of acylic.
Lest I should give the impression that this week's assignment came and went without the requisite burst of madness, I did try to create buttons for my prototype.
That's right, I sculpted buttons... and they would have worked, but I ran out of steam when I realized I was going to need to drill another six holes in another sheet of acrylic. I may attempt this feat again before Tuesday. This is contingent upon first tweaking my code to recognize the new button assignments. The physical construction of the prototype encouraged a different wiring scheme from the one I used on the breadboard.
I've updated my operational prototype with the LEDs as Amit suggested in class. After trying them out, it seems I need to determine how they should behave after I've pressed the "A" button and I've used the ">" or "<" to go out of the range of the characters indicated by the new LEDs.
Options:
What do you think?
I'm also wondering for the final prototype if I need to expose the "mem" and mem "<" buttons. They are not completely necessary for the operation I want to work with: setting the name. The "<" button allows review of the current items in memory. Is the idea here to simulate everything or just enough to show the concept we're trying to improve?
Building the operational prototype was time consuming. It took more than twice as long as the paper prototype.
In the paper session, the burden of patience and imagination was on the user. I feel like paper prototypes will be good for illustrating concepts and refining them. The audience for the paper prototype should be a colleague who is either familiar with the process or has some background information about the operation you are trying to evaluate. Otherwise, I think too many things must be explained. For example, I had a discussion with a co-worker this morning about a design I was working on. Having a rough sketch from my tablet in the correct scale gave him a better idea of the idea I was trying to communicate so he could make constructive comments about it.
I think the operational prototype may be most helpful when I'm looking for actual user feedback on a particular operation. The test subjects can and should be far removed from the design process. The user can perform the test with a minimum amount of explanation.
Advantages of the Paper Prototype
- Rapid design, redesign, and refinement
- Low committment of time and attachment to design
- Lightweight, portable
Disadvantages of the Paper Prototype
- Inaccurate sense of the time required to perform an operation
- May not be useful in assessing the ergonomics of the operation
- Requires user to have knowledge of the problem domain; ie. what are we trying to assess? what needed to be left out? what exact operation must be performed?
- Requires a patient user
Advantages of the Operational Prototype
- Accurate indication of time required to complete operation
- Allows user to enter much more fully into the interaction (they can forget that you are there watching and simply concentrate on performing the task)
- May be very good for selling the concept beyond immediate colleagues
Disadvantages of the Operational Prototype
- Can be time consuming to produce (compared with paper prototype) and may develop a deeper personal attachment to the concept or idea. Perhaps delegating the task to another can help avoid this
- Requires greater attention to details of the interaction (again more time)
I think the operational prototype allowed me to really confirm that the operation took less time. It was clear to see (just based on the time of the videos alone) that it was a much shorter process.
To improve the interaction quality when entering characters into the stitch memory of the Bernina 145, I propose additional functionality for the existing "A" button. The sewing machine currently jumps to the "A" character when the "A" button is pressed. Nothing happens currently if the "A" button is pressed repeatedly.
I propose that pressing the "A" button will cycle among three commonly used "jump points" in the list of characters: "A", "0", and "_". I believe this will accelerate text entry because it will allow the current character "cursor" to jump quickly in a list of 59 characters. (As an aside... I have to wonder why there are only 59 characters in the list. Why not one of the 2^n numbers?)
Tomorrow evening I will film my user interaction test using the software prototype I developed this evening. It would be very easy to get carried away with making a realistic mockup of the Bernina, but I did my best to stick to the bare
essentials.
I asked my wife to operate the paper prototype. When I shot the video, I had her enter the whole string. This was torturous for her -- and I had her do it twice: first without the improved process and then with it.
I learned several important lessons from constructing the prototype and from her subsequent testing with it:
- It is important to cleary communicate the desired operation. In our first testing session, we forgot to use the Alpha button to jump back to the beginning of the alphabet.
- It is worthwhile to think through (or even mockup) the interaction before building the prototype. I had devised what I believed to be a clever system for scrolling through the numbers on my prototype which involved pulling a long tape of the characters through a window on the paper control panel. It was a clever idea, but it didn't take into account the spatial orientation of the paper control panel. I had a mental model of horizontal scrolling in my head when vertical scrolling would have been much better for this application. When I discovered this flaw, I had already produced a full version of the prototype and was reluctant to fix it. As as result, it was difficult to pull the numbers horizontally past my wife's hand without bunching them up.
Analysis
The time spent operating the prototype and then subsequently editing and uploading the videos was substantial. Although I have videos of both interactions, I have only posted the first test. Notating this interaction is quite unwieldy. After consulting with Amit, a more useful test would have been to concentrate my efforts on analyzing the part of the interaction that was particularly frustrating: having to scroll through the entire character set to get to the "." character. Amit suggested that I could have focused simply on entering "N.S" and notating that.
I edited the process of entering "[AT]SERVER.COM" out of the video I've posted above and as a further extension could even edit out everything except the "N.S" of from "JOHN.SMITH". Qualitatively, I do feel that the improvement I've suggested will make a big difference -- especially for long strings. My wife mentioned that she doesn't usually use the machine's memory for long strings because they take so long to enter -- and it can be difficult to remember the characters she has already entered.
Today I'm going to learn to sew... so I thought it would be most important to be able to write letters with the sewing machine. Since I'll soon be creating garments for myself, it would be very useful to sew my email address in them, in the event I lose them.
Description
My wife's Bernina 145 Sewing Computer is very well designed and extremely usable. I had never tried to operate it before and found that I could navigate its controls without opening the instruction manual. I even figured out that the Bernina 145 can stitch simple alphanumeric characters into fabric. My wife has found that the interface for entering characters into the stitching memory is pretty weak. As I'll demonstrate in the videos of the operation, it takes many button presses to navigate through the character set. I believe the character-entry process could be improved without even adding any buttons to the control panel.
The initial operation I began testing was entering "JACK.SMITH[AT]SERVER.COM" into the machine's memory.
The following video documents my attempt to complete this operation.
Analysis
It turns out that notating and evaluating this particular operation is a greater level of committment than I had anticipated. There are many, many button presses. There are also a number of ways to complete the entry
Objective: Change the selected voice to "DreamRodes"
Assumptions: TG77 already in VOICE mode and on MEMORY I (internal). (1)
Notation (2):
[Button]
\ - Press
/ - Release
* - Number of repeats
s - Number of seconds
Ex: [Y \ /]*52 / 10s
I have produced short movie clips illustrating each of the ways to select a new voice
(1) This assumption is made to constrain the number of possible ways to change the voice. Without these assumptions, it would be necessary to consider many other paths from different modes. This study would be useful in the evaluation of the ease of use of the Yamaha TG77 in live performance. In live performance environments it is crucial to be able to switch quickly between the most important modes related to the performance.
(2) I considered an XML-based notation format, as I thought it might be useful later on to have the format easily machine-parseable. It seems from first glance that there is a heirarchy of presses and releases. By nesting presses, it is easy to see what happened and when.
<Yes/><Yes/>
<Yes>
<Left/>
</Yes>
This is likely overkill, so I'll abandon it for now.
I have two suggestions related to voice selection on the TG77:
1. Implementation of a "jog wheel" function in order to scroll through the voice names at variables speeds
2. Implementation of a "search" function to locate the voice without having to scroll through the various banks
"Jog Wheel"
Interestingly, the TG77's keyboard-counterpart (the Yamaha SY77) has a rotary wheel control which can be used to scroll through voices. I wonder why the designers didn't do this for the TG77 using the DATA ENTRY slider.
The video below shows the mocked-up jog wheel operation. The DATA ENTRY slider on the TG77 doesn't have a function when the unit is in Voice Display mode, so I feel this would be a logical use for it. I mocked up the interaction by holding down the "+1/YES" button while moving the slider.
Notation:
[Slider /] / 3s [Slider /] / 2s = 2 operations / 5s
Notes:
This interaction raises several interesting questions.
1. How quickly should the slider move through the voices? A rotary knob with detents has an implied mapping: 1 voice per click. The slider has no detents.
2. What happens if the slider is at the top of its range when the user wants to jog through the voices? The answer to this question is related to how we answer #1... This probably is an area that requires some user testing. Unless moving the slider back down a bit will allow access to the full remaining range of voices, this could
be very frustrating to use. The data entry slider on my Studio Logic SL-1100 behaves a bit like this -- and can be frustrating.
Voice Search
In Voice Display Mode, only two of the function buttons are used (F7 and F8). Another button (F6) could be used as a "Search" button. Pressing "F6" would cause a search dialog box to appear. I think dialogs are beyond the scope of this assignment.
Test 5: Selecting the "DreamRodes" voice by direct numeric entry
When the DreamRodes is selected in Voice display mode, the upper left portion of the screen displays "VOICE-I D05(53)", which translates to "Voice Mode, Internal Bank - D, patch number 53". Using this knowledge, we can jump immediately to the DreamRodes any time we have the Internal memory bank selected.
Buttons:
"5" - [5]
"3" - [3]
"Enter" - [E]
Notation:
[5 \ /]*1 / 0.5s [3 \ /]*1 / 0.5s [E \ /]*1 / 0.5s = 3 operations / 1.5s
Quality:
If you know the number of the voice you're selecting, this is the way to go. It requires the least number of operations in the least amount of time. The downside is that it requires what Donald Norman refers to as "knowledge in your head" of a system. You must already know the voice number corresponding to DreamRodes.
Notes:
I assigned short durations to these button presses as they are located close to one another.
Test 4: Selecting the "DreamRodes" voice by using the voice directory
Buttons:
"F8", to be abbreviated [F8]
"Bank/Select", to be abbreviated [Bank]
"Right Arrow", to be abbreviated [>]
Notation:
[F8 \ /] / 1s [Bank \ /]*2 / 2s [> \ /]*1 / 1s = 4 operations / 4s
Quality: It is much easier to find a voice when you can see a bunch of them at a time. The downside of this method is that you must be close to the face of the unit in order to read the names.
Notes:
When the TG77 is in Voice Display mode
the F8 button displays a list of the voices.
Test 3: Selecting the "DreamRodes" voice by pressing and release the "+1/YES" button in cycles
Buttons: "+1/YES", to be abbreviated [+1]
Notation: ( [+1 \ ] / 1.5s [+1 /] ) * 12 = 24 operations / 18s
Quality: This seems better than simply holding down the "+1" button if you're looking for a particular instrument.
Test 2: Selecting the "DreamRodes" voice by holding down the "+1/YES" button
Buttons: "+1/YES", to be abbreviated [+1]
Notation: [+1 \]*1 / 7s [+1 /]*1 / 0s [-1 \ /]*1 / 1s = 3 operations / 8s
Quality: It is very easy to overshoot the desired voice while holding down the "+1" button. This technique is not recommended if you don't remember the name of the instrument you're looking for.
Test 1: Selecting the "DreamRodes" voice using multiple presses of the "+1/YES" button
Buttons:
"+1/YES", to be abbreviated [+1]
"-1/NO", to be abbreviated [-1]
Notation: [+1 \ /]*52 / 10s [-1 \ /]*2 / 1s = 54 operations / 11s
Quality: While pressing [Y] rapidly, I found it was easy to overshoot the desired voice. I would like to try this with someone who is unfamiliar with the instrument as I have grown accustomed to the names of the instruments which precede "DreamRodes"
Note: The video segment lasts longer than the reported 11 seconds because I found later that I could press the button more rapidly than I did while filming and still read the name of the voice.
I built a base for the clock last night and asked Kelly to try reading the time. We learned several things in the process:
- Tracing a circle is difficult when you can't see. Kelly didn't have a sense of the size of the outer ring with her eyes closed, so her fingers went off the ring several times. Each time, she had to return to the 12 o'clock index marker and start again.
- I built a prototype with a visual mapping that doesn't correspond with the way we speak the time. Since Kelly and I have been using clocks for a long time (although she can read the non-digital ones much more quickly), we expect the longer hand to always point to the number of minutes. When I designed this clock, I thought the outer ring should also represent the minutes in order to mimic the way we're used to seeing a clock. This would be a positive thing for a visually impaired person with memories of clock faces. For a person blind from birth, however, this visual/spatial mapping doesn't exist. The way we speak the time, "four forty-nine, pm" rather than "eleven minutes to five o'clock, pm" defines a mental sequence: hours, then minutes. With this mental sequence, it makes sense that the outer ring is the hours and the inner ring the minutes. Despite our visual/spatial maps, Kelly and I both found our minds wanted to use the outer ring to represent hours when our eyes were closed.
- 12 != 1 != 0 (or twelve doesn't equal one doesn't equal zero). Another problem of the traditional clock face is tied to starting with twelve. Kelly experienced difficulty remapping the 12 o'clock position as zero when she couldn't see the clock face. I realized that it doesn't make sense if you haven't grown up looking at a clock. My instructions to her were to "trace clockwise around the circle, counting each depression until you reach the raised marker." I could either clarify my instructions or try another prototype which addresses some of these issues.
I began to experience firsthand some of the blocks we put in place as we consider designs. I stereotyped the user of my clock (in this case a visually impaired or completely blind person) as a sighted person in several key areas.
I started with another approach to the clock design. I wanted to try prototyping a tactile clock face that would eliminate the need for a talking clock. Allistar noted in his blog that "[s]tyle is something that’s also apparent - never assume because someone is blind they don’t embrace style. After all others can see us."
I wanted to see if I could propose something more stylish that would be enjoyable for both sighted and blind people.
 |  |  |
To tell time using this clock, the user begins by locating the raised marker at the 12 o'clock position on the outer rim of the clock face. They move their finger toward the center of the clock (moving up two levels) until they find the depressions on the hours layer. Starting at the 12 o'clock position, they will trace clockwise around the circle, counting each depression until they reach the raised hour marker. To determine the number of minutes, they return to the 12 o'clock marker on the outter rim and move their finger toward the center of the clock (moving up one level) until they find the depressions on the minutes layer. Starting at the 12 o'clock position, they will track clockwise around the circle, counting each depression until they reach the raised minute marker.
In class on Tuesday evening, we were given a problem to solve in ten minutes: design a clock for a blind person. This short exercise became the first assignment of the class. Although I played with several concepts, only one stayed with me through the end of the ten minute brainstorming period. I proposed a talking clock.
I began by brainstorming what I believed to be the user's needs:
- Telling time on demand
- Waking up at a specific time
- Easily setting the time
As I started sketching from there, other needs emerged:
- Reliable power source (AC line voltage + battery backup) so the blind person should be able to obtain the current time under either battery or main power failure conditions
- Volume control in order to avoid unnecessarily disturbing others
- Automatic time setting radio signal
When I returned to the problem yesterday afternoon, I researched current products marketed to the blind and visually impaired:
 Pyramid talking clock |  Talking Thermometer Clock I wonder how the blind or visually impaired person will know where to aim the infrared remote. |  Keychain clock Seems similar to a product that might be used to "remember everything" |  Simple clock |
My initial impression was that few appeared to have been designed specifically with this market in mind. I did find a another design feature to inform my previous brainstorming:
- A heavy base with non-slip feet might be useful for the blind
I researched braille numbers in order to see other possible ways to design the clock.