mobile has moved well beyond a simple tap or drag.  call it the tinder-ization of mobile, but users now routinely gesture, swipe, flick, pull, drag, long press, and hard press.  the more i delve into building mobile apps, the more i notice the finer points of how these features are and can be implemented.

there’s nothing quite as telling as handing someone a new build of an app i just completed and see what they expect to interact act with and how.  from these interactions, plus being an avid downloader of apps, the one constant i’ve noticed is how there is no ‘rule of thumb’ for gestures.  some email clients archive by swiping left.  others by swiping right.

routinely apps will go so far as to build in tutorials of how and why you should swipe.  i’ll expound upon more examples and ideas throughout this post, but i’ll begin with this -- the basis for how i’ve come to think about mobile gestures.

where web navigation is directional,

mobile gestures are relational.

if you want to go to the bottom of a web page from a computer, you scroll your mouse downwardly or peck away at the down key.  but if you’re on your phone and want to go to the bottom of the article, you swipe up.  moving away the content you’ve read and pulling up the new content into view.

if you want to view the next photo in your scroll, you swipe the current photo out of the way to reveal the next photo. 

if you want to view a menu or some sub action, you move an existing view out of the way or drag in a new view.

this primary difference with mobile is virtually opposite to previous web-era user experience design, but it’s also more natural.  watch a baby play with a phone, and they get it.  how your fingers interacts with glass on a screen is almost innate.  so as mobile developers and product people, how do we design for the best (defined as logical + magical) experience?

short answer: follow tinder (which is also how apple defines gestures), don’t buck convention, and pay close attention to context.  

a quick definition before we continue: swiping right means moving your finger from left to right.  if the focus of the interaction is visible, the object should move and/or dismiss to the right.  thinking swiping away a card on google now, or dismissing a swarm message after your last check in.

but if the focus of the interaction is not visible, new content should appear from the left.  think scrolling through photos, or moving to the next day or week in your calendar.

getting the right direction of a gesture was something i struggled with during the latest update to airbear.  i wanted to make it easy to move between different days, especially since this is where monetization kicked in.

the airbear feeding home screen

i had different implementations on my phone, showed people to see which way they would expect to swipe, and received ranging reviews.  most said it didn’t matter, that they’d learn which way to swipe.  throw on top my natural inclinations towards backwardness as a lefty, and i was stumped.  


so after shipping what i now consider that wrong implementation, i started studying gestures.  i want to build more in my apps, but i also don’t want users to have to learn something new or worse be confused.  as intercom recently published about some of their user testing, they were seeing users swipe left to dismiss (largely because of tinder habits).  even google gets things mixed up, as it tries to buck this swipe left to dismiss convention.

really? swipe right?!?

best practices for winning at mobile gestures

1) context -- does the user have a natural sense that an element is swipable?

without a nudge (or ugly tutorial) a user won’t know that some nuanced element of your ui will register a gesture without being primed.  table views do this by default (such as text or email).  movement that presents the element can also accomplish this, as well as also giving a glimpse of further content (such as a new screen or subview blurred by the layer on top).  arguably the only time a tutorial is acceptable is when the ui is so simple that an app needs to orient its users with all of the features that are invisible, discoverable only with swipes, such as what clima -- my favorite weather app -- does.

2) direction -- which way(s) should a gesture be received?

follow convention (tinder and relational as discussed above), but don’t limit the ways in which a gesture can work.  e.g. twitter only lets you dismiss an image vertically, whereas slack recognizes any gesture direction and then pleasantly spins the image out of view.

3) multi-function -- are there options other than gestures?

while users acclimate themselves to expect more gestures, build in other ways for users to interact with your product.  sure a gesture might be the best way to move between days in airbear, but the user can still tap on the individual days to move directly.

4) bespoke magic -- can you implement a common gesture in a new way that speaks to your product?  can you move gestures beyond navigation?

especially as long and hard presses become more expected, delight your users with some magic that speaks to your product.  robinhood did this by having users confirm a trade by swiping up.  facebook messenger did this by having the size of your ‘like’ determined by how long you hold the like button.

 

in the end, we’re still in the very early days of mobile ux and gestures.  guessing most people don’t use them to their potential or realize how ubiquitous they really are.  as a side experiment to this post, i’m running a poll to see how many people use gestures on their notifications.


Posted
Authorjonathan hegranes

the perfect product balance makes the user both love and hate the experience.  the love comes the way the product solves the user’s problem and the way it makes them feel in the process.  the hate stems from the love, because by loving the product so much the user wishes it did even more.  any place in between is product ambivalence -- a no man’s land where projects and companies die.

perfect product pacing starts by solving a clear problem and shipping a simple first version of the product, only moving on and building more when the love and hate are sufficient and growing.  you start by having a meaningful first product, but as as reid hoffman, co-founder of linkedin and now vc at greylock, says, “if you’re not embarrassed by your first version, you’ve waited too long.”

too often an inexperienced founder will hesitate and struggle to get that alpha or beta out the door because they are tuning and building in fear that the current version isn’t polished or doesn’t do enough.  even experienced but undisciplined product managers will make this mistake, bolting on too many features without justification.  the key is to have an early thesis of why specific users want what you’re building and set out to prove this with as little code, development, employees, and cash as possible.  

this is the tact i took with airbear.  for sure early brainstorming and mocks crept towards a bulky v1 product, but i ultimately got it down to providing one clear value prop -- simple breastfeeding logging that lets parents know how that day’s feedings are going.  users noticed this and responded.

over 10,000 feedings later, positive reviews, and lots of love were also met with plenty of criticism.  what about bottle feeding?  why can’t i see the history?  seeing x or y data would be useful? can you add alerts?  this level of hate and wanting more not only showed me that there was an audience for airbear, but also showed me what i should work on next.  

you know you’re on track when you get angry feedback because that never comes from ambivalent users

arguably the greatest value this diligent method of product pacing provides is not having to go back and rework or delete old, stale features.  probably half of my day job these days is stripping out old features or irrelevant functionality that was built too soon and without justification.  des traynor, co-founder at intercom gives a great talk that compares two products.  one is a simple product that sees its competitor with tons of features and thinks ‘we need to add those’.  meanwhile that bloated product sees the simple one and thinks ‘i wish we didn’t have all these features, which are hard to maintain or that no one uses’.  

beware of product envy and build only when the time is right and the love and hate buckets are overflowing.  some of the best products today did that, even with millions of venture capital in the bank.  nothing shows prudent product pacing quite like the time between launch your iphone app and android.

if people love your product, after around the first few dozens of users you will start hearing requests for android.  these four companies clearly had the love factor, but they still waited on average for almost a year and a half to launch on android (and you can be sure that a lot of hate was piling up during that time).  if you’re curious how other great companies progressed and paced, there’s a cool site that lets you explore their timelines in more detail -- http://www.startlin.es/timelines/

part of being a release note connoisseur means i also spend a lot of time looking through version history.  how, why, and when app updates are pushed tells a lot.  granted big mega corps like facebook or twitter are on a bi-weekly cadence of ‘minor improvement’ updates, but the early days of an app show the most drama.  big new features come out after a quarter or two of listening and talking with customers.  these can be the hardest months as it’s easy to just want to keep shipping new stuff.  but it’s when you have hundreds of users (as opposed to millions or billions) that you have the freedom to both wait and be bold.  

code cleanup and performance stuff aside, resist the temptation to ship new stuff. wait to see not just how many people are using your product but also how they are using it (which could surprise you), and by all means focus on growth.  that’s the road i’ve been on since launching airbear in february, and i’m excited to announce a long awaited update in the itunes app store.  

with the last airbear update, we are now just at step #2.  if we’re going to get to step #3, that’s going to take even more hard decisions about product pacing.  they may have the same number of wheels, but a bicycle is far more complex with far greater potential.

what step is your product on?

Posted
Authorjonathan hegranes

users can both feel how much care you put into a product, and how much care you didn't put into it.  this is often why big companies can't win because they have to scale.  or at least they think they do.

actually doing things that don't scale is difficult in practice, but your users will notice the difference and feel the love you put in and the time you took to make everything just so.  a great example of this is acompli versus inbox, wherein you have a small startup trying to make a great email app and inbox, which is google's latest email evolution.

i'm actually a fan of inbox and use it for my personal email on my laptop.  lovely animations combined with easy navigation make it wonderful, except that google refuses to do things that don't scale.  

in a day where i took both an uber and lyft, google inbox has put these in different buckets.  you'd think they would take the top 50 or 500 apps vendors and create specific rules for them.  manual, yes.  tedious, a little.  but perfect.  your email app, especially google, should know the top 100 finance companies, top 100 travel companies, etc, etc.  if you want to algorithm results after that, fine, but get the fat part of the curve exactly right.

meanwhile acompli has a better 'focused' inbox than google's priority inbox.  it recognizes actual people better, while also pushing aside newsletter type stuff that truly isn't priority.  just guessing, but i'm assuming a lot of this was done through very inefficient means.  at least at first, while they were ramping up.

the result was microsoft bought acompli for $200 million, and to microsoft's credit did not undo the magic.  they kept it open, kept it beautiful, and didn't make it too outlooky.  i'm still getting used to having outlook on my phone, as i hadn't used it for a decade, but it's still the best email/calendar option i've found on the iphone.  i just hope they keep putting the same care into the product.

 

Posted
Authorjonathan hegranes

six months ago i became a dad.

six months ago i started coding.

today i’m announcing air bear! 

you can read all about air bear on our medium post 'babies are hard' about how we’re helping new parents with feedings and providing a little sanity along the way.  or just go straight away to download the app :) 

 this is a story of how air bear came to be.

going back to last summer, apple had just announced swift, my friend dorian was starting a #codeaday challenge, and my wife was about to give birth to our baby girl.  together, these were the beginnings of what has become air bear.

anyone will tell you that i’m a sucker for anything new (i.e. chewing new cinnamon-roll gum as i type this), so apple’s new programming language was already enticing.  swift is the heir to objective c, which had been around since the early 1980s. pretty much every app on your phone today is built on objective c, but just comparing some of the syntax and features of swift vs objective c and it’s really quite beautiful. and from my perspective (a total noob), more intuitive.

coding has never been my day job, but always something that i’ve tinkered with. i’ve taken a few ruby classes and enjoy fiddling around with different technologies, but doing the actual building was a first for me.  it’s a skill i wanted to start developing for a number of reasons, as it helps me think about and understand products at a much deeper level, but it’s also a necessary skill if you actually want to be able to implement ideas on your own schedule.  as @fakegrimlock says, ‘if you not code, you not understand code’.

from "how to startup" v0.5 by fakegrimlock

figured i better get harper learning git at an early age.

figured i better get harper learning git at an early age.

so between swift and dorian, my brain was in the right space. harper -- our daughter -- was the inspiration.

one of my favorite posts by paul graham is ‘how to get startup ideas', where he says to work on a problem you have, and my problem at the time was the freshly minted baby that would wake up every few hours to eat.

we had taken baby classes, read books, etc, etc, but as this was our first kid, we didn’t know what to expect and i quickly noticed some repeating themes.  there was the question we’d ask 10x a day -- “is it time to feed the baby?” and that was topped by the number of times we’d wonder -- “is this normal???”.

naturally i looked to the app store for help.  

 
while there is invariably an app for everything... there is rarely a good app for anything.  
 

i pretty much refuse to use an app that doesn’t look good, especially the icon.  with existing baby apps, i had to throw that rule out the door right away.  while a lot of tracking and logging apps are functional, they are not easy to use, and certainly not fun to use.

so wishing i had a better way to know if our baby was eating well and when the next feeding was coming next, i set out to build air bear.

the first few months were all about learning.  learning what is a good feeding schedule.  learning what parents need and want.  and learning how i might actually build this thing.

after talking to a lot of parents, observing what hacks and systems my wife came up with, and armed with some base development skills -- it was finally time to start building.

making something simple is not easy, and the air bear concept had already ballooned into too much.  so the first step was narrowing down what air bear would be.  initial thinking was to track feedings, bottles, diapers, health stuff, and maybe even memories.  we may get there over time, but we needed a place to start and feedings are the most important.  it’s the thing mom’s track the longest and care about.  frankly something they’ll care about forever.  

but even after deciding to *just* start with feedings, i still ended up writing and later deleting more code than i needed.  i thought about collecting the birthday or birth stats like weight and height, which are useful but not totally necessary.  after distilling further and further to the root problem i wanted to solve, i got down to a what i think is a beautiful and simple minimum viable product.

i love this tweet by @manicho about a good mvp and hopefully air bear is closer to the second row than the first --

so this version of air bear in the app store today is the skateboard you see at stage one.  and what stage two will be is still to be decided.  i have a lot of ideas of stuff i want to build and new features i want to incorporate, but i’ll largely be looking for feedback from early air bear users.  what they love, what they hate, and what they want to see next.

please go download air bear on the app store today .

  (while you’re at it, please give us a 5-star review :)

 

(while you’re at it, please give us a 5-star review :)

and if you know of any new parents or those that are expecting, please do introduce them to air bear.  i’d love to hear their thoughts and feedback.  leave a comment below, or shoot me an email <jon@airbear.co> any time if you have any ideas for the app, for parents, for anything.


lastly, so many people to thank.  my wife has been amazing and supportive as i asked her *lots* of questions about breastfeeding, and super patient while i spent early mornings and late nights working on air bear for the last few months, especially when i was grumpy because there was some damned bug that i couldn’t yet figure out.  aaron who as been great to work with, kept me in check, and who designed the amazing air bear logo!  throughout the process, lots of friends have been awesome with feedback, support, and making really cool introductions to fellow new parents who might want to use the app, or to baby and lactation experts that have shared their wisdom into what nursing moms need to hear.  thank you <3

and there's also been so many amazing technical resources (besides stackoverflow) and experienced people that have helped along the way.  just a few of my favorite new people -- whether they know it or not -- are

@jonkawa, who provided some unique wisdom along the way.

@mengto, who is a design and animation magician.

@jamztang, who writes killer stuff on ios.

 & @awolnation, which has become my favorite early morning coding music.

Posted
Authorjonathan hegranes

top-down or bottom-up is a classic question with many potential contexts.

how do you model your company?  without question, bottom-up.

how do you view economic policy?  already the answer gets more gray and depends on personal feelings.  which way you lean will direct your answer.

how do you display a feed?  this question doesn’t seem to have a definitive answer and it’s the one that got me diving into this no mans’ land of product philosophy.

i have to bash twitter from time to time because it sucks at so many things (their persistent notifications problem befuddles me).  yet, twitter is still one of the first places to go to see “how did they do it”?  and twitter is the epitome of the top-down or bottom-up question.

the twitter new feed is top-down -- with the most recent posts at the top.  yet in the very same app, they use bottom-up for direct messages -- with the most recent messages at the bottom.

whenever using any product, i love to ask the question of “why did they do this?”  and i find that the answer usually falls into one of two buckets:

  1. genius product insights from amazing design, ux, and customer involvement

  2. copying someone else

the problem with copying is that while you know it works (at least you hope it works since at least one other idiot did the same thing), you also have no idea into the why.  you don’t know if that was done for legitimate, customer-centric reasons -- or simply because that company shipped it that way for whatever reason, or lack thereof.

after going through my phone, the one trend i can see that determines top-down or bottom-up is what i’ll call “purposeful interaction”.

if the product is simply displaying new content that you’ve (implicitly) subscribed to or followed, then it just flows on top…  examples being:

  • twitter (news feed)

  • podcasts

  • instagram

  • soundcloud

  • email

if the product is more like a dialog, then every new message goes to the bottom… examples being:

looking at these examples, it does make sense for purposeful interactions to be bottom-up -- because you want to see the last message you're replying to when your keyboard pulls up.

of course, there are products that are starting to evolve beyond a simple top-down or bottom-up.  facebook is top-down, albeit highly filtered and algorithm-laden.  but then there’s examples like disqus, quora, or reddit which try to elevate the best content to the top -- whether that data is two seconds or two years old.


 

Posted
Authorjonathan hegranes

without question, my favorite part of any product is the feeling you get from using it.  sometimes this means an extra feature or a cool animation.  sometimes it’s the fact that nothing happens at all.  sometimes it stems from not letting you do something, in a good way (i’m looking at you, twodots).  sometimes it just makes you feel good.

the beauty of this feeling is that it endears you to the product in a way that cannot easily be copied, and more importantly ties you to that product for much longer time frame.  

i’ve long admired this in products… back when i worked at disqus, i did a thing at an all-hands where i jokingly trademarked the “point of tap” as *the* opportunity.  and a lot of my recent thinking about the right interactions has led me to dive into this more deeply.

we all do the same things every day, whether it’s buying a cup of coffee or downloading a new app or logging into a site.  and all it takes is a little bit of magic to pretty much forever connect with that person for life.

philz coffee does this by not only making you an amazing cup of coffee, but when they hand it to you, they say “make sure it’s perfect”.  how perfect is that?

headspace does this with the absolute perfect loading animation…  not to mention their videos are spot on.

taking lunch as an example, there are variables that lead up that moment where we order or take our first bite.  and then there’s how we feel afterwards that is more of a direct correlation of the product / service we just consumed.  but in the middle is a no-man’s land of either magic or blah.  

we don’t always realize the blah, but you’ll respond to the magic -- consciously or subconsciously with your heart, mind, and wallet.

the other fascinating thing about this is the same process can still feel really different.  i’m still not sure why this is, but a commit to github via the terminal just feels better than using the github app.  buying a taco after waiting in a long line feels different.  getting surprised / amused at something mundane feels really different.

alexis ohanian and tim ferriss (on tim’s podcast) go into this a bit, and kevin (aka, best twitter handle ever) had some really good examples in sam’s startup class.  #mustwatch

i realize this (magical ah-ha state of utter stupid bliss) is both really hard but really easy to do.  in the end, it’s a game changer and something i’m striving for / focused on intently.

Posted
Authorjonathan hegranes