L8R interaction: Work in Progress

Spoiler Alert! This post ends with questions, not answers. I’m posting it to share how I’ve been thinking about a critical design problem: How are people going to L8R things? Knowing what L8R is is nice, but not essential ☺

The most important principle for capturing image reminders is immediacy.

This means minimizing the number of steps between the intention to act and the execution of action.

With L8R, the user’s intention is to create an image reminder. This consists of a few steps: capturing the photo, optionally tagging people or adding text, and designating a trigger to schedule it:

The first step, capturing a photo, is the most urgent one. The world will not hold still. So we have a few requirements:

• Home screen is a live camera view
• Maximize real estate for preview image
• Capture button is big and obvious
• Minimize time between tapping button and capturing photo

Despite these affordances, we’ll never beat the native Camera app when it comes to immediacy. The 2 “unfair advantages” it has are:

1. Swipe up from locked screen to open app
2. Use volume buttons to capture image

We can make up for these disadvantages by closely pairing the capture task with the schedule task, completing the user’s intention of creating an image reminder. (Doing this with a combination of Camera and Evernote took me +15 steps.)

Various triggers are possible for scheduling a L8R. The most immediate need is for a “time trigger,” but a good solution will anticipate the introduction of “geo triggers.”

Apple’s UIDatePicker is the most obvious kind of time trigger, but is not the best tool for the job with L8R. Picking an exact date is a secondary use case; snoozing to a future date (tomorrow, next week, next year, etc.) is the primary use case.

The right set of snooze options is TBD, but for now let’s assume we have a lot: Right Now, In an Hour, Tomorrow, Next Week, Next Month, Next Year, Pick a Date.

What’s the best way to display this set of snooze options?

If we have no opinions about which the user is most likely to choose, a flat structure makes sense.

This has a few advantages:

• The user has a sense of what options are available to her
• No menus = fewer taps
• No conflict between triggers of different types (temporal, geo, etc.)

But a flat structure has its own set of problems:

• Becomes difficult to process as # of triggers grows
• Potentially obscures the preview image
• Boring and grounded in task management tools
• Doesn’t match the mental model for L8Ring

What I mean by the last point is that tapping a button is not innately tied to the idea of sending something to the future. We could just as easily be sending the photo to a friend, categorizing it, flagging it as inappropriate, whatever.

We could remedy this by displaying an animation after the button is tapped — maybe the image flies off on a paper airplane. This is OK, but better is if the interaction itself reinforces the mental model.

What is the mental model we want the user to have exactly?

• L8Ring should feel like a relief, like work off the user’s plate
• A L8R’ed photo should disappear, but with the hint that it will return

These considerations led me in early prototypes to make L8Ring a more physical interaction. Here, the user drags the capture button and pans it to select a trigger:

This interaction is appealing for a few reasons. First, there’s something nice about reducing the input of “the world” into a ball for the user to manipulate. Second, we’ve now created a virtual timeline on which the temporal triggers sit.

This interaction is unappealing for a few reasons:

• It is bizarre and unfamiliar
• It removes the preview image from the user’s workflow — the assumption is that she will need to tap the L8R ball if she wants to see exactly what her photo looks like
• The options are no longer laid out clearly
• Thumb gymnastics may cause discomfort for the user and is more error-prone

Maybe most damaging, this kind of interaction doesn’t really adequately capture the physics of relief. We’re not shooing the L8R away so much as scrubbing it along an axis.

For better physics, we might look to relevant tools:

But it’s hard to imagine incorporating slingshot or boomerang physics without actually building a game around L8Ring (which, yeah, maybe…).

These interactions might serve as effective post-scheduling animations, but expecting the user to pull back a slingshot and launch a moment into next year takes us into strange territory.

Are there interactions in the wild that we might co-opt for use in L8R? I’ve always been interested in Twitter’s profile pull-down:

I can imagine the user tugging slightly to increase the time trigger (this mapped to pulling a slingshot), and releasing to schedule, or pulling all the way back to expand a menu.

This kind of direction is almost certainly taking us into “power user” territory, and would need to complement a more obvious interaction.

Creating a separate mode for power users is typically frowned upon, but I’m not so sure it can’t work — especially if the “normal user” mode hints at the “power user” mode.

For an example of this, we can look at Apple’s own Messages app. The first interaction is tapping the camera icon, the second interaction is long-pressing it.

The Messages app reveals this behavior to us via the record icon on the other side, which can only be long-pressed to function (and tells us so when we tap it).

A tap/long-press dual interaction may work for L8R, although it prevents us from using long-press for video in the future.

In order for it to succeed, it will need to be discoverable, worthwhile, and actually fun.

To be continued…