… treading carefully to fix threading carelessly.
The Flowdock team recently delivered an awesome feature called re-threading, that you can read about in a previous blog post. It’s something our users have been craving for a long time. Hell, I’ve been craving it for a long time. I’m one of the people that builds Flowdock. I’m supposed to be a power user that glides effortlessly through my flows, commenting here and replying there, in tune with the bots and integrations. But I thread fail. It’s not that I don’t know what I’m doing, or that an insufficient quantity of derision and public shaming has been heaped upon me. It. Just. Happens.
My own particular weakness actually happens after I’m in the right thread for a while, chattering away. I see a notification in the same flow, and I close the thread to check it out. Then a new comment to that thread appears in the flow, and I just gotta respond. Like now. And… ugh, not again.
I was pretty excited when the team started working on this feature, and I was particularly excited about bringing it to mobile.
We immediately faced some challenges though. When you are designing a feature for a mobile app, there are constraints that don’t exist anywhere else. Screen real estate is scarce and precious, of course, and we must always be thinking about battery life, network stability, memory constraints, and other behind the scenes things. In the case of rethreading, gesture contention became the most critical concern.
Let’s back up a bit and talk about rethreading on the web and desktop clients. They have two flavors of rethreading. In the first, you can just tap the rethread button and your wayward message gets tacked onto the end of the previous thread. That’s perfect for those times that you realize your mistake the moment that you make it. In the second type of rethreading, you can grab the chat bubble or reply arrow and drag it to any other thread in your flow. Sounds great, right? Well, let’s think about that in the mobile world. It’s a world devoid of nice sharp mouse pointers and stuffed full of stubby fingers and thumbs. Touch points are not precise.
It’s a world where you can’t look back more than a message or three without scrolling.
In Flowdock, as in any other communication tool, the screens all scroll. How do you scroll in mobile? Simple – put your finger on the screen and move it. How do you drag something in mobile? Simple — put your finger on it and move… oh that’s not gonna work. We just hit some gesture contention. We could probably do something with multi-touch, but it would probably mean having two different fingers trying to do two different things, and the human mind just doesn’t work that way. It would not only be difficult to do, it would be almost impossible to discover.
Let’s back up one more time and talk about a different feature that was recently delivered to our mobile apps. It used to be really difficult to edit a message on mobile. You had to find the message in the flow, then tap it to open the thread, then tap the Edit button at the top of the thread, then find your message again and tap yet another Edit button on the message itself to open an edit screen. Ugly. Now users can pop directly into the edit screen using 3D touch (iOS) or long press (Android). Users love this feature, and we don’t want to take it away, so it is another area of gesture contention that must be avoided.
After much discussion, we decided not to bring drag-drop rethreading to our mobile platforms.
We’ve done some user analytics research that tells us our users mostly want to rethread the message they just posted, and mostly want to attach it to the thread just above it. That’s the point of the one-touch button on the web and desktop clients. It’s the right approach for mobile, because it not only avoids the horrors of drag-drop and trying to suss out user intent, but it also neatly avoids any need to drop a message onto a thread that is likely off screen.
On to the implementation! It turns out that Android and iOS have subtle differences that affect how we are able to deliver this feature. Android users are very comfortable with long press to bring up contextual menus, while iOS users are more at home with 3D touch to “drill in” to an interesting object. That makes an easy decision for Android — add a rethread item to the long press menu. We choose not to support long press on iOS because it is such a similar gesture to 3D touch, so we needed a different solution for our iPhone friends. We decided to put a rethread button directly on each qualifying message cell.
It only took a few seconds to realize that was wrong.
It served the need of keeping the most important features at the shortest distance to the user, but it left all of the screens looking cluttered and messy. One more compromise had to be made. On all the other clients, almost any message that you author can be moved to a different thread. That includes replies and solitary messages (a new thread that does not have any replies yet). On iOS, you can only rethread solitary messages. That may seem like a significant limitation, and maybe it is. At the moment though, we believe that a significant majority of rethreading will be covered by this seemingly narrow definition. The result is an interface that remains clean and uncluttered, while still making the power of rethreading available when you need it most.
I’m not convinced yet that we got it right; you’ll have to judge for yourself. Feedback is most welcome!