Posts tagged Input methods
Think Aloud
Jun 29th
The UX Group recently had a session in which fellow Grad Student Amy Gill (who was wonderful!) spoke about her research into the Think Aloud method and how we can use it as practitioners. Perhaps the first thing that came to mind was “isn’t it just a usability test method?” but really it’s a psychology method that we’ve taken and applied to our field. We often forget the origin of the methods we use, but the origins can provide us with a helpful refresher on when and how we should be using these methods.
![]()
The Think Aloud method was originally developed for use in Psychology to – surprise! – learn about thought patterns. Originated in 1980 by Simon and Ericsson [1], the theory was a new way of thinking about psychology, recognizing that thought patterns were important and that behaviourism wasn’t necessarily the right path to truly understanding the human brain (ask me about behaviourism another time…). In any case, they proposed that verbal reports can be taken as valid data as long as they are reports of a certain level. Level 1 reports require the least amount of processing – information that is already stored in the brain as verbal code is simply vocalized. Level 2 reports require some processing – information stored in a different format (visual, spatial) is recoded and articulated as verbal code. Level 3 reports require generation of new material that does not already exist in the brain, such as explanations of actions. Of these three levels, only the first two can really be assumed to be valid reports of brain thought patterns thought to interfere to a limited and negligible degree.
What does this mean for usability? Amy explained that perhaps the most distilled point that we can get from the psychological origin of our method is that we shouldn’t ask “Why?”. We should ask it afterwards if we want to really delve into the whys of our participants actions, but not during a Think Aloud task. We want the users to give us an honest and unfiltered stream of consciousness to better understand the mental models they are forming as they use our interfaces. We don’t want them to start analyzing what they’re doing, or giving us the first answer that seems plausible, or telling us what we want to hear.
There was a lot of confusion and some claims of “I ask Why, and it’s worked fine!”, but I think we should keep in mind that Think Aloud is really a method aimed at collecting a specific kind of data: mental models and thought processes. When we want to make sure that our understanding and view of the interface matches up with the user’s, we should use Think Aloud. When we want to see where a user becomes confused, or when the mental processing they have to accomplish in their head becomes overwhelming, we should use Think Aloud. However, when we want to gain an indepth understanding of how and why a user would use this interface, and how well it meets their specific process needs, we might not want to use Think Aloud – maybe consider contextual inquiry or one of the many other useful tools in a usability practitioner’s toolbox.
In either case, Amy’s talk made me think about two main lessons that often get lost in the day-to-day: 1) understanding the history and roots of a method can clarify how to really use it, and 2) pick the data you want, then the method – not vice-versa!
[1] Ericsson, K.A. and H.A. Simon, Verbal reports as data. Psychological Review, 1980. 87(3): p. 215-251.
Text Input Methods
Apr 11th
Moving forward requires rethinking things. Sometimes, this might mean rethinking things that most people would think can’t be rethought. Take the paradigm that we currently have of for text input: the keyboard. The keyboard is large and cumbersome, or it’s hard to use when it gets small. Tactile feedback is important, or you have to watch your keyboard the entire time (iPhone, anyone?). Additionally, the keyboard presents some major issues for accessibility, and for people who like to write in multiple languages or alphabets.
The standard qwerty keyboard was designed as such to simply prevent the likelihood of two keys being typed right after each other, as this could cause typebar crashes, a serious mishap in the typewriter days. But, after it became standard, there was no real opportunity or drive to change it back to anything more useful or thoughtfully designed. There are supporters of alternate keyboard layouts, but they are within the minority, and tend to be constrained to re-programmed keyboard input devices.
Recently, I heard some friends discussing how pointless a new text input device developed by a grad student seemed. They said “you’d have to learn all new patterns!”. Are new patterns really any different from what we all had to learn when we figured out where the keys were on a keyboard? Could there be a text input method lurking out there that is miles ahead of what we all spend hours using every day?
Take a look at some interesting new text input methods that are out there right now:
- Dasher
This entry method uses one directional input to construct sentences. As you pick a letter, you move towards more letters that are only available if they make sense after the previously chosen letter. How does one create words that aren’t real words? That’s my only question. There is an interesting video showing how it works here.“Dasher is a text-entry system in which a language model plays an integral role, and it’s driven by continuous gestures. Users can achieve single-finger writing speeds of 35 words per minute and hands-free writing speeds of 25 words per minute. Dasher is free software, and it works in all languages, and on many platforms. Dasher is part of Debian, and there’s even a little java version for your web-browser.”
- Swype
This method has a standard keyboard, but it is used by drawing lines connecting the letters in the word. The algorithm then figures out what you are trying to write. Apparently you can even miss letters and it should figure it out. This will greatly depend on it’s predictive ability, but would be much better than trying to type on a real keyboard, and doesn’t require relearning of keyboard ideas.

- EdgeWrite
This sounds like what my friends were talking about. Here, you are confined to a box with a stylus. Different combinations of swipes on sides and diagonals of the box create different letters. Seems hard to mess up, once you’ve memorized the combinations. But perhaps that’s too big of a barrier?

KeyBowl
Each hand holds a dome, which can be rotated. Different combinations of angles create different letters. This keyboard claims to be more ergonomic and prevent strain injuries. Again, the issue lies in having to re-memorize key placement.

I think the biggest issue with all of these types of text input is the fact that the keyboard is still so prevelant. I know that I get very confused when I switch between my laptop and desktop, simply because the ctrl button is in a different place on each. Imagine trying to keep motor memory for two different kinds of text input! I would not be surprised if there were major gains in speed and accuracy for people using a text input other than the keyboard, but they will likely have a lot of trouble switching back to a normal keyboard if/when they need to. On the plus side, it might be a good security feature if no one else knows how to type on your computer!
