Warum kann ich meine Tweets nicht bearbeiten?! Twitter sollte das erlauben.
Es ist so einfach, oder? CRUD-Anwendungen (Create, Read, Update und Delete) sind Grundlagen des App-Aufbaus! Welch eine grobe Fahrlässigkeit. Aber Moment. Lassen Sie uns einfach als kleine nerdige Übung darüber nachdenken, was eine Funktion wie diese für das Twitter-Team bedeuten könnte. Ich arbeite dort nicht und habe keine Insider-Kenntnisse, daher ist dies alles hypothetisch, um die App-Entwicklung zu verstehen.
- Sollten Sie in der Lage sein, jeden Tweet, den Sie jemals getwittert haben, jederzeit zu bearbeiten?
- Oder sollten Sie nur wenige Minuten dafür Zeit haben, bis er gesperrt wird?
- Bieten Sie das allen an? Opt-in? Opt-out?
- Sollten Sie in der Lage sein, auch Tweets oder Direktnachrichten zu bearbeiten?
- Wie sieht es aus, einen Tweet zu bearbeiten? Kann es einfach und offensichtlich sein? Benötigt es zusätzliche Benutzeroberflächenelemente? Wie exponieren Sie diese Benutzeroberfläche? Lohnt sich die zusätzliche Benutzeroberfläche?
- Geht der Tweet sofort oder nach der Bearbeitungsfrist an die öffentliche Timeline?
- Was passiert, wenn jemand einen Tweet favorisiert und dieser später bearbeitet wird? Verliert er die Favoriten? Zum Beispiel könnte ein Tweet, der ursprünglich "Ich mag Pfannkuchen!" lautete, später zu "Leute, die das favorisiert haben, mögen Robbenbabys jagen!" (oder viel schlimmer) bearbeitet werden.
- Gleiche Frage, mit Retweets. Und mit Antworten.
- Gibt es soziale oder moralische Auswirkungen davon?
- Wie wirkt sich die Tweet-Bearbeitung auf das allgemeine Gefühl bei der Nutzung von Twitter aus? Würde eine Zeitverzögerung dieses Gefühl beeinflussen? Würden die Leute Tweets anders sehen?
- Macht die Tweet-Bearbeitung kompromittierte Konten zu einer noch gefährlicheren Aussicht?
- Wie gehen Drittanbieter-Clients mit der Tweet-Bearbeitung um? Gibt es eine öffentliche API dafür? Wie komplex ist das?
- Oder bieten Sie die Tweet-Bearbeitung nur über das Web an? Wie kommt diese Entscheidung bei den Entwicklern an?
- Wie stellen Sie sicher, dass die Bearbeitung durch Drittanbieter eine ebenbürtige Benutzererfahrung bietet? Ist das wichtig?
- Wenn Tweets nicht zeitverzögert sind, wie gehen Sie mit bearbeiteten Tweets über die API um? – Wie sagen Sie Drittanbieter-Clients, dass sie einen aktuell angezeigten Tweet aktualisieren sollen, anstatt einen neuen anzuzeigen?
- Wohin gehen bearbeitete Tweets? Zurück an den Anfang der Timeline oder bleiben sie, wo sie sind?
- Sollte visuell angezeigt werden, dass ein Tweet bearbeitet wurde? Wie setzen Sie das in Drittanbieter-Apps durch?
- Gibt es hier rechtliche Implikationen? Was ist, wenn jemand etwas Illegales twittert und es dann in etwas Legales ändert?
- Eröffnet die Tweet-Bearbeitung irgendeine Art von böswilligem Verhalten? Welche Art von Missbrauch ist zu erwarten?
- Was sind die infrastrukturellen Bedenken? Werden alle Revisionen gespeichert? Wie viel zusätzliche Last entsteht für Webserver und Datenbank?
- Drosseln Sie die Bearbeitung, so wie Sie mutmaßlich die Tweet-Erstellung drosseln?
- Wie *tatsächlich* nachgefragt ist diese Funktion? Ist es nur eine lautstarke Minderheit?
- Was hat Twitter davon, wenn sie diesen Weg gehen? Zufriedenere Nutzer? Ist das eine Garantie?
- Wie viel Zeit, Mühe und Geld wird das kosten? (Design, Entwicklung, UX, Tests usw.) Sind sie bereit, dies für die Lebensdauer des Produkts zu unterstützen?
- Ist das Team von der Idee begeistert oder wäre es mühsam und nicht spaßig?
Wir könnten diese Liste wahrscheinlich verdoppeln und das ist nur von außen betrachtet. Software ist schwierig. Klug und verantwortungsbewusst mit den Funktionen dieser Software umzugehen, ist noch schwieriger.
Wow! Das ist eine gute Sichtweise!
Ich wünschte, Kunden wüssten/verstünden das!
Und Manager…
Und Designer…
Dritter Punkt von unten.
Wenn die Bearbeitung von Tweets dazu führen würde, dass die Nutzer zufriedener sind (und wiederum, *wenn* das der Fall wäre), dann wären die restlichen Punkte, einschließlich derer, die wir hätten, wenn wir die Liste verdoppelt hätten, nur Herausforderungen für das Entwicklungsteam.
Aus der Sicht des Nutzers ist es, als würde Twitter seine Probleme auf mich verlagern.
Als Entwickler und auch als Nutzer mag ich, wie Twitter funktioniert (ohne mir die Bearbeitung meiner Tweets zu erlauben).
Aber Sie, Chris, ich selbst und wahrscheinlich auch die übrigen Leser von CSS-Tricks sind nicht die Nutzer, die ein Produkt im Ausmaß von Twitter als Zielgruppe hat. Ein solch kolossales Produkt/Marke/App verlässt sich auf den größten Teil seiner Nutzer, und statistisch gesehen sind diese wahrscheinlich wie meine Mutter oder jeder andere, der einfach nur "twitter.com" in seinen Browser eingibt.
All die (wenn auch für die Entwickler korrekten) Bedenken auf Ihrer Liste sind für sie nicht relevant.
Mach weiter so, Chris! :)
Sie haben zu 100 % Recht, und ich glaube, Chris würde Ihnen zustimmen. Die Botschaft, die ich aus diesem Artikel mitgenommen habe, ist, dass unsere Community einen Schritt von der "Komm schon, das ist super einfach"-Mentalität zurücktreten muss und erkennen muss, dass jede Entscheidung, egal wie klein, riesige Auswirkungen auf die App als Ganzes haben kann. Alle guten Entscheidungen durchlaufen einen Prozess, bei dem solche Fragen gestellt und beantwortet werden, im öffentlichen Bereich, auf höherer Ebene im Unternehmen, im Feature-Team und/oder beim einzelnen Designer/Entwickler.
Ich denke, kurz gesagt: Der Code mag einfach sein, die Entscheidung nicht.
Einige gute Punkte werden hier angesprochen, Chris. Insbesondere der Punkt über Tweets, die favorisiert und dann bearbeitet wurden. Ich glaube nicht, dass Twitter die Funktion bald einführen wird, ich bin sicher, sie haben sie in Erwägung gezogen. Sie haben offensichtlich die Entscheidung getroffen, Tweet-Edits nicht zuzulassen. Am Ende des Tages, wenn Sie einen Fehler in einem Tweet machen, den Sie ändern möchten, können Sie ihn einfach löschen und neu hinzufügen. Dies würde natürlich alle Retweets oder Favoriten des ursprünglichen Tweets ungültig machen.
Das Bearbeiten von Tweets ist eine wirklich großartige Sache, aber die Leute missbrauchen solche Optionen.
Haha, guter Beitrag. Oft passiert es mir, dass ich etwas machen will, und dann mitten im "Nachdenken, wie es gemacht wird"-Teil merke, wie schwierig es ist.
Sie haben eine wichtige Frage vergessen: "Ist das Ziel bereits über andere Funktionen erreichbar?"
Im Fall von Twitter, ja – man kann einen Tweet löschen und ihn neu posten. Oder einfach eine Korrektur posten. Vielleicht wäre eine zusätzliche Frage: "Bietet die Bearbeitung von Tweets mehr Benutzerfreundlichkeit im Vergleich zu den alternativen Methoden?"
Wenn man es so betrachtet, werden böswilliges Verhalten nicht berücksichtigt. Das ist ein albernes Beispiel, aber man könnte etwas twittern wie: "Ich liebe die neue CSS-Tricks-Website!" Dein Kollege kommt vorbei und twittert zurück: "Du hast völlig Recht!" Dann bearbeitest du den Tweet zu etwas wie: "@deinkollege hasst süße Babys!" Man kann leicht erkennen, wie das außer Kontrolle geraten und den Ruf einer Person ruinieren könnte, wenn es falsch eingesetzt wird.
Während Ihre Frage berechtigt ist, möchte ich vielleicht hinzufügen, ob diese Alternativen das Ziel auf benutzerfreundliche Weise erfüllen. Ihre vorgeschlagenen Alternativen sind zwar einigermaßen gültig, aber nicht dasselbe wie die Bearbeitung eines Beitrags per se.
Das Löschen und Hinzufügen eines neuen Beitrags würde ihn aus dem historischen Kontext entfernen und möglicherweise ganze Handlungsstränge verschieben. Es könnte auch Probleme bei der Syndizierung an andere Dienste aufwerfen. Meiner Meinung nach keine sehr gute Lösung.
Das Posten einer Korrektur, obwohl es viele Probleme mit der Löschung der Timeline korrekt hält, ist auch nicht ideal. Behält das Posten einer Korrektur einen Link zum Original? Wenn jemand das Original verwendet, insbesondere syndiziert, wie hoch ist die Wahrscheinlichkeit, dass die Korrektur nie gesehen wird?
Persönlich würde ich für die Bearbeitung mit einer Schaltfläche zum Anzeigen des Originals stimmen, und das Original würde mit der Bearbeitung in API-Aufrufen transportiert. Aber, wie Chris' Liste zeigt, wäre es eine entmutigende Aufgabe.
Während Ihre Frage berechtigt ist, möchte ich vielleicht hinzufügen, ob diese Alternativen das Ziel auf benutzerfreundliche Weise erfüllen. Ihre vorgeschlagenen Alternativen sind zwar einigermaßen gültig, aber nicht dasselbe wie die Bearbeitung eines Beitrags per se.
Das Löschen und Hinzufügen eines neuen Beitrags würde ihn aus dem historischen Kontext entfernen und möglicherweise ganze Handlungsstränge verschieben. Es könnte auch Probleme bei der Syndizierung an andere Dienste aufwerfen. Meiner Meinung nach keine sehr gute Lösung.
Das Posten einer Korrektur, obwohl es viele Probleme mit der Löschung der Timeline korrekt hält, ist auch nicht ideal. Behält das Posten einer Korrektur einen Link zum Original? Wenn jemand das Original verwendet, insbesondere syndiziert, wie hoch ist die Wahrscheinlichkeit, dass die Korrektur nie gesehen wird?
Persönlich würde ich für die Bearbeitung mit einer Schaltfläche zum Anzeigen des Originals stimmen, und das Original würde mit der Bearbeitung in API-Aufrufen transportiert. Aber, wie Chris' Liste zeigt, wäre es eine entmutigende Aufgabe.
Schöne Beobachtung, Chris. Das ist mir schon oft aufgefallen, wenn ich Online-Anwendungen entwickle. Die HAUPTbereiche, in denen ich das erkenne, sind bei der Entwicklung der Datenbank. Kunden sagen: "Okay, wir brauchen diese Felder", und ich sage ihnen immer, dass sich die Feldgröße, das Layout und das Schema ändern und wachsen werden, wenn ich mit dem Entwurf der Anwendungen beginne, weil man am Anfang nie an alles denkt, egal wie sehr man sich anstrengt. Eine kleine Idee, wie die vielen, die Chris erwähnt, kommt ans Licht und fügt der Datenbank etwas hinzu, was alles verändert. Eine Änderung kann eine totale Änderung sein. Das habe ich bei buchstäblich jeder Datenbankanwendung erlebt, die ich je erstellt habe.
Die Moral ist, genug Zeit für die Entwicklung des Datenbankschemas einzuplanen. Das Rückgrat.
Danke dafür. Ich würde das an unsere internen Kunden weiterleiten, um ihnen zu zeigen, dass
"Warum können Sie nicht einfach X tun?" ist nie so einfach. Aber natürlich würden sie dann sagen: "Was hat Twitter damit zu tun?"
Im Ernst, wenn das Design/die Entwicklung sagt: "Okay, wenn es so einfach ist, Sie figure out the UI", dann scheinen die gewünschten Funktionen weniger wichtig zu werden.
Amen zu diesem Beitrag.
Schönes Gedankenexperiment. Es ist allzu leicht zu vergessen, dass es enorm viel braucht, um etwas so einfach erscheinen zu lassen wie Twitter.
Erscheint es nicht seltsam, dass die Einfachheit der Benutzeroberfläche eine inverse Beziehung zur Komplexität des Codes hat? Es stimmt, aber es passt nicht ganz in meinen Kopf.
Deshalb erlauben sie Ihnen nicht, den Tweet zu bearbeiten. Wenn Sie den Benutzer zwingen, ihn zu löschen und neu zu schreiben, haben Sie viel weniger rechtliche Probleme und weniger Kopfzerbrechen, da Sie nicht in Besprechungen stecken bleiben, um diese Entscheidungen zu treffen.
Ich denke, Funktionen hängen vom Verhältnis von Nutzen zu Aufwand/Kosten ab – wie lebensverändernd wird es sein? Wichtiger noch (für ein Unternehmen wie Twitter), wie viel Geld würde es mir potenziell einbringen oder kosten? Ich denke, die Kosten überwogen für Twitter bei diesem Punkt bei weitem den Nutzen.
Außerdem... wenn Sie den Tweet-Text kopieren, bevor Sie ihn löschen, können Sie ihn wieder einfügen und bearbeiten, was im Wesentlichen dasselbe ist, vielleicht nur nicht so bequem, wie wir es gewohnt sind.
Vielleicht erklärt das, warum YouTube in vielerlei Hinsicht schlecht ist. Außer dass sie tatsächlich viele gute Funktionen hatten, die jetzt fehlen.
Ich wünschte, mein Chef würde das verstehen. Vor ein paar Monaten hatte er eine Funktionsanfrage, die zwei separate Datenbanken erforderte, die über einen gemeinsamen Schlüssel miteinander kommunizierten. Das allein ist nicht besonders schwer zu erreichen... aber die unvermeidlichen Fragen zur Quantifizierung dieser Kommunikation brachten den Prozess völlig zum Erliegen.
Zu welchem Zeitpunkt erfolgt die Kommunikation?
Zu welchem Zeitpunkt muss sie aufhören?
Was sind die Parameter für das, was gesendet wird?
Hat der Inhalt einer DB "Priorität" vor dem anderen? Wenn ja, wann/wie/warum?
Mein Chef hatte sich keine dieser Fragen gestellt – er erwartete einfach, dass ich es zum Laufen bringe. Schwer zu tun, ohne den Umfang der Anfrage zu verstehen.
Ziemlich augenöffnend. Ich stimme dem zu, was die Leute oben sagen, versuchen Sie, meinen Kunden das zu sagen. "Kann nicht alles gemacht werden, wann ich es will und wie ich es will?" Nein!
Und wenn wir über ein anderes Spiel sprechen würden? Ethik ändert sich, Spontaneität verschwindet. Wenn Spontaneität durch die Absicht *ersetzt* wird.
Ein Werkzeug wird entwickelt, um Spontaneität auszudrücken, und plötzlich simulieren Politiker, Verkäufer, Vermarkter Spontaneität. Was müssten sie bearbeiten?
Das ist ein logisches Ergebnis: Reflexion statt Spontaneität. Keine *Reue* möglich.
In den Augen aller ist mein Spiel verborgen. Perfektes Werkzeug der Desinformation.
Sehr gute Punkte und ein faszinierendes Gedankenexperiment. Aber letztendlich denke ich, dass diese Fragen mit einer Einführung für einen Prozentsatz der Benutzerbasis beantwortet, A/B-getestet und verbessert oder verworfen werden sollten.
Twitter ist nach dem realen Leben modelliert. Hier sprechen die Leute ihre Meinung, sie können ihren Standpunkt argumentieren und dann zustimmen, dass sie falsch lagen oder andere widerlegen. Der Punkt ist hier, ein gesprochenes Wort in der Öffentlichkeit ist ein gesprochenes Wort in der Öffentlichkeit. Punkt.