Zum Inhalt wechseln
cutty.dev
All posts

Auto-Prefix URL — eine Kleinigkeit, die Minuten spart

cutty.dev erkennt, wenn du eine Adresse ohne https:// einfügst, und fügt sie selbst hinzu. Das klingt banal. In der Praxis ist es der Unterschied zwischen zwei Sekunden und einem Klick auf „Noch einmal versuchen“.

Du gibst allegro.pl in das Formular ein. Du klickst. Und was?

Bei den meisten URL-Shortener erhältst du in diesem Moment eine Fehlermeldung. Etwas im Stil von „Dies ist keine gültige URL“. Weil das https:// am Anfang fehlt. Also gehst du zurück, fügst das Protokoll hinzu, klickst noch einmal, und erst jetzt hast du deinen Kurzlink.

cutty.dev macht das nicht. Er fügt einfach selbst https:// hinzu und macht einfach weiter, als wäre nichts gewesen.

Ich weiß, wie das klingt. Wie ein Feature, das kaum einen Absatz verdient, geschweige denn einen ganzen Beitrag. Und doch sitze ich hier und schreibe darüber, weil genau dieses Detail für mich ein kleines Manifest dessen ist, wie ich generell über den Bau des auto-prefix URL Tools und all der anderen unsichtbaren Erleichterungen denke.

Zwei Sekunden gegen zwanzig

Rechnen wir nach. Wirklich, mit Zahlen, denn sonst ist es nur Gerede.

Erster Weg: du fügst ein, hast den Link, schließt das Fenster. Zwei Sekunden. Vielleicht drei.

Zweiter Weg: du fügst ein, Fehler, liest die Meldung (eine oder zwei Sekunden, um zu verstehen, worum es geht), ergänzt das Protokoll, klickst noch einmal, erst jetzt der Link. Fünfzehn, zwanzig Sekunden. Plus dieser winzige Moment der Irritation, dieses leise „ach ja, Protokoll“, das einzeln nichts kostet, aber sich aufstaut.

Und nun multiplizieren Sie das mit der Anzahl der Male, in denen Sie pro Monat eine Adresse einfügen. Bei mir sind es Dutzende. Bei jemandem, der professionell mit Links arbeitet — Hunderte. Plötzlich summiert sich dieses „kaum erwähnenswerte“ Detail auf Minuten pro Monat. Pro Person.

Das ist genau die Arithmetik, die die meisten Menschen übersehen, weil jeder einzelne Fall zu klein erscheint, um ihn zu beachten.

Was steckt eigentlich darunter

Der Mechanismus ist banal, und ich verberge das auch nicht. Du fügst den Text in das Feld ein. Bevor irgendetwas an den Server gesendet wird, prüft ein Stück JavaScript, ob das, was du eingegeben hast, mit einem bestimmten Protokoll beginnt — http://, https://, ftp://, mailto:, was auch immer. Wenn es nicht damit beginnt, geht das System davon aus, dass du eine gewöhnliche Domain meinst, und fügt vorne https:// hinzu.

In der Praxis:

  • allegro.pl wird zu https://allegro.pl
  • github.com/twoj-profil/projekt zu https://github.com/twoj-profil/projekt
  • www.gazeta.pl zu https://www.gazeta.pl

Und wenn das Protokoll bereits vorhanden ist, auch wenn es seltsam ist, überschreibt das System es nicht. Es lässt es stehen und prüft weiter, was damit zu tun ist. http://example.com geht durch (erlaubt). ftp://example.com landet im Papierkorb, da wir nur http und https akzeptieren. Und javascript:alert(1) fliegt sofort raus, denn das ist keine Adresse, sondern ein Versuch, etwas Schädliches einzuschleusen (klassisches XSS, danke, nein).

Warum ich das habe und die Hälfte des Marktes nicht

Hier wird es interessant, denn die Antwort ist ein wenig lustig.

Der Standardweg zur Validierung einer Adresse im Browser ist der Konstruktor new URL(string). Und dieser Konstruktor ist hart. Kompromisslos. Ohne Protokoll — wirft er einen Fehler. new URL("allegro.pl") gibt dir einfach einen TypeError zurück und das war's.

Und weißt du was? Das ist korrektes Verhalten. Für die überwältigende Mehrheit der Anwendungen ist genau das das, was man will. Aber in einem Formular zum Kürzen von Links, wo man die Adresse aus der Adressleiste des Browsers oder aus einer Nachricht kopiert, verwandelt sich diese Unbeholfenheit von einem Vorteil in ein Hindernis. Plötzlich zwingt dich ein Werkzeug, das dir Zeit sparen soll, dazu, etwas zu korrigieren, das es eigentlich perfekt versteht.

Um dies zu umgehen, sind es buchstäblich nur ein paar Zeilen:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalej leci normalna walidacja przez new URL(normalized)
}

Fünf Zeilen. Ein paar Sekunden weniger Reibung pro Tag für jeden, der Adressen einfügt. Ehrlich gesagt weiß ich nicht, warum das nicht überall Standard ist. Ich vermute, es liegt daran, dass der "URL-Constructor einfach so funktioniert" und niemand Lust hatte, ihn anzufassen. Trägheit, keine böse Absicht.

Eine kleine Digression darüber, was „standardmäßig“ bedeutet

Denn diese Geschichte mit new URL() ist ein großartiges Beispiel für etwas Größeres. Viele Dinge in der Softwareentwicklung, die als „so macht man das“ gelten, sind in Wirklichkeit „so ergab es sich aus den Standardeinstellungen einer Bibliothek, die niemand hinterfragt hat“. Der Strict Mode des Konstruktors ist keine Entscheidung der Designer von cutty oder der Konkurrenz — es ist eine Entscheidung der Autoren der URL-Spezifikation, getroffen in einem völlig anderen Kontext und für völlig andere Anwendungen.

Und dann erbt der gesamte Markt diese Standardauswahl und nennt sie „Standard“. Ich habe das Gefühl, dass die besten Produkte genau an den Stellen entstehen, an denen jemand innegehalten und gefragt hat: Moment mal, dient dieses Verhalten eigentlich meinem Nutzer oder nur meiner Bibliothek? Meistens lautet die Antwort: der Bibliothek. Und dann lohnt es sich, mit fünf Zeilen Code zur Seite des Menschen zu wechseln.

Es gibt mehr von diesen Kleinigkeiten, als man sieht

Auto-prefix ist nur eines von vielen Elementen, die du auf keiner Feature-Liste finden wirst. Denn wenn man sie dort auflisten würde, sähe jedes einzelne lächerlich klein aus:

  • Entfernen von Leerzeichen vor der Validierung, damit ein versehentliches Leerzeichen am Ende der eingefügten Adresse nicht alles zerstört
  • Beibehaltung des Ankers, d. h. #section in https://example.com/page#section verschwindet nach der Kürzung nicht
  • Query-Parameter (?utm_source=test) werden vollständig übertragen, nichts wird unterwegs abgeschnitten
  • Domains mit polnischen Sonderzeichen, źdźbło.pl, werden automatisch in Punycode umgewandelt
  • Polnische Buchstaben im eigenen Suffix werden in ASCII umgewandelt (różowy-link wird zu rozowy-link)
  • Gefährliche Protokolle — javascript:, data:, file: — werden mit einer spezifischen, verständlichen Meldung abgelehnt

(Es ist noch eine automatische Umleitung von http:// zu https:// geplant, wenn der Zielserver Verschlüsselung unterstützt. Das funktioniert aktuell noch nicht live, also werde ich nicht so tun, als ob.)

Jedes dieser Details spart jemandem fünf, zehn, dreißig Sekunden und ein Seufzen. Einzeln nichts. Zusammen ist es der Unterschied zwischen „funktioniert OK“ und „ich nutze es gerne“.

Was ich noch dazuverdienen möchte

Wunschliste für die Zukunft, weil es mir einfach Spaß macht, darüber nachzudenken:

  • intelligentes Einfügen — eine Adresse mitten im Satz erkennen und nur die URL aus den Wörtern extrahieren
  • Masseneinfügen — eine Liste von Adressen, eine pro Zeile, und sofort ein separater Kurzlink für jede
  • vorgeschlagene Endungen — basierend auf dem Titel der Zielseite drei markengerechte Slugs zur Auswahl vorschlagen
  • Open Graph Vorschau direkt nach dem Einfügen, noch bevor Sie auf „kürzen“ klicken

Jedes davon ist wieder eine „Fünfzeiler-Funktion, die nach nichts aussieht“. Und alles zusammen? Das ist genau die Grenze zwischen einem Werkzeug, das in Ordnung ist, und einem, nach dem man jeden Tag ohne Nachzudenken greift. Wenn du sehen willst, wie es jetzt funktioniert, füge bei cutty.dev irgendetwas ohne Protokoll ein — allegro.pl, github.com, news.ycombinator.com — und sieh selbst, dass es dir keine Steine in den Weg legt.

Zum Schluss, ein wenig persönlich

Lange dachte ich, dass Produkte durch große Funktionen gewinnen. Durch dieses eine beeindruckende Etwas, das man auf einer Folie präsentieren kann und über das die Leute schreiben werden. Und ja, manchmal ist es so.

Je länger ich Cuttys baue, desto stärker spüre ich, dass Nutzerloyalität woanders entsteht — in jenen hunderten von Mikrosekunden, die niemand bewusst wahrnimmt. Du erinnerst dich nicht daran, dass das Tool https:// selbst hinzugefügt hat. Du erinnerst dich nur an den allgemeinen Eindruck, dass es „irgendwie gut zu benutzen ist“, „nicht nervt“. Dieser Eindruck kommt nicht von ungefähr. Er setzt sich aus Dutzenden von fünfzeiligen Entscheidungen zusammen, die niemand einzeln vor sich selbst als „zeitwert“ rechtfertigen würde.

Vielleicht besteht genau das das Handwerk aus. Nicht in dieser einen großen Bewegung, sondern in der Beharrlichkeit, immer wieder auf der Seite des Menschen beim Formular zu stehen — selbst wenn es nur um zwei erbärmliche Sekunden geht. Und du? Was hat dich in letzter Zeit an einem Werkzeug so sehr genervt, dass es schon fast peinlich ist, es zuzugeben? Denn meistens liegt genau dort die beste Arbeit, die noch zu erledigen ist.