UX RESEARCH: New NAVIGATION + CREATION FLOWS IN IpHOne APP
How can we re-design our existing iPad app to fit the iPhone?
At Hopscotch, we undertook the ambitious project of designing a block-based mobile programming interface for the iPhone. We had an iPad app, which, because of the wider screen real-estate, afforded a split-screen design. To fit the same functionality on the iPhone, however, we had to rethink the high-level navigation, and creation (programming) flow. We studied navigation and creation patterns across various apps, built paper prototypes and tested them with new users.
A few design goals defined our study. We wanted creating on Hopscotch to be 1) fast, 2) intuitive / easy as possible and 3) satisfying in a way that building things in real-life is. As such, we focused on two experiences: the navigation and the creation flows.
How can we simplify navigation? The current iPad navigation requires a lot of space and asks the user to switch between screens often. How can we we simplify the navigation for iPhone so there are fewer switches required when creating, editing across characters is faster and there is less cognitive overhead required of the user to figure out "where I am"?
How can we simplify the creation flow? The current iPad creation flow is very inconsistent - i.e., depending on what type of "thing" you are adding (e.g., object/rule/block), you go through a different flow - the add button is in a different place, the confirmation state looks different. How can we make the overall design more consistent and streamlined, so that the user doesn't have to learn multiple flows, and the design feels more intuitive?
SKETCHES AND PAPER PROTOTYPES
To simplify navigation, we tested the idea of a collapsible list view where all code for the project is available in one single view. instead of the current iPad version where you can only read code in character views (i.e., to edit code between characters you need to go navigate out of the first character and then into the second, a minimum of 3 taps)
- The notion of a collapsible list was intuitive to users. It enabled fast switching between objects.
- Many users don't name their objects, therefore, when the list is collapsed, they all look the same...
- Beginners with few objects like using the map for navigation because these users spatially recall where an object is. In more complicated projects where there are many overlapping objects, the map is a hairy, difficult source of navigation, and a searchable list would be preferred.
=> Important to still provide a way to see the map and navigate via the map if desirable
=> Important to identify objects in some unique way in the list (e.g., nudge users to name them, show a mini-map representation)
To simplify creation, we tested a design that borrows from text editors and the emoji keyboard. In this design, different 'things' (object, rule, block, parameter) are represented by different keyboards. The keyboard changes based on where the cursor is in the text editor, i.e., depending on where you are in the coding hierarchy and what type of 'thing' you are trying to add.
- Very intuitive to users; Kids are particularly familiar with the emoji keyboard
- In the iPad version, adding an object was confirmed by seeing the object appear on the map. This confirmation made it very clear that you are creating "a world" and that these objects are "tangible" things in your world. It makes something seemingly abstract, more concrete. However, this notion of concreteness is lost in this iPhone design because adding an object is simply confirmed by seeing the object added to an abstract list. Concreteness is important especially for beginners.
=> Adding objects should be confirmed by seeing them appear on a map, otherwise the keyboard design was intuitive to users and allowed good consistency across creation flows.
Based on this research, we launched the iPhone app in summer for 2016. It received a Fast Company Design Award and was featured by Apple numerous times.
Hopscotch for iPhone and iPad has been downloaded over 7MM times.