Notes after writing a long, participatory thread on Twitter
(This is meant for the Twitter design team, but feel free to read and comment if you want)
I recently wrote a 427-tweet thread that a great many people contributed to, with many wonderful replies:
It was a great deal of fun for me, and I am not sure this could’ve happened anywhere else but on Twitter. However, creating and maintaining the thread was painful, and — much more than ever before — reading and participating in it seemed also to be painful to others.
This is a list of my observations and suggestions on how to make it better. I don’t know how common this use case is, and how exactly it relates to other Twitter/threading use cases; I wanted to share this in case there’s something useful in here.
I bolded my suggestions so it’s easier to scan this quickly.
Setup: I used my iPhone 6S to take photos, and posted most of the tweets using the official Twitter iOS app on the same phone.
1. Threads are slow to load
In the iOS app, opening any tweet in a thread shows it immediately, but the context of the thread (surrounding tweets) and the UI to append to the thread are slower and slower to load the longer the thread gets.
This feels like an unintentional punishment for creating longer threads. It’s there for me as a writer, and — more importantly — it’s also there for readers. Currently, looking at the later tweets in the thread (example link to one) on good wi-fi takes over 90 seconds to load the surrounding context and UI. (And looking at it on cellular made me worried about data charges, as it seems consistently slow and therefore probably not cached?)
It seems like this could be optimized to load in constant time (perhaps show the first few items in the thread and then a Load more item, in between, similarly to what’s done in notifications?). Or cached once loaded. It’d also be good — and it feels like good practice — to see the related UI (Add another Tweet button) appear immediately without having to wait for the content. Lastly, some sort of a loading indicator would be nice to add, although perhaps only if the thread is expected to be long.
(The desktop web experience doesn’t seem to have that problem.)
2. There is a nasty scroll up bug
In the iOS app, if you open any tweet further down the thread and scroll up or down even just a bit before the context/UI finish loading (or even attempt to scroll)… the moment they do, you get moved up all the way to the top of the thread, losing whatever orientation you had.
It’s really confusing at worst, and infuriating at best, when you understand what’s going on but — after having waited 90 seconds and accidentally touched the screen and scrolled it— are still powerless to stop it.
Please fix this bug. It’s been there for so long.
3a. It seems easy to lose track of the thread
As you read, the thread gets truncated at some point, with responses to the “selected” tweet (the tweet with big letters) taking over. There is a call to action to keep reading the thread, but it’s tiny and that makes it easy to miss it — and that assumes you know to look for it.
The call to action also says X more replies, not using the word “thread,” even though the UI to enter the thread calls it that (Show this thread).
Even when you find that call to action in the middle of scrolling and tap on it, you’ll have to fish for it next time, too, as the responses to the original tweet keep hanging in there at the bottom of the chute.
(There is also a bug you could see above, where for some reason the number never goes above 171? That might add to the confusion — you tap it once, scroll down, and the number remains the same.)
3b. The conversation UI seems confusing, in general
The above three problems — slowness, scrolling bugs, extending UI — contribute to the confusion, but I think even without them it’d still be hard to participate in a conversation where people respond to various tweets in the thread. Here’s a sample of the problem:
I don’t think people intended to respond with the same answer despite others having done so before them. I believe they responded because they never saw the other answers.
This was the first time I actually wrote a little explainer…
…and I had so many questions — on Twitter or otherwise — about how to read the replies to a tweet in the thread. It’s confusing (here are some comments), even if it’s explained to you: the replies to the “selected/current” tweet appear nowhere close to the tweet but far below, separated by 30 subsequent tweets in the thread.
I have a few tactical suggestions:
- Make the “tap here to extend the thread” UI more visible, and tie its label more to the notion of a thread (right now it reads as replies from others).
- If you tap on the action to extend the thread, consider making the initially “selected” tweet not selected any more — or at least remove the replies to it from the bottom. This way, reaching the end of the visible part of the thread will also mean reaching the bottom of the scrollable chute, Fitts’s Law and all that.
- When you start navigating within the thread (e.g. tapping on various tweets to make them “selected”), maybe reduce the distance between the currently “selected” tweet and the tweets replying to it from 30 to much lower? Since the intent of the reader is then to engage with the replies first, and the thread later.
I do have a sense that a more profound redesign of this entire UI would be in order, however, to better accommodate threads with replies to them.
4. It’s hard to stay on top of notifications
The very moment your tweet/thread become nanoviral, your notifications get shot. It feels like the service punishing you for doing a good job. Two things in particular are frustrating:
- You can very quickly run out of notifications buffer — you scroll back and at some point the notifications just stop without any warning. If you don’t want to miss out on a reply to you, this forces you to be on top of your notifications, and that’s stressful. I talked about it a bit more before. One idea would to be to extend the notifications buffer. The other, to perhaps allow you to paginate notifications, or allow to choose a specific date and be more intentional about reading notifications than just the rudimentary (and getting slower and slower) infinite scroll.
- Notifications pane has two modes: All and Mentions. I expect the second tab to also include quote tweets, but they’re not there. That forces me to use All not to miss anything — and wade through tons of likes and retweets that are not pertinent. Suggestion: Please add quote tweets to the Mentions view.
5. It’s easy to make a mistake and mess up the thread
If you mess up and continue the thread not from its last tweet, the whole thing breaks — you can follow up to the beginning from a misplaced tweet, but you will no longer be able to read the entire thread when you start from the beginning.
This makes sense, but it feels too easy to arrive at this state. It happened to me twice in the above thread alone, where I later had to delete some tweets and republish them in the correct order. (Leftover proof where someone else helped me figure it out.)
I think a feature to reconnect/reshuffle tweets in a thread would be an overkill. Making the UI appear faster (as per above) would help. Perhaps there’s a chance to introduce some sort of a thread end mark, maybe even visible just to the author? It could be a typographical glyph, or it could be just a change in the UI. Right now in my own stream the last tweet in a thread has the same text as any tweet before: Show this thread. Maybe there’s an opportunity to make the last one special?
6. It’s hard to keep track of which photos were already included
Managing photos is a small private hell: choosing photos to be portrayed, remembering to filter them, remembering which ones were already used. This is mostly on iOS, not on Twitter. As a matter of fact, Twitter has a pretty good photo selection UI.
However, one feature request that would make this so much easier: when I’m selecting photos to be attached to a tweet, please indicate (gray out?) photos I already attached to (other) tweets before.