With the software which you can download on Github here- it comes with several standard applications – one of which is a keyboard that allows users to type. For people like graffiti artist Temp, this is a truly amazing way to communicate to the outside world which once was not thought possible. When viewing this keyboard (shown on the left – second image from the top) I initially felt there were several aspects of the keyboard that could be improved upon:
1) The rollover/click state is indicated by the button fading into a saturated green. This fading affect doesn’t give the user much of understanding to the amount of time required or remaining for the click to initiate.
2) The window is jam packed with buttons and thus doesn’t give the user much space to rest there eyes after they typed or are waiting for a response. Because of this there is also a limited amount of space where text is displayed. I wanted to create a text area where more sentences (or even paragraphs) could be typed.
3) The IA felt like there could potentially be some consolidating of features or even use of non screen real-estate. Potentially numbers, shift, and delete functions could be removed from the main key area and placed on the external limits of the screen.
4) I felt that typing required an increased up and down motion of the eyes to check what has been typed when it could potentially be displayed infront of a users eyes at all time.
With these problems in mind I created a design with the large black typing area and a green chalkboard keyboard selection area. Overall I felt this redesigned keyboard organized the buttons in a more intuitive manner and allowed for clearer click state (with a black character filling effect), a cleaner work space with a single row navigation, and a reorganized UI with non key letter buttons (shift, numbers, delete) placed outside the screens width. With this Apple Dock appropriated design finished – I seeked to create an app that would fulfill this image. As it proved, the Apple Dock lens effect was more difficult to code than I anticipated. After struggling to get the dock to function as I wanted, I decided that I needed to get something functional in code to begin user testing to determine if this interface actually worked or not.
When I began my tests I found that the standard keyboard that comes with the eyeTracking software performed fairly well even with it’s minimal design and button filled screen. In comparison to a linear alphabet (similar to the one proposed in my design) – I could not type as fast. The results from my tests are below:
Standard Keyboard
Font-family: Helvetica Neue Med
Font-size: 16
Button Dimensions: 100×100
Type speed (“HELLO”): 17 seconds
Errors: 4
Single Line keyboard
Font-family: Hand Times
Font-size: 48
Button Dimensions: 50×50
Type speed (“HELLO”): 57.5 seconds
Errors: 5
Font-family: Hand Times
Font-size: 68
Button Dimensions: 70×70
Type speed (“HELLO”): 49 seconds
Errors: 4
Font-family: Hand Times
Font-size: 90
Button Dimensions: 90×90
Type speed (“HELLO”): 1:12 seconds
Errors: 1
After reviewing my results I found that at a button size comprable to the standard keyboard I was able to achieve the same results with fewer errors, but it took me much longer to achieve this. So is this a viable keyboard or not? For now I think it is not the correct solution, but I do believe the error reduction is something that can be learned from in my next iteration. Without a rowed approach it is more difficult to hit the wrong key. I’m also interested in the Dasher (bottom image on the left) software that Kyle and Greg showed me which claims to achieve 29 words per minute with eyetracking software. Perhaps the predictive text route is the way to go…
Lastly, I’d like to thank everyone who helped me throughout this project. ITP is truly a wonderful place where magic happens, but the support of everyone on the floor helps to keep everything flowing. I plan to continue this research to one day have a better eyeTracking keyboard for the physically handicap.
Audio was added in post-production.
- Response decay – an emotional response is of relatively short duration, and will fall below a level of perceptibility unless re-activated.
- Repeated strikes – Rapid repeated activation of an emotion causes its perceived intensity to increase.
- Temperament and personality influences – A person’s temperament and personality influence emotion activation and response.
- Nonlinearity – The human emotion system is nonlinear, but may be approximated as a linear system for a certain range of inputs and outputs.
- Time-invariance – The human emotional system can be modeled as independent of time for certain durations. For short durations, habituation effects occur. For long durations, factors such as a person’s physiological circadian rhythms and hormonal cycles needed to be considered.
- Activation – Not all inputs can activate an emotion; they have to be of sufficient intensity. This is not a fixed value, but depends of factors such as mood, temperament, and cognitive expectation.
- Saturation – No mater how frequently an emotion is activated, at some point the system will saturate and the response of the person will no longer increase. Similarly, the response cannot be reduced below a ‘zero’ level
- Cognitive and physical feedback – Inputs t the system can be initiated by internal cognitive or physical processes.
- Background mood – All inputs contribute to a background mood, whether or not they are below the activation level for. emotions. The most recent inputs have the greatest influence on present mood.
In Picard’s explanation she treats emotions similarly to a weighted signal or wave-form. I found this really fascinating as it is a very clean and digestible way to visualize a complex process. I tried to recreate this process with a real-time affective signal in C++ and openFrameworks. The image on the left is a screenshot of what the output currently looks like. This prototype signal incorporates strikes, saturation, repeated strikes, a response decay and activiation properties. I’m continuing to add more of the properties to it to eventually have the full signal model and hope to have this complete by the end of the week.
Overall I felt that focusing on Picard’s book was a breakthrough for me because she does an amazing job of breaking down a complex process. She also provides great details on each variable and how it relates to a mathematical equation. Although there are some clear flaws in some of these equations they certainty are great step forward for emotional computing. I also appreciate that she doesn’t necessarily provide any code and I feel that her explanations are so rich that it is a very rewarding experience to transfer her notes into a real algorithm. I plan to continue to refine this signal and then move onto her next chapter. I’m still undecided on what my final product will be, but I’m excited to continue to get my hands dirty with more programming.