Tiny Typing

Status: Complete

Text entry design for smartwatches.

Andy Shen & Diana Li & Renhao Hu

Background

As the shift to mobile and wearable technologies begins to surface, there is an increasing amount of importance in having a good design for user input. While phone screens may provide enough space for users to type into a keyboard, smartwatches don't have enough space to support a traditional keyboard for users to tap on. We explored this issue by developing an app for touchscreen smartphones to simulate a smartwatch and creating different designs for user input.

This project was an assignment for Designing Human-Centered Software, a HCI course at Carnegie Mellon University that teaches fundamental concepts in designing, prototyping, and evaluating user interfaces.

Requirements

Create a text entry method for a smartwatch

Size of the touch area is 1 inch by 1 inch (roughly the same size as the older 38mm Apple Watch. )

Text entry accuracy must be above 95%

Optimize for speed (i.e., words per minute) and intuitiveness

The character set only includes ‘a’ through ‘z’ and space. No caps, numbers or punctuation.

Trial Information

Each trial consisted of two randomly generated sentences pulled from a corpus that we would have to type (similar to typeracer). When we finished typing the first sentence, we hit the next button and enter the second sentence. After we submitted the second sentence, out speed (words per minute) would be outputted with additional penalties for words that were misspelled. The wpm with penalty was what we used to benchmark the speed of each of our prototypes.

Tech Stack

The app was created using Processing, an open source graphical library and IDE built for visual design. It uses the Java language with various simplifications. The apps were then run on android phones.

Starting Point

We were initially given scaffold code that contained a design with the current letter on the top half of the screen and a red button to move backwards a letter and a green button to move forwards a letter. To submit the letter, the user clicks on the current letter.

Some of the biggest observations we made with this design were the simplicity and the number of clicks required to submit a letter. While this design was extremely simple and intuitive, it takes around 13 clicks in order to find each letter in the worst case. Since wpm is correlated with number of clicks, we wanted to create a design that would maintain the simplicity but reduce the number of clicks required to get to each letter. After testing the scaffold code, we found that we could achieve roughly 2.4 wpm with that design.

Brainstorming

To start off, we began by brainstorming a couple of possible designs we wanted to explore. Some features that we thought we could potentially have in our design included autocompletion suggestions, handwriting recognition, and autocorrecting misspelled words to improve our wpm and decrease our error penalty.

Design 1

Our first idea was to have the keys lined up on the border of the smartwatch and the user would select a letter by sliding their finger towards the edge of the watch at that letter. The delete key would be located at the bottom left of the screen and the space key would be at the bottom right. The user confirms the input by tapping on the middle of the screen. This experimental design was inspired by the fact that we wanted to utilize the entirety of the space that we had available to work with.

Design 2

Our second idea was to have the keys lined up on the left and right edges of the watch. The first 13 letters of the alphabet and the delete key would be on the left side while the last 13 letters and the space key would be on the right. The user would select a letter by sliding their finger towards up and down the side of the watch. The middle of the screen would then contain suggestions for words that the user may be typing. We came up with this concept when we thought about the switches on analog watches and wanted to see if we could incorporate them into our design.

Design 3

Our third idea was closer to a traditional qwerty layout. The keyboard layout is the same as a regular keyboard except the p is moved to the third row because of spacing issues. We then separated the keys into groups of three. When a user taps into one of the three grids, swiping in the direction of the letter will result in that letter being output. For example, if a user taps in the middle grid and swipes up, a t will output. We also moved the space and delete keys to the top of the screen. While this design doesn't bring any drastic changes to the table, we wanted to see how effective a more traditional keyboard layout would do on a smartwatch interface.

Prototyping Process

Once we had our design ideas, we created prototypes and performed user testing on each iteration. In total, we created 5 prototypes. We ended up not implementing the first design because the screen wasn't big enough to fit the number of letters that we drew out in our design. The different prototypes can be seen here:

Testing Results

Takeaways

Traditional qwerty design is effective - People have become accustomed to the layout, making qwerty faster to use

Minimize number of clicks - The more clicks required, the longer users will take to complete a task.

You are not like the users - Our wpm was significantly higher than our testers, related to expert blindness.

Smartwatch screens are not too small for typing - While slower than keyboard, we still managed to achieve over 10 wpm, which can be further improved with additional optimizations.

• Date: November 2018
• Category: HCI Design

Close Project

Galaxy Defenders

A spinoff of the retro arcade game Space Invaders

View Project Video

Background

This project was my term project for Fundamentals of Programming, an introductory computer science course at Carnegie Mellon University that teaches fundamental of programming with emphasis on producing clear code using top-down design, informal analysis, and effective testing and debussing.

Tech Stack

I created the game in Python, along with Pygame, a cross-platform set of Python modules that contains computer graphics and sound libraries for Python.

Game Rules

The main objective of the game is to progress through the first four levels by defeating enemies and then beating the boss on the fifth level. The player defeats enemies by shooting bullets at the enemies. If the player gets hit by an enemy or by an enemy bullet, the player loses a life. The game ends once the player has 0 lives left or the player defeats the boss.

Game Features

There are four different types of basic enemies that show up as the player progresses through the game. Each of them have different movement patterns and abilities depending on what type of enemy it is.

Once the player reaches level five, the final boss appears. Depending on the amount of health the boss currently has, it will be in a different mode. The different modes include:

Dodge mode - Boss tries to dodge the player's bullets while firing back some bullets.

Tracker mode - Boss's bullets become homing and fires lines of three bullets at the player.

Collision mode - Boss moves at a high speed downwards towards the player.

Shooter mode - Boss shoots out a large number of bullets in front, to the left, and to the right of it.

Throughout the duration of the game, powerups may randomly fall from the screen. The two different categories of powers are weapon upgrades and health packs. Weapon upgrades can allow the player to fire multiple bullets or switch weapons to a laser that ignores bullet collision with enemy bullets. Health packs restore one health to the player.

Potential Add-on Features for the Future

Sockets to support multiplayer online mode.

Additional Powerups such as movement manipulation or a bomb that could clear the map.

High score table to track scores across multiple plays.

Takeaways

Object oriented programming principles - Principles of OOP such as inheritance helps with code reuse and modularity.

Balancing gameplay is difficult - Challenging to make the game fun and challenging and fair at the same time.

Managing a large codebase is challenging - Separating code into different modules was more effective than a monolith.

• Date: November 2015
• Category: Software Development

Close Project