Grow your CSS skills. Land your dream job.

Features Are Complicated

Published by Chris Coyier

Why can't I edit my tweets?! Twitter should allow that.

It's so simple right? CRUD apps (Create, Read, Update, and Delete) are app-building 101! What a gross oversight. But wait. Just as a fun nerdy little exercise, let's think about what a feature like this might take for the Twitter team. I don't work there or have any inside knowledge, so this is all hypothetical for the sake of understanding app development.

  • Should you be able to edit any tweet you've ever tweeted at any time?
  • Or should you just have a few minutes to do it until it locks?
  • Do you offer this to everyone? Opt-in? Opt-out?
  • Should you be able to edit tweets or direct messages also?
  • What does it look like to edit a tweet? Can it be simple and obvious? Does it need additional UI? How do you expose that UI? Is it worth the extra UI?
  • Does the tweet go out to the public timeline immediately or after the editing grace period?
  • What if someone favorites a tweet and it is later edited? Does it shed the favorites? E.g. a tweet that originally said "I like pancakes!" could be later edited to "People that favorited this like clubbing seals!" (or much worse).
  • Same question, with retweets. And with replies.
  • Are there any social or moral implications of this?
  • How does tweet editing affect the overall feel of using Twitter? Would a time delay affect that feel? Would people think of tweets differently?
  • Does tweet editing make hacked accounts an even more dangerous prospect?
  • How do third party clients handle tweet editing? Is there a public API for it? How complex is that?
  • Or do you only offer tweet editing through the web? How does that move go over with developers?
  • How do you ensure third party editing offers an up-to-par UX? Does that matter?
  • If tweets aren't time-delayed, how do you handle edited tweets through the API? - How do you tell third-party clients to update a tweet they are currently displaying rather than show a new one?
  • Where do edited tweets go? Back on top of the timeline, or stay where they are?
  • Should it be visually displayed that a tweet has been edited? How do you enforce that in third-party apps?
  • Are there legal implications here? What if someone tweets something illegal and then changes it to something legal?
  • Does tweet editing open up any kind of bad guy behavior? What kind of mis-use can be expected?
  • What are the infrastructural concerns? Are all revisions saved? How much additional web server and database load is this?
  • Do you throttle editing like you presumably do for tweet creation?
  • How actually requested is this feature? Is it just a vocal minority?
  • What's in it for Twitter if they go down this path? Happier users? Is that a guarantee?
  • How much time, effort, and money is this going to take? (Design, development, UX, testing, etc) Are they prepared to support this for the life of the product?
  • Is the team into the idea or would it be grueling and not-fun?

We could probably double that list on our own and that's just looking from the outside. Software is tough. Being smart and responsible with the features of that software is even tougher.

Comments

  1. Gautam
    Permalink to comment#

    Wow! That’s a good way of looking at things!

  2. Urhin
    Permalink to comment#

    I wish clients knew/understood that!
    And managers…
    And designers…

  3. Permalink to comment#

    Third bullet from the end.
    If editing tweets was the case for users to be happier (and again, IF that was the case), then the rest of the bullets, including those we would have if we have doubled the list, are challenges for the development team and only.
    From the users perspective, it’s like Twitter moves their problems to me.

    As a developer and as a user too, I like how Twitter works (without letting me edit my tweets).

    But you Chris, myself, and probably the rest of the CSS-Tricks readers, are not the users a product in Twitters’ scale has as it’s target group. Such a colossal product/brand/app, relies on the biggest part of it’s users, and statistically speaking, I guess they are like my mother, or anyone else who just knows how to type “twitter.com” in their browsers.
    All the (however correct for the developers) concerns in your list are not the case for them.

    Keep up the good work Chris! :)

    • will_wallace85
      Permalink to comment#

      You’re 100% correct, and I think Chris would agree with you. The message I got out of this article is that our community needs to take a step back from the “C’mon, that’s super easy” mentality and realize that every decision, no matter how minor, can have huge repercussions on the app as a whole. All good decisions go through a process where those types of questions are asked and answered in the public realm, at a higher level in the company, the team working on the feature and/or the individual designer/developer.

      I guess, in short, the code may be easy, the decision is not.

  4. Some good points raised here, Chris. Especially the point about tweets that have been favourited then edited. I don’t see Twitter adding the feature any time soon, I’m sure they have considered it. They evidently made the decision not to allow tweet edits. At the end of the day, if you make a mistake in a tweet you want to change, you can just delete it and add it again. This would of course void any retweets or favourites the original tweet got.

  5. Edit tweets is really awesome thing, but people Misuse this type options.

  6. Haha, good post. Often it happens to me that I try to make something, then in the middle of the “thinking how it’s made” part I realize how difficult it is.

  7. Norman Bird
    Permalink to comment#

    Nice observation Chris. I have often ran across this as I develop online applications. The MAJOR areas I recognize this is in the development of the Database. Clients says “ok we will need these fields” and I always tell them that the field size, layout and scheme will often change and grow as I start to design the applications, because you never think of everything in the beginning , no matter how hard you try. One little idea, like the many Chris mentions, comes to light and it adds something to the DB, which changes everything. One change can be a total change. I have experienced this on literally every DB application I have ever created.

    The moral is to allocate enough time on developing the DB schema. The backbone.

  8. RioBrewster
    Permalink to comment#

    Thanks for this. I would forward this to our internal clients to show them that:
    “Why can’t you just do X?” is never that simple. But of course then they would say – “What does Twitter have to do with it?”

    Seriously though, once the design/development says “Ok, if it’s that easy you figure out the UI” then the requested features seem to become less critical.

  9. David
    Permalink to comment#

    Amen to this post.

  10. Nice thought experiment. It’s all too easy to forget that it takes an awful lot to make something seem as simple as Twitter.

    Doesn’t it seem strange that interface simplicity has an inverse relationship with code complexity? It’s true, but it doesn’t quite fit in my head.

  11. This is why they don’t let you edit the tweet. If you force the user to delete it and rewrite it, then you have much less legal hassle and fewer headaches because you’re not stuck in meetings trying to make these decisions.

    I think features are benefit to effort/cost ratio dependent- how life changing is it going to be? More importantly (to a company like Twitter), how much money would it potentially make or lose for me? I think the costs far outweighed the benefits for Twitter on this one.

    Plus…if you copy the tweet text before you delete it, you can paste it back in and edit it, which is basically the same thing, perhaps just not as convenient as we’re used to having.

  12. Maybe this explains why YouTube sucks in a lot of ways. Except they actually had a lot of features that were good that have now gone missing.

  13. Permalink to comment#

    I wish my boss understood this. A few months back he had a feature request that necessitated two separate databases to communicate with one another over a shared key. That in itself isn’t terribly hard to achieve… but the inevitable questions to quantify that communication completely derailed the process.

    At what point does the communication occur?
    At what point must it stop?
    What are the parameters for what is sent over?
    Does one DBs content have ‘priority’ over the other? If so when/how/why?

    My boss had not considered any of these – he simply expected me to make it work. Hard to do without understanding the scope of the request.

  14. Permalink to comment#

    Pretty eye-opening. I agree with what people are saying above, try telling my clients this. “Can’t everything be done when I want it and how I want it?” nope!

  15. Permalink to comment#

    And if we were talking about another game? Ethics change, spontaneity disappears. If spontaneity is substituted by the intention.
    A tool is designed to express spontaneity, and suddenly politicians, salespeople, marketers simulate spontaneity. What would they need to edit?
    This is a logical result: reflection instead of spontaneity. No repentance possible.
    To the eyes of all my game is hidden. Perfect tool of disinformation.

  16. Permalink to comment#

    Very good points and a intriguing thought experiment. But ultimately I think these questions should be answered with a roll out to a percentage of the user base and a/b tested + improved upon or ditched.

  17. Nitesh
    Permalink to comment#

    Twitter is modeled after real world. In here, people speak their minds, they may argue their point of view and then may agree they were wrong or prove others wrong. The point here is, a word spoken in public, is spoken in public. dot.

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".