1 Punkte von GN⁺ 2024-07-14 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn man möchte, dass Menschen ein Projekt oder eine Produktfunktion verstehen und weitergeben, braucht es vor wiederholten Erklärungen zuerst eine eigene Webseite
  • ChatGPT Code Interpreter ist trotz seiner starken Funktionalität bei Name und Auffindbarkeit in der offiziellen Dokumentation uneinheitlich, sodass Erklärungen Dritter zum nützlicheren Link werden
  • Die Beispiele von Claude Artifacts sowie GitHub Codespaces und Copilot zeigen, dass sich Funktionen leichter teilen und erklären lassen, wenn sie zu einem verlinkbaren Gegenstand werden
  • Wenn Konzepte wie Dan McKinleys Boring Technology auf einer eigenen Seite zusammengefasst sind, können auch Menschen, die zum ersten Mal davon hören, mit nur einem Link schnell den Kontext erfassen
  • Der Wert einer eigenen Seite beschränkt sich nicht auf Sichtbarkeit in Suchmaschinen, sondern besteht auch darin, in Web-Gesprächen dieselbe Erklärung nicht immer wiederholen zu müssen

Warum verlinkbare Seiten nötig sind

  • Für Dinge, die andere verstehen und über die sie sprechen sollen — etwa Projekte, Ideen oder Produktfunktionen — braucht es eine verlinkbare Seite
  • Hyperlinks sind das grundlegende Mittel, um Gespräche im Web zu erweitern: Statt Erklärungen jedes Mal neu zu schreiben, kann man auf eine maßgebliche Erklärung verweisen
  • Fehlt eine eigene Seite, können Aufmerksamkeit und Suchtraffic zu Erklärungen oder Seiten abfließen, die andere erstellt haben oder die bestimmte Suchbegriffe bereits besetzt haben

Das Auffindbarkeitsproblem von ChatGPT Code Interpreter

  • ChatGPT Code Interpreter ist eine Funktion, mit der ChatGPT während der Antworterstellung Python-Code schreiben und ausführen kann
  • Die Funktion selbst ist leistungsfähig, aber wenn man nicht weiß, wie man sie per Prompt aktiviert, ist ihre Existenz schwer zu bemerken
  • Sucht man auf der OpenAI-Website nach Code Interpreter, stößt man auf technische Dokumentation zu einer API-Funktion oder auf einen alten Forum-Thread, was Verwirrung stiftet
  • Wenn diese Funktion vorgestellt wird, ist die Tag-Seite zu code-interpreter ein nützlicherer Link als die offizielle OpenAI-Seite
  • Später wurde zwar die eigentliche Dokumentation gefunden, ihr Titel lautete jedoch Data analysis with ChatGPT, und der Begriff „Code Interpreter“ kommt auf der Seite nicht vor, wodurch sie schwer zu finden war
  • OpenAI hat den Namen dieser Funktion immer wieder geändert: Code Interpreter, Advanced Data Analysis und Data analysis with ChatGPT

Gute Beispiele für Funktionsseiten

  • Für Claudes Funktion Artifacts gibt es zumindest eine leicht auffindbare Hilfeseite
  • Der Ankündigungsbeitrag zu Artifacts wurde allerdings zusammen mit der Vorstellung von Claude 3.5 Sonnet veröffentlicht, sodass Artifacts allein schwer als klarer Link-Zielpunkt erkennbar ist
  • GitHub bietet für einzelne Funktionen separate Landingpages an
  • Wenn eine Funktion eine eigene dedizierte Seite hat, entsteht beim Verlinken und Teilen ein fester Bezugspunkt für die Erklärung

Boring Technology: wenn ein Konzept zu einer Website wird

  • Dan McKinley prägte 2015 im Essay Choose Boring Technology den Begriff Boring Technology
  • Der Kerngedanke ist, dass Entwicklungsteams nur begrenzte Kapazität haben, um neue Probleme zu lösen, und diese Kapazität deshalb für die Teile einsetzen sollten, die ein Produkt einzigartig machen
  • In allen übrigen Bereichen sollte man die langweiligste und bekannteste Technologie wählen, deren Bugs und Grenzen über lange Zeit im Netz verstanden und diskutiert wurden
  • Diese Idee ist auch auf der Website boringtechnology.club zusammengefasst
  • Wenn jemand den Begriff nicht kennt, reicht ein einziger Link, damit die Person innerhalb weniger Minuten den Kontext versteht

Auch persönliche Ideen brauchen teilbare Seiten

  • Ideen wie baked data, git scraping und prompt injection sind ebenfalls auf Seiten zusammengefasst, die sich immer wieder teilen lassen
  • Ohne eigene Domain kann die Botschaft jedoch schwächer ausfallen, dass „dies die zentrale Seite ist, auf die verlinkt werden sollte“
  • Ein klares Link-Ziel erhöht, wie gut sich eine Idee teilen und in Gesprächen verwenden lässt

Ein Wert, der über SEO hinaus vor allem in Gesprächen wirkt

  • Einer der offensichtlichen Zwecke einer eigenen Seite ist SEO
    • Wenn Nutzer nach einer Produktfunktion suchen, sollten sie auf die eigene Website gelangen und nicht auf Seiten, die andere erstellt haben
  • Der größere Wert zeigt sich jedoch in Gesprächen
    • Statt beim Erklären eines Konzepts erneut einen Absatz zu schreiben, kann man einen Link mit der maßgeblichen Erklärung teilen
  • Wenn man möchte, dass Menschen eine Idee, ein Projekt oder eine Funktion verstehen und diskutieren, sollte man eine passende Webseite dafür schaffen

1 Kommentare

 
GN⁺ 2024-07-14
Hacker-News-Kommentare
  • rsync.net ist ein Dienst, der so etwas gut macht. Ich habe zum Beispiel noch nie bei einem anderen Dienst so etwas wie eine CEO-Seite gesehen.
    Ich weiß nicht, wie nützlich das tatsächlich ist, und ich musste dem CEO auch noch nie etwas mitteilen, aber obwohl ich nicht einmal Kunde bin, musste ich beim Lesen dieses Beitrags sofort an diese Seite denken.
    [1]: https://www.rsync.net/products/ceopage.html

    • Manche Konferenzen haben eine Seite wie „Warum Ihr Mitarbeiter an der KimchiBurgerConf teilnehmen sollte“.
      Sie ist so gestaltet, dass man sie direkt an den Vorgesetzten weiterleiten kann, ohne dass der Teilnehmer erst selbst eine halbwegs plausible geschäftliche Begründung formulieren muss.
  • Bei OpenAI sollte man eigentlich meinen, dass sie inzwischen Technical Writer eingestellt hätten, aber laut LinkedIn scheint das nicht der Fall zu sein. Deshalb überrascht mich der schlechte Zustand der Dokumentation auch nicht besonders.
    Ich verstehe nicht, warum sie niemanden für eine dedizierte Dokumentationsrolle einstellen. Entweder halten sie das für unwichtig oder sie priorisieren Wachstum ganz nüchtern über Dokumentation, aber was auch immer der Grund ist, am Ende schaden sie sich damit selbst.

    • Die OpenAI-Dokumentation ist in letzter Zeit etwas besser geworden, liegt derzeit aber Anthropic deutlich hinterher. Der Prompting-Guide von Anthropic ist wirklich das Beste, was ich bisher gesehen habe: https://docs.anthropic.com/en/docs/build-with-claude/prompt-...
    • Wenn man Technical Writer einstellt, wäre das im Bereich technische Dokumentation ein Eingeständnis von menschlicher Überlegenheit. Unabhängig davon, welche Auswirkungen das auf Ingenieure und Nutzer hat, scheint es nach außen besser auszusehen, GPT-generierte Dokumente zu verwenden.
  • Im Beitrag wird auf https://boringtechnology.club/ verwiesen, ein großartiges Slide-Deck darüber, Innovationsanstrengungen nur für wirklich einzigartige Lösungen aufzusparen.
    Alles andere sollte man mit möglichst langweiliger Technologie umsetzen. Ich sehe viel zu oft, dass Entwicklungsteams versuchen, bis in die untersten Schichten alles zu innovieren und dabei den Fokus darauf verlieren, welchen Wert sie eigentlich liefern. Ich würde dieses Slide-Deck am liebsten in mein Weltbild eingravieren.

  • Wieder ein guter Beitrag von Simon. Ich habe dieses Konzept gestern Abend direkt in ein neues Projekt eingebaut. Ich wollte zeigen, dass die Google Gemini App yt-dlp zensiert, die Gemini API aber nicht, und gleichzeitig einen Zuflusskanal für das Projekt sowie die geschäftlichen Gründe schaffen, von denen Simon spricht.
    https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
    Außerdem habe ich localStorage verwendet, damit eine Liste besuchter öffentlicher Chats gespeichert wird. Wenn man zurückkommt, kann man andere Chats sehen, die man gelesen hatte, und sie leichter wiederfinden, als in alten Nachrichten danach zu suchen, wo man den ursprünglichen Link bekommen hat.

    • Zur Info: Den beispielhaften YouTube-Link sollte man lieber nicht öffnen. Gemini hat ein gängiges Troll-Meme hervorgeholt.
  • Tote Links sind mit Abstand das Schlimmste. Könnte nicht jemand eine Browser-Erweiterung bauen, die mit GPT die Website hinter einem toten Link halluziniert?

    • Inzwischen gibt es vielleicht schon mehrere Generationen von Menschen, die nicht wissen, dass Link Rot nicht nur bei „internen“ URLs vorkommt, etwa bei Discord-Bildlinks, sondern bei allen Links.
      Künstler verlinken oft einfach nur auf Social-Media-Seiten, aber Accounts können gesperrt und Benutzernamen geändert werden. Entwickler „verlinken“ auch Abhängigkeiten, ohne zu bedenken, dass Repositories verschwinden können; wenn niemand ein Backup gemacht hat, kann damit auch der Quellcode dieser Version verloren gehen. Paketversionen können aus Registries entfernt werden, und die Online-Dokumentation von Abhängigkeiten kann ebenfalls verschwinden.
      [1]: Einfach Name + Version in eine Manifestdatei eintragen und es dann für immer vergessen. Selbst wenn man noch Caching ergänzt, ist das kein richtiger Mirror und schon gar keine Methode, mit der man im Katastrophenfall Abhängigkeiten selbst bauen könnte.
    • https://websim.ai/
    • Eine Art Kompressionsverfahren wäre auch interessant, das gerade genug Informationen liefert, damit eine festgepinnte LLM-Version eine Seite erzeugen kann, die die Ziele des Autors erfüllt.
      Wenn Leute dann einzeln beschreiben würden, wie die Seite früher aussah, oder das Web nach Hinweisen crawlen würden, wäre das eine ziemlich spannende Idee. Man könnte sogar die „Under Construction“-Banner zurückbringen.
    • Früher nannte man das Vorstellungskraft. Im digitalen Zeitalter scheint sie verloren gegangen zu sein :3
    • Ob als Browser-Erweiterung, weiß ich nicht, aber es gibt die Seite websim AI, die mit einem LLM in Echtzeit gefälschte Seiten erzeugt. Ehrlich gesagt funktioniert das erstaunlich gut.
  • Ich mag den Blog von Simonw. Seit letztem September lese ich seinen Blog mit dem Python-Interpreter. Er sagte, er habe damit angefangen, weil er im Alleingang komplette Anwendungen spontan bauen wollte.
    Allerdings ist mir immer noch nicht klar, wie das genau funktioniert. Ich hatte erwartet, dass es dafür eine einfache Option oder einen Button gibt, habe aber nichts gefunden. Ich hätte mich vielleicht noch mehr bemühen können, es herauszufinden, aber wenn es einen bequemen Link oder ein Tutorial gegeben hätte, hätte ich GPT vermutlich nicht größtenteils ignoriert und weiter benutzt.

  • In diesem Zusammenhang lebt Squares Outage-Response-Meme unter https://outage.party/ weiter.

    • Kann jemand für diejenigen, die damals nicht dabei waren, den Kontext erklären?
  • Ich habe viele Microsoft-Produkte genau aus diesem Grund wirklich gehasst. Besonders schrecklich waren Produkte mit ständig wechselnden Namen wie VSTS/VSO/Dev Ops oder Sharepoint. Ein einzelner Deep Link war 700 Zeichen lang, mit Dutzenden base64-Query-Strings und absurden Pfaden. So nach dem Motto: „Was ist das Problem? Dann nutzt halt einen URL-Shortener. URLs sind eben lang, da kann man nichts machen.“ Das hat mich wahnsinnig gemacht.
    2014 zeigte ein internes Team-Tool den Status von Systemressourcen an, und alle Ressourcen samt Status lagen in einer SQL-Datenbank. Die Web-App war aber ein SPA aus der Zeit vor Routern, aktualisierte die URL nicht und unterstützte keine Deep Links. Wenn man ein bestimmtes Ressourcenproblem per E-Mail oder Messenger weitergeben wollte, musste man erklären: „Geh zu Tool X, such nach Y und klicke Z -> W -> M -> O -> K, dann findest du es dort.“ Es hat mich unglaublich genervt, dass man einen tief verschachtelten Zustand nicht einfach per Link wie https://X.com/Y/Z/W/M/O/K teilen konnte. Auch nach mehrfachem Ansprechen bekam ich nur Antworten wie „Das hat keine Priorität und ist auch kein so großes Problem“.
    Einmal bekam ich die Gelegenheit, zwei Wochen lang an etwas zu arbeiten, das ich verbessern wollte, und beschloss, eine Alternative mit Deep-Link-Unterstützung zu bauen. Außerdem sorgte ich dafür, dass alle Deep Links mit dem Präfix /api/ den Inhalt als JSON zurückgeben. Im Team und im Unternehmen war das ein Riesenerfolg, und obwohl mein Tool deutlich einfacher war und weniger Funktionen hatte, ging die Nutzung von Tool X fast über Nacht zurück. Letztlich wollten die meisten Menschen also eher eine einfache Möglichkeit, Links zu teilen, als ein leistungsfähiges SPA, in dem man tief eintauchen und recherchieren kann.
    Einen Monat später kündigte das Team von Tool X in einer firmenweiten Mail groß an, dass nun auch Deep Links unterstützt würden. Die einfache Funktion, über das Präfix /api/ JSON-Daten zurückzugeben, hielten sie aber nicht für wichtig. Fünf Jahre später war die UI meines Tools zwar veraltet, aber der eigentliche Service wurde zum zentralen internen Service hochgestuft, weil viele Teams ihre Automatisierung rund um die URLs mit /api/-Präfix aufgebaut hatten, und am Ende musste genau dieses Team den Code übernehmen und warten.

    • In Büroumgebungen sehe ich oft, dass Menschen zufrieden damit sind, einfach die vorhandenen Tools und festgelegten Abläufe zu benutzen, und gar nicht auf die Idee kommen, dass es besser gehen könnte. Wenn man sie fragt, sagen sie das auch nicht — bis man ihnen etwas Besseres zeigt.
    • Einer der Gründe, warum sich React Server Components unangenehm anfühlen, ist, dass sie dazu verleiten, API- und Darstellungsschicht zu vermischen. Es gibt Vorteile, aber wir wissen alle, dass die Darstellungsschicht immer daran scheitert, für Nutzer oder Anwendungsfälle entworfen zu sein, die man noch nicht vorausgesehen hat.
    • Was ist ein SPA?
  • Als Simonw-Fan möchte ich noch einen Punkt ansprechen, den offenbar noch niemand erwähnt hat: Simons andere Beispiele dafür, Menschen etwas zum Verlinken zu geben, funktionieren auch auf HN sehr gut: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    Leute, die Simon in der AI-Szene nahestehen, wissen das bereits, aber er fasst sehr oft laufende Entwicklungen, die einem breiteren Publikum noch nicht bekannt sind, extrem schnell zusammen. Er macht relevante Fakten früh verlinkbar und zugänglich, sodass auch Menschen, die weiter von dem Thema entfernt sind, darüber diskutieren können.

  • Ich stimme der Aussage zu, dass „Hyperlinks das Beste am Web sind“. Genauer gesagt sind es Hyperlinks und URLs.
    URLs sind der Grundpfeiler des Webs. Sie ermöglichen es, auf Texte und andere Ressourcen auf eine Weise zu verweisen, die präzise, universell und langlebig sein soll. Es frustriert mich immer wieder, dass die Leute nicht erkennen, wie großartig das ist. Zum Beispiel wenn jemand statt einen Link in eine Nachricht einzufügen sagt: „Such auf YouTube danach.“ Wenn man einem Text ein dauerhaftes Zuhause im Web gibt, erhöht das auch die Sichtbarkeit und verringert die Notwendigkeit, dass der Autor denselben Gedanken noch einmal schreiben muss.
    Verwandter klassischer Essay: Cool URIs don't change. [0][1]
    [0] https://www.w3.org/Provider/Style/URI
    [1] https://news.ycombinator.com/item?id=23865484

    • Zwei zu wenig genutzte Eigenschaften von URLs sind, dass man fast unendlich viele erzeugen kann und dass man Benennungen im Voraus festlegen kann.
      Der praktische Effekt ist folgender: Wenn man sich mit jemandem unterhält oder in einer Q&A-Runde nach einem Vortrag sagen möchte: „Ja, daran haben wir auch gedacht, und unter acmeinitiative.example.com/skub finden Sie Informationen dazu“, obwohl man den Beitrag zu /skub noch gar nicht geschrieben hat, kann man /skub in diesem Moment sofort als den vorgesehenen Handle für diesen Beitrag festlegen. Den Beitrag kann man später schreiben; er erscheint dann dort, und interessierte Menschen können ihn jederzeit über diese URL finden. Dasselbe gilt für von anderen geschriebene Texte oder externe Ressourcen: Man kann in seinem eigenen Namespace spontan eine URL anlegen und später, wenn man Zeit hat, auf den ursprünglichen Link weiterleiten.
      Ich habe viel zu oft in Aufnahmen, Podcasts und Ähnlichem mit klugen Technikerinnen und Technikern, die ihre eigene Domain eindeutig besitzen, erlebt, dass sie das nicht tun. Meist nuscheln sie irgendeine Beschreibung, die man vielleicht finden könnte, oder versuchen sich an einen Titel zu erinnern und nennen ihn halb falsch. Dann müssen alle interessierten Zuhörerinnen und Zuhörer jeweils ihre eigene Zeit und Aufmerksamkeit verschwenden, um danach zu suchen, und insgesamt geht eine enorme Menge Energie verloren.
    • Walled Gardens blockieren URLs immer stärker.
      FB blockiert unter dem Vorwand des Teilens urheberrechtlich geschützter Inhalte viele Websites bis hin zu zufälligen Blogs, reddit blockiert alle .ru-Links, mehrere Archivseiten, Telegram-Links usw. Twitter hat einige Blogging-Plattformen blockiert, und auch kleinere Seiten blockieren oft Discord. Die Sperrung von Discord lässt sich vielleicht rechtfertigen, aber ich hoffe, dass dieser Trend für Menschen ein Anlass wird, solche Orte zu verlassen.
    • Ich hasse die Formulierung „Such danach“.
      Erstens löst sie sofort dieses unangenehme AOL-Keyword-Gefühl aus. Zweitens ignoriert sie das Konzept der Filterblase völlig. Selbst wenn du und ich denselben Suchbegriff eingeben, können wir sehr unterschiedliche Ergebnisse bekommen. Drittens gibt es URLs und Hyperlinks bereits, also muss man mir nicht unnötig zusätzliche Arbeit aufbürden. Wenn du direkt verlinkst, kann ich sehen, worauf du dich genau beziehst, statt mich zwischen unzähligen Reaktionsvideos zu verlieren.
    • Zu sagen, man solle auf https://youtu.be/dQw4w9WgXcQ klicken, ist einfach, aber wie übermittelt man diese URL in einem rein sprachbasierten Medium wie einem Telefonat oder Podcast? Ohne sich auf ebenso schwer zu merkende URL-Shortener zu verlassen, ist das nicht einfach.
    • Ich wünschte wirklich, der Teil darüber, dass Autorinnen und Autoren denselben Gedanken nicht noch einmal schreiben müssen, würde tatsächlich so funktionieren.
      Aber viele Websites und Dienste hassen genau das. Sie sehen darin einen Eingriff in ihr Aufmerksamkeitsrevier. Wenn ich als Autor auf eine Idee verlinke, die ich bereits in einem Blogbeitrag oder Buch sorgfältig formuliert habe, wird der Kommentar mit der Begründung „Eigenwerbung“ entfernt oder zensiert. In letzter Zeit kopiere ich auf HN häufiger einfach meinen ursprünglichen Text hinein, statt Links zu geben, mit denen Leser tiefer einsteigen könnten, um Strafen zu vermeiden. Es gibt eindeutig eine Kluft zwischen dem guten „akademischen“ Weg der Informationsverbreitung, den wir propagieren, und der Realität von Systemen, die Ausdruck kontrollieren.