Auto-prefix URL — en lille detalje, der sparer minutter

Du indtaster i formularen allegro.pl. Du klikker. Og hvad så?

I de fleste URL-forkortere får du på dette tidspunkt en fejlmeddelelse. Noget i stil med "dette er ikke en gyldig URL". Fordi der mangler https:// foran. Så du går tilbage, tilføjer protokollen, klikker igen, og først nu har du dit korte link.

cutty.dev gør ikke dette. Den tilføjer bare selv https:// og fortsætter bare, som om intet var hændt.

Jeg ved, hvordan det lyder. Som en feature, der knap nok fortjener et afsnit, for ikke at tale om hele indlægget. Og dog sidder jeg og skriver om det, fordi netop denne lille detalje er for mig et lille manifest for, hvordan jeg overhovedet tænker omkring opbygningen af auto-prefix URL-værktøjet og resten af disse usynlige bekvemmeligheder.

To sekunder mod tyve

Lad os regne. Virkelig, med tal, for ellers er det bare snak.

Den første vej: du indsætter, får et link, lukker vinduet. To sekunder. Måske tre.

Anden vej: du sætter ind, fejl, læser beskeden (et sekund eller to for at forstå, hvad det drejer sig om), tilføjer protokollen, klikker igen, først nu linket. Femten, tyve sekunder. Plus det lille øjebliks irritation, det stille "nå ja, protokollen", som ikke koster noget enkeltvis, men som akkumuleres.

Og multiplicér nu dette med, hvor mange gange om måneden du indsætter en adresse. For mig er det dusinvis. For en person, der administrerer links professionelt — hundreder. Pludselig akkumuleres denne "knap værd at nævne" detalje til minutter om måneden. Per person.

Det er netop denne aritmetik, som de fleste mennesker overser, fordi hvert enkelt tilfælde ser for lille ud til at bekymre sig om.

Hvad ligger egentlig nedenunder

Mekanismen er banal, og jeg skjuler ikke det. Du indsætter teksten i feltet. Før noget sendes til serveren, tjekker en bid JavaScript, om det, du har skrevet, starter med en protokol — http://, https://, ftp://, mailto:, hvad som helst. Hvis det ikke gør, antager systemet, at du mener et almindeligt domæne, og tilføjer https:// foran.

I praksis:

• allegro.pl ændres til https://allegro.pl
• github.com/twoj-profil/projekt til https://github.com/twoj-profil/projekt
• www.gazeta.pl til https://www.gazeta.pl

Og hvis protokollen allerede er der, selvom den er mærkelig, overskriver systemet den ikke. Den efterlader den og undersøger derefter, hvad man skal gøre med det. http://example.com går igennem (tilladt). ftp://example.com ryger i skraldespanden, da vi kun accepterer http og https. Og javascript:alert(1) ryger ud med det samme, fordi det ikke er en adresse, men et forsøg på at injicere noget grimt (klassisk XSS, tak, nej).

Hvorfor har jeg det, når halvdelen af markedet ikke har det

Her bliver det interessant, for svaret er lidt sjovt.

Standardmåden at validere en adresse i browseren på er konstruktøren new URL(string). Og denne konstruktør er hård. Kompromisløs. Der er ingen protokol — den kaster en fejl. new URL("allegro.pl") returnerer dig blot en TypeError, og det er det.

Og ved du hvad? Det er korrekt adfærd. For langt de fleste applikationer er det præcis det, du ønsker. Men i en formular til forkortelse af links, hvor man kopierer adressen fra browserens adresselinje eller fra en besked, forvandles denne råhed fra en fordel til en hindring. Pludselig tvinger et værktøj, der skal spare dig tid, dig til at rette noget, som det jo ellers forstår perfekt.

En omvej til dette er bogstaveligt talt et par linjer:

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)
}

Fem linjer. Et dusin sekunder mindre friktion, hver dag, for alle der indsætter adresser. Jeg ved ærligt talt ikke, hvorfor det ikke er standard overalt. Jeg mistænker, at det handler om, at "URL-konstruktoren virker bare sådan", og at ingen havde lyst til at røre ved det. Inertia, ikke ond vilje.

En lille digression om, hvad det betyder at være "standard"

For denne historie med new URL() er et fantastisk eksempel på noget større. Mange ting i software, der anses for at være "sådan gør man", er i virkeligheden blot "sådan endte det med standardindstillingerne i et eller andet bibliotek, som ingen stillede spørgsmålstegn ved". Konstruktørens strict mode er ikke en beslutning truffet af cutty-designere eller konkurrenter — det er en beslutning truffet af forfatterne til URL-specifikationen, foretaget i en helt anden kontekst og til helt andre formål.

Og derefter arver hele markedet dette standardvalg og kalder det en "standard". Jeg har en følelse af, at de bedste produkter fødes præcis de steder, hvor nogen stoppede op og spurgte: vent lige lidt, tjener denne adfærd egentlig min bruger, eller kun mit bibliotek? Oftest lyder svaret: biblioteket. Og så er det værd at bruge fem linjer på at skifte side til mennesket.

Der er flere af disse småting, end man ser

Auto-prefix er kun ét af mange sådante elementer, som du ikke finder på nogen liste over funktioner. For hvis man skrev dem der, ville hver især se latterligt lille ud:

• trimning af mellemrum før validering, så et tilfældigt mellemrum i slutningen af den indsatte adresse ikke ødelægger det hele
• bevarelse af anker, hvilket betyder at #section i https://example.com/page#section ikke forsvinder efter forkortelse
• forespørgselsparametre (?utm_source=test) overføres i deres helhed, intet bliver beskåret undervejs
• domæner med polske tegn, źdźbło.pl, konverteres automatisk til punycode
• polske bogstaver i den personlige slutning erstattes med ASCII (różowy-link bliver til rozowy-link)
• farlige protokoller — javascript:, data:, file: — afvises med en specifik, forståelig meddelelse

(Der er stadig planlagt en automatisk opgradering af http:// til https://, når målserveren understøtter kryptering. Dette fungerer endnu ikke live, så jeg vil ikke lade som om.)

Hver af disse detaljer sparer nogen fem, ti, tredive sekunder og et suk. Alene er de intet. Sammen er de forskellen mellem "det virker OK" og "jeg kan lide at bruge det".

Hvad jeg gerne ville tilføje mere

Ønskeliste til fremtiden, fordi det simpelthen giver mig glæde at tænke på det:

• intelligent indsættelse — detekter en adresse skjult i en sætning og udtræk kun selve URL'en fra ordene
• bulk-indsættelse — en liste med adresser, én per linje, og lav straks et separat kort link fra hver af dem
• foreslåede endelser — foreslå tre brandede slugs til valg baseret på destinationssidens titel
• Open Graph-forhåndsvisning med det samme efter indsættelse, før du overhovedet klikker på "forkort"

Hver især er igen en "fem-linjers funktion, der ikke ligner noget". Og alle sammen? Det er netop grænsen mellem et værktøj, der er okay, og et, som man rækker ud efter hver dag uden at tænke over det. Hvis du vil se, hvordan det fungerer nu, så indsæt hvad som helst uden protokol i cutty.dev — allegro.pl, github.com, news.ycombinator.com — og se, at intet står i vejen for dig.

Til slut, lidt personligt

Længe troede jeg, at produkter vandt med store funktioner. Med den der ene imponerende ting, som kan vises på et slide, og som folk vil skrive om. Og ja, nogle gange er det sådan.

Men jo længere jeg bygger cutty, desto stærkere føler jeg, at brugerloyalitet opstår et andet sted — i de hundredevis af mikrosekunder, som ingen bevidst lægger mærke til. Du kan ikke huske, at værktøjet selv tilføjede https://. Du husker kun det generelle indtryk af, at "det er på en måde godt at bruge", "det er ikke irriterende". Dette indtryk kommer ikke fra ingenting. Det består af dusinvis af femlinjede beslutninger, som ingen enkeltvis ville forsvare over for sig selv som værende "værd at bruge tid på".

Måske er det netop det, der er håndværket. Ikke i den ene store bevægelse, men i vedholdenheden til gang på menneskets side ved formularen — selv hvis det kun drejer sig om to ynkelige sekunder. Og du? Hvad har irriteret dig for nylig i et værktøj, så småt at det næsten er pinligt at indrømme? For normalt er det netop dér, det bedste arbejde venter på at blive gjort.