Design den perfekte URL

Denne artikel dukkede først op i Opgave 215 af .net magazine - verdens bedst sælgende magasin til webdesignere og udviklere.

URL-design er for nylig blevet et emne for diskussion igen det sidste år. Det startede med Twitters efterår 2010 redesign, som ser ud til at have valideret, hvad der generelt blev anset for at være en dårlig webdesignteknik for websteder, der vender offentligt: ​​'hash-bang' URL.



Dette er webadresser, der starter direkte efter selve domænet med '#!' Eller '£!' - for eksempel twitter.com/kurafire bliver til twitter.com/#!/kurafire . Den del af URL'en, der entydigt identificerer indholdet på siden, tilføjes derefter i slutningen. Denne teknik er rettet mod at forbedre ydeevnen - den er i det væsentlige rettet mod ikke at genindlæse en hel side, når du kun behøver at genindlæse et lille stykke af den. Men det kommer ikke uden alvorlige ulemper.



Denne vejledning undersøger de finere detaljer ved URL-design og forklarer, hvorfor hash-bangs skal frarådes. Men lad os først se på det grundlæggende.

Hvad er en URL?

Udtrykket URL står for Uniform Resource Locator og specificerer placeringen af ​​en bestemt ressource, såsom en webside. Da en placering er identifikationen af ​​et sted, er enhver URL også en URI eller Uniform Resource Identifier.



En URL specificerer dog ikke kun placeringen af ​​en URI, men også metoden til at få adgang til den - ordningen eller protokollen. Syntaksen for en URL er som følger:

skema: // domæne / sti? forespørgsel_streng # fragment_identifikator

Her vil vi fokusere på webadresser, der bruger HTTP-protokollen, og ignorere ting som MAILTO, FTP eller FILE såvel som porte, indlejrede brugernavne og adgangskoder. En HTTPS-adresse er den samme som enhver almindelig HTTP-URL med det ekstra krav, at den bruger en sikker forbindelse.



Syntaksen for en URL opdelt i dens bestanddele. En URL angiver placeringen af ​​en bestemt ressource, som kan omfatte websider. I denne vejledning vi

Syntaksen for en URL opdelt i dens bestanddele. En URL angiver placeringen af ​​en bestemt ressource, som kan omfatte websider. I denne vejledning koncentrerer vi os om webadresser, der bruger HTTP-protokollen

Domæne

Mens domænedel er indlysende, er det værd at nævne, at www. er ikke en del af et domæne. Det er kun et underdomæne, der ofte bruges af websteder, men som teknisk set er unødvendigt. Mange ikke-tekniske mennesker mener, at det er nødvendigt, så om du skal bruge www.yourdomain.com eller bare yourdomain.com i din marketing eller som den primære webadresse afhænger af dit publikum. Uanset hvad skal begge adresser få besøgende til et og samme websted.

Sti

Stien er en af ​​de vigtigste dele af URL-design og skal oprettes som en mappestruktur ved hjælp af skråstreg fremad, uanset din backend-serveropsætning. Hver unikke side på dit websted eller webapplikation skal have sin egen unikke sti.

Dette skal være så beskrivende og meningsfuldt som muligt og være læsbart for mennesker. Når alt kommer til alt er webadresser beregnet til folk, ikke søgemaskiner - sidstnævnte har ikke problemer med at huske en lang række tilfældige tegn, men brugere deler dine webadresser med andre mennesker.

Hold dine stier så korte som muligt. / om dette firma er unødvendigt langt; / om vil gøre. Læsbare sætninger som dit navn.com/wrote/some-blog-post eller yourname.com/works-for/a-cool-company kan tilføje et godt strejf, men det foretrækkes at bevare kortfattethed.

Forespørgselsstrenge

De fleste hjemmesider giver besøgende mulighed for at søge. Dette er, hvad forespørgselsstrenge er bedst til, såvel som relaterede handlinger såsom filtrering og sortering af indholdet på en side.

Tidligere misbrugte en række serversidesystemer forespørgselsstrengparametre til at betjene forskellige sider på et websted, f.eks. Somesite.com/index.php?p=about. Andre websteder gik et skridt for langt i den rigtige retning og omskrev søgeforespørgselstrenge som en sti til noget, der lignede dette: / q / Min% 20søgning% 20 forespørgsel / sortby / dato / rækkefølge / beskrivelse /.

Begge disse tilgange er dårlige fremgangsmåder, som jeg anbefaler, at du undgår. Vigtigst er det, at en forespørgselsstreng skal behandles som en valgfri tilføjelse til siden; URL'en skal arbejde for at producere en gyldig og nyttig side, selv når den er fjernet. Pagination er en gyldig forespørgselsstreng til sider med en skiftende indholdsstrøm.

Fragmentidentifikatorer

Sjov kendsgerning: fragmentidentifikatoren er den eneste del af en URL, der ikke sendes til serveren, der er vært for siden. I stedet er det meningen at identificere en bestemt placering inde på den resulterende side, såsom et bestemt afsnit i en FAQ eller en fodnote i slutningen af ​​en artikel.

Browsere kan navigere mellem flere fragment-id'er uden at genindlæse siden, og det er denne mekanisme, som folk har valgt at misbruge for at få hele websteder til at fungere uden nogen sideindlæsning mellem at navigere (den nye twitter.com , for eksempel).

Da det er en ønskelig brugeroplevelse, oprettede browserudbydere HTML5 History API, som er en passende (omend helt ny) teknik til at navigere rundt på websteder uden at udløse sideindlæsninger eller misbruge fragmentidentifikatorer.

For detaljerede instruktioner om brug af HTML5 History API anbefaler jeg Manipulering af historie 'Kapitel i Mark Pilgrims online bog Dyk ind i HTML5.

For en klar og kortfattet anatomi af en webadresse der

For en klar og kortfattet anatomi af en webadresse er der en fremragende artikel på Doepud Web Designs websted

At bryde aftalen

Enhver kombination af URL-komponenter repræsenterer en stille aftale: Denne særlige URL returnerer en unik ressource eller et dataobjekt, eventuelt med henvisning til et specifikt underafsnit inden for den ressource.

Da fragment-id'er ikke sendes til serveren, kan man argumentere for, at hash-bang-webadresser ikke er teknisk gyldige.

Citerer Wikipedia-side om webadresser : 'I databehandling er en Uniform Resource Locator (URL) en Uniform Resource Identifier (URI), der specificerer, hvor en identificeret ressource er tilgængelig, og mekanismen til at hente den.' En hash-bang-baseret URL specificerer utilstrækkeligt mekanismen til at hente indholdet, da det kræver en JavaScript-rundtur til serveren, efter at serveren allerede har sendt browseren en HTML-side - en side, der ikke har indholdet tilknyttet anmodet URL (endnu).

Sagt på en anden måde, hash-bangs ændrer mekanismen til at hente en ressource. Det defineres ikke længere simpelt og udelukkende ved en URL-ordning, men ved 'fuldt fungerende JavaScript som bestemt og leveret af serveren og fortolket af en JavaScript-processor i browser-kvalitet'.

Dette kan alle virke pedantisk, men betydningen bliver tydelig, når man overvejer virkeligheden af, hvordan ressourcer tilgås. En browser, der indlæser en URL, er naturligvis den mest almindelige måde for en webside at blive indlæst på, men det er ikke den eneste metode. Ethvert simpelt wget- eller krøllebaseret forsøg på at hente indhold fra internettet fungerer ikke længere, og ethvert stykke software, der indlæser webindhold, skal nu omfatte en fuld JavaScript-parser for at understøtte sådanne webadresser. Og alt dette forudsætter, at JavaScript ikke bliver filtreret ud af en proxyserver eller firewall og ikke indeholder nogen fejl overalt på siden. Når brugere slukker for JavaScript i deres browser, holder disse websteder op med at fungere.

Hvis det ikke er dårligt at bryde den stille aftale og have hele stedet afhængig af skrøbelige teknikker, er hash-bangs også en envejsgade til permanent vedligeholdelse og support. Du kan ikke bruge omskrivning på serversiden til dine webadresser, selv når du redesigner igen. Så medmindre du vil bryde dine indgående links og folks bogmærker, skal du altid foretage noget behandling på dit domænes primære destinationsside for at understøtte disse webadresser, når du har lagt dem derude.

Der

Der er et glimrende resumé af hash-bang-problemet på AppStorm

Dårlig praksis

Der er mange forskellige måder at designe dine webadresser på. Grundlæggende ovenfor er alle gode teknikker, men vi skal vide, hvad der skaber dårlig URL-design for fuldt ud at forstå og værdsætte, hvad der gør godt URL-design godt. Her er nogle fremgangsmåder, der skal undgås, startende med de værste lovovertrædere og fortsætter til metoder, der kun er dårlige råd:

Sideidentifikation hashes

Nogle (for det meste gamle) indholdsstyringssystemer eller blogmotorer identificerer hver unikke side med en lang række tilfældige tegn; noget som dette: 5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html. Hvis dit indholdsstyringssystem eller webstedsmotor genererer sådanne URL'er, skal du finde ud af, hvordan du overskriver eller deaktiverer denne adfærd med det samme; hvis det ikke er muligt, er det virkelig bedre for dig at få et mere moderne CMS. Der er kun ulemper ved disse webadresser - for dine brugere og dig selv - og utallige gode, moderne systemer til rådighed til at drive dit websted, der undgår denne forfærdelige teknik.

Session hashes

Selvom det ikke er så slemt som når det bruges til sider, er hashes, der bruges til sessioner på dit websted, stadig dårlige.

Til at begynde med kan de påvirke SEO negativt. Men den større bekymring er, at de fleste systemer, der anvender dem, bruger SHA-1, hvilket er relativt usikkert - bestemt til brugersessioner eller logins, der indeholder følsomme data.

Filudvidelser

Dine webadresser skal være fri for .php, .aspx og så videre. Filudvidelser er ikke forward-kompatible, så hvis du skifter backend-systemer og alle dine URL'er indeholder .aspx, er du tvunget til at omskrive på serversiden for hver enkelt side på dit websted. Dyrt, ineffektivt og helt unødvendigt. Html-udvidelsen anbefales heller ikke rigtig, men hvis du er sikker på, at du kun nogensinde vil betjene de sider, du bygger som statiske filer, er det en acceptabel teknik.

Ikke-ASCII-tegn

Websteder med et tegnsprog som det primære indholdssprog er noget undskyldt, men latinsk og ikke-grundlæggende tegnsætning kan accentueres bedst.

bærbar stativ til 17 tommer bærbar computer

Understreger

Disse har dårligere brugervenlighed og SEO-værdi og ingen konkrete fordele for over bindestreger.

Nøgleordstopning

Tilføjelse af flere søgeord til webadresser kan hjælpe med SEO, men det vil forvirre dine brugere. Du risikerer også hurtigt at blive markeret som en nøgleordsspammer.

I

I 'Old Twitter' er hele denne single-tweet til stede to gange: en gang i indholdet som beskrivelse og en gang på siden. Imidlertid...

... den nye Twitter overhovedet ikke indeholder tweeten og er 44 kilobyte i størrelse. Denne side skal udføres i et JS-parsing-miljø for at indlæse tweetet eller det

... den nye Twitter overhovedet ikke indeholder tweeten og er 44 kilobyte i størrelse. Denne side skal udføres i et JS-parsing-miljø for at indlæse tweetet, ellers kan det ikke hentes

God praksis

Selvom det er vigtigt at vide, hvilke teknikker du skal undgå, er det naturligvis mere værd at vide, hvilken du skal bruge. Vi har nu alt det grundlæggende dækket, så lad os se på nogle avancerede taktikker, der giver gode webadresser.

'Seje URI'er ændrer sig ikke', som Tim Berners-Lee sagde tilbage i 1998, men bortset fra at holde dem permanente på tværs af redesign, hvad giver det mere gode adresser? Nogle vigtige overvejelser er robusthed, hackbarhed og navneinddeling.

Robust URL-kortlægning

Folk deler dine webadresser, og nogle gange gør de det på et medium, hvor modtagerens miljø muligvis ombryder webadressen på tværs af linjer. Dette er mest almindeligt med blogindlæg, der inkluderer en fuld dato og en lang titel i URL'en.

En løsning er at holde alle dine webadresser kortere end 70 tegn, men det er ikke altid ideelt. Desuden er relationelle databasesystemers art sådan, at ID-værdier er hurtige at slå op, men strenge ikke er det.

Med store mængder trafik kan dette være en seriøs nok flaskehals til at tage en server ned. Tilføjelse af mere hardware kan være en dyr løsning.

Robust URL-kortlægning kan løse begge disse problemer for dig. Ved at indlejre et unikt ID tidligt på din sti kan du have lange, fuldt beskrivende URL'er, når det er nødvendigt, men stadig nyde pålideligheden af ​​kortere URL'er og hastigheden på ID-opslag.

Tag denne URL: ditdomæne.dk/nyheder/1982-dette-er-a-længere-nyheder-post-titel- som-næsten-helt sikkert-bliver brudt-på-en-ny-linje-i-nogle- kunder. I dette eksempel er '1982' ID-værdien af ​​databaseposten for dette bestemte indlæg. Dit CMS kunne derefter kun bruge denne del af URL'en til at foretage en vellykket opslag: ditdomæne.dk/nyheder/1982.

Alt efter det er valgfrit og dejligt for mennesker og SEO, men det betyder ikke noget, om det bliver pakket ind på to linjer.

Den eneste ulempe ved denne teknik er, at ID'er i sig selv ikke er så menneskelige, så det er en kompromis at overveje.

Hackbare URL'er

I en god, hackbar URL kan et menneske justere eller fjerne dele af stien og få forventede resultater fra dit websted. De giver dine besøgende bedre orientering omkring dine sider og giver dem mulighed for nemt at flytte op niveauer. Et eksempel er: ditdomæne.com/blog/2011/05/20/some-article. At reducere dette til hvert skråstreg skal give forventede resultater. For eksempel skal dit domæne.com/blog/2011/05/20/ returnere alle indlæg offentliggjort 20. maj 2011. ditdomæne.com/blog/2011/05/ giver et overblik over maj 2011's indlæg, mens dit domæne.com/blog / 2011 / kunne bruges til at få et overblik over 2011's indlæg, eller, hvis det er for detaljeret, bare sende totaler for hver måned. yourdomain.com/blog/ skal returnere de seneste opdateringer, uanset deres faktiske offentliggørelsesdato.

Hvor detaljeret du skal være om design af sådanne webadresser afhænger virkelig af websteds indhold og målgruppe. Jo mere aktuelt indhold er, jo mere drager det fordel af offentliggørelsesdatoer i URL; jo oftere, nyt indhold bliver offentliggjort, jo mere drager det fordel af finere granularitet.

Andre områder - såsom kategorier, produkter og tjenester - har ikke brug for datakomponenter, men uanset hvor detaljerede (eller ej) dine webadresser ender med at være, skal de i sidste ende være fuldstændig hackbare.

Det er en fejl at sige, at hackbare webadresser kun bruges af teknisk kyndige besøgende og afvise dem, hvis dit publikum ikke er i den niche. For det første bliver brugerne kun mere teknologisk kyndige over tid, ikke mindre. Men vigtigere er, at du ikke kender alle dine besøgende, nuværende og fremtidige.

Navneområder

Det øverste niveau på stien er den mest værdifulde ejendom i en URL. Hvis dit websted gør det muligt for brugere at tilmelde sig og have deres egen profil på dette niveau, skal du oprette en sortliste med brugernavne, der indeholder alle aktuelle og mulige fremtidige funktioner, du måtte ønske at have. Du kan finde nogle gode eksempler på lister på Quora for det.

Navnespacefunktioner bag brugernavnet: lister eller / tilhængere er gode løsninger til offentlige funktioner, der tilhører hver bruger individuelt.

Private ting, som f.eks. Kontoindstillinger, skal aldrig navngives bag brugernavnet og skal bare vises efter / konto eller / indstillinger. Du må heller ikke blande og matche teknikker her. Hvis du begynder at lægge nogle funktioner under / funktion / og andre under / funktion, vil du kun forvirre dine brugere.

Hvis du starter et websted som en blog, men forventer at opbygge det mere i fremtiden, kan du overveje at tilføje alle indlæg under / blog / som et navneområde på øverste niveau for at undgå potentielle konflikter senere.

Quora har nogle gode råd til at forhindre dine brugernavnstilmeldinger i

Quora har nogle gode råd til at forhindre, at dine brugernavnstilmeldinger 'stjæler' værdifulde URL-nøgleord

Forretningssagen

Da webadresser er en så vigtig del af dit websted eller din applikation, bør de være blandt de første ting, du planlægger og træner med dit team. Ikke kun fordi du ikke vil være nødt til at ændre dem over tid, men fordi det at skabe en fantastisk struktur foran hjælper dig betydeligt med at forstå og krystallisere din brugers behov og krav samt dine egne forretningskrav.

At designe gode webadresser bør være en samarbejdsindsats; hvis du har dedikerede informationsarkitekter på dit team, skal de være involveret. Det samme gælder databasearkitekter, front-end-ledere og ledende designere. At komme med en fantastisk URL er ikke kun et job for dine marketing- eller brugeroplevelsesfolk. det er relevant og vigtigt for alle, der er involveret i fremstillingen af ​​produktet.

Når du har din URL-struktur, kan du hurtigt og nemt plotte et komplet sitekort. Dette hjælper informationsarkitekter med at designe et godt hierarki og navigation, back-end ingeniører arbejder effektivt, og front-end-udviklere forvandler rækkevidden af ​​sektioner og sider til ren markering og kode. Fra den konceptuelle designfase og fremefter hjælper en fantastisk URL-struktur, der er designet foran og i fællesskab, med at gøre dit webprodukt bedre på alle måder.