Tag Archives: limits

Twitter experiments with 280 characters

I had first suggested a 280-character guideline for microblog posts back in 2014. As I’ve said many times since then, and through launching Micro.blog, I believe expanding the limit will make for better conversations, less mangled punctation, yet still remain short enough that it encourages quick posting.

Twitter announced today that they are also experimenting with a 280-character limit! From their blog post:

We understand since many of you have been Tweeting for years, there may be an emotional attachment to 140 characters – we felt it, too. But we tried this, saw the power of what it will do, and fell in love with this new, still brief, constraint.

They focus most of the announcement on explaining how the current constraints are different for some languages, like Japanese, which can fit far more words into 140 characters. That’s true, but it glosses over the most important point.

Longer text allows for more thoughtful posts, fewer misinterpreted shouting matches, and Twitter desperately needs to improve the tone of conversations on their platform. I’m a fan of this change.

Better software, less support

A few months ago “Ars carried a story”:http://arstechnica.com/journals/apple.ars/2008/10/09/slowing-economy-impacts-apple-call-center-in-colorado about Apple canceling a call center in Colorado. This part stuck out to me:

“Somewhat surprisingly, the iPhone 2.1 update was also named as one of the reasons for the cancellation. The software update has apparently been so successful at resolving iPhone 3G problems that its release has caused a noticeable drop in support calls.”

In this case it was just bug fixes, but it reminded me of “Getting Real”:https://gettingreal.37signals.com/. Make software easy to use and simple and then there are fewer things that can break and users are less confused. I have been obsessed with following this advice lately. Some of the limitations I’ve put in a couple recent projects:

  • No preferences (for Mac, no prefs window; for web, no options or settings screen).

  • Single toolbar (no status bar or need to look in multiple places, e.g. both the top and bottom of the window).

  • Minimal toolbar buttons (only the absolute basics are exposed outside of menus).

  • Opinionated defaults (no customization, similar to others above).

On a few occasions this has hurt my ability to add features, but on others it forces me to see a user interface problem from a new angle, something I wouldn’t have done if I hadn’t had these limits to work in.

Limiting features in an app does not come naturally to me, but the more I embrace it, the more value I see in it. I “tweeted a bonus side effect”:http://twitter.com/manton/status/1177252437 to this approach last week: “Maybe another reason why simple software succeeds: customers see in it all the possible features to come, implemented just right for them.”