I don’t like Twitter threads.
In most cases, if something takes more space than one or two tweets to say, it’s easier to read as an article. It’s especially bad with very long threads, and those that aren’t crafted to make each tweet a unit. When sentences continue on from one tweet to the next as if they’re only line breaks, it makes it hard to pick out a statement to highlight, or where to start.
On the plus side: Tweets are more likely to be seen, more easily shared, and people can interact as they’re posted, like a live conversation. A thread that’s crafted to fit in 140-character chunks has a rhythm to it, like a daily comic strip collection vs. a comic book. And an unplanned tweetstorm gives both the writer a chance to get their ideas down quickly and the reader a chance to see them unfiltered.
Compared to an article, a tweetstorm provides immediacy, and any Twitter thread provides reach. But they’re still a pain to read.
Also written (of course) as this twitter thread.
Infinite scroll is like finishing a sandwich, and the server plops another one in front of you without asking what you want on it, or if you want it at all. If you’re full, or you don’t like what they chose? Too bad, it’s on your plate now! To make matters worse, sometimes if you put the sandwich down for a moment to eat some chips, they’ll think you’re done and swap your sandwich for a different one!
Slate just replaced pagination with infinite scroll on their articles. Yes, pagination sucks. A multi-page article on the web is like a burger that’s been sliced up into wedges, and you only get one wedge at a time, forcing you to go back to the counter every few bites. But infinite scroll isn’t an improvement.
Both approaches impose the wrong structure on a single unit. Search results and timelines are one thing, but for an individual piece of content, the best way to map it to a web page…is to just map it to a web page.
Update (Sep 2016): Combined with giant images and complex layouts that slow down browser rendering (*cough* CBR), it’s even worse. To continue the lunch analogy:
- You order a sandwich with a cup of soup and a side salad.
- After an interminable wait, you get the sandwich and soup, but no salad, and no spoon. The waiter rushes off before you can say anything.
- Eventually you’re able to flag someone down and ask for the spoon and the salad.
- You munch on the sandwich by itself, which is at least a decent sandwich.
- Finally the waiter comes back with a whole pizza, and takes away your half-eaten sandwich.
- You still don’t have a spoon, but that doesn’t matter because the waiter took the soup too.
Fury after Facebook messes up smartphone users’ address books:
Remember how Facebook sneakily changed your default email address to @facebook.com? … Some smartphone users…are reporting that their on-phone address books have been silently updated to make @facebook.com email addresses the default way to send a message to their contacts.
The lesson: Whenever you change something, always consider the impact on things that depend on it.
This reminds me of the ill-fated Network Solutions attempt to replace failed DNS lookups with responses directing web browsers to search pages, not considering that web browsers aren’t the only software that uses DNS, or that some of that software might depend on accurate “this domain does not exist” info.
Originally posted on Google+
Some recent linkblogging. (Thank you, StumbleUpon)
I use the Broken Link Checker plugin on this blog and on Speed Force to find broken or moved links. In addition to helping you manage them in the admin interface, it can also assign formatting (as a CSS class) to mark them in your posts.
Cool! Readers can see that the link is broken before clicking on it!
But what’s the best way to label the links?
The plugin uses strike-through by default. You are marking something that’s gone, but strike-through usually means the text is being crossed out. That’s fine for a link in a list, but something like “Catering was provided by
MyNiftyFoodCo” implies that the name of the company is wrong, not that the website is gone.
Just making something italic or changing the color doesn’t work either, because it’s arbitrary. Nothing about an italic link (which could be a title), or a random other color, suggests that something might be missing.
What I’ve come up with is to reduce the contrast on broken links. It combines two familiar schemes:
- High contrast for new links and low contrast for visited links.
- “Graying out” inactive items in software.
So here, I’ve got bright blue for new links, darker blue for visited links, and broken links as black (well, very dark gray), the same color as surrounding text. I’m keeping the underline in place so there’s still some indication that it’s a link, but it’s not as strong as the label for one that’s still functional.
It’s still not ideal, since color is the only difference, but it should cause less confusion than the strike-through.