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.
Wow! That’s a good way of looking at things!
I wish clients knew/understood that!
And managers…
And designers…
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! :)
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.
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.
Edit tweets is really awesome thing, but people Misuse this type options.
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.
You missed one key question: “Is the aim already achievable via other features?”
In Twitter’s case, yes it is – you can delete a tweet and repost it. Or just post a correction. Perhaps an additional question would be “Does editing tweets add more usability vs the alternate methods?”
Thinking about it this way doesn’t take into account malicious behavior. This is a silly example, but you could tweet something like, ‘I love the new CSS-Tricks website!’ Your co-worker gets on there and tweets back, ‘Your totally right!’ Then you edit the tweet to something like, ‘@yourcoworker hates cute babies!’ You can easily see how this could get out of hand and ruin someone’s reputation if used the wrong way.
While your question is valid, I might add that do those alternatives accomplish the goal in a user friendly matter. Your proposed alternatives, while somewhat valid, are not the same as editing a post per say.
Deleting and adding a new one will remove it in historical context and possibly shift entire story lines. It also could raise issues on syndication out to other services. In my opinion, not a very good solution.
Posting a correction, while it keeps many of the deleting timeline issues accurate, it also is not ideal. Does posting a correction maintain a link to the original? If someone uses the original, especially syndicated, what is the possibility that the correction will never be seen?
Personally, I would vote on editing with a button to view the original and the original transported with the edit in API calls. But, as Chris’s list points out, it would be a daunting task.
While your question is valid, I might add that do those alternatives accomplish the goal in a user friendly matter. Your proposed alternatives, while somewhat valid, are not the same as editing a post per say.
Deleting and adding a new one will remove it in historical context and possibly shift entire story lines. It also could raise issues on syndication out to other services. In my opinion, not a very good solution.
Posting a correction, while it keeps many of the deleting timeline issues accurate, it also is not ideal. Does posting a correction maintain a link to the original? If someone uses the original, especially syndicated, what is the possibility that the correction will never be seen?
Personally, I would vote on editing with a button to view the original and the original transported with the edit in API calls. But, as Chris’s list points out, it would be a daunting task.
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.
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.
Amen to this post.
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.
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.
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.
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.
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!
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.
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.
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.