Suunnittele täydellinen URL-osoite

Tämä artikkeli ilmestyi ensimmäisen kerran numero 215 of .net magazine - maailman myydyin verkkosivujen suunnittelijoille ja kehittäjille suunnattu lehti.

URL-suunnittelusta on viime aikoina tullut jälleen keskustelunaihe viimeisen vuoden aikana. Se alkoi Twitterin syksyn 2010 uudelleensuunnittelulla, joka näyttää vahvistaneen yleisesti huonoksi verkkosuunnittelutekniikaksi julkisesti suunnattujen verkkosivustojen URL-osoitteen: hash-bang-URL.



Nämä ovat URL-osoitteita, jotka alkavat suoraan verkkotunnuksen jälkeen '#!' Tai '£!' - esimerkiksi twitter.com/kurafire tulee twitter.com/#!/kurafire . Sen jälkeen lisätään URL-osoitteen osa, joka yksilöi sivun sisällön. Tällä tekniikalla pyritään parantamaan suorituskykyä - sen tarkoituksena on lähinnä olla lataamatta koko sivua uudelleen, kun sinun tarvitsee ladata vain pieni osa siitä. Mutta se ei tule ilman vakavia haittoja.



Tässä opetusohjelmassa tarkastellaan URL-suunnittelun yksityiskohtia ja selitetään, miksi hash-bangia ei suositella. Mutta ensin katsotaanpa perusteet.

Mikä on URL?

Termi URL tarkoittaa Uniform Resource Locator ja määrittelee tietyn resurssin, kuten verkkosivun, sijainnin. Koska sijainti on paikan tunniste, mikä tahansa URL-osoite on myös URI tai yhtenäinen resurssitunniste.



URL-osoite ei kuitenkaan määritä vain URI: n sijaintia, vaan myös menetelmän siihen pääsemiseksi - järjestelmän tai protokollan. URL-osoitteen syntaksi on seuraava:

kaavio: // verkkotunnus / polku? kyselyn_merkkijono # fragmentin tunniste

Tässä keskitymme WWW-osoitteisiin, jotka käyttävät HTTP-protokollaa, ja jätämme huomiotta esimerkiksi MAILTO, FTP tai FILE, samoin kuin portit, upotetut käyttäjänimet ja salasanat. HTTPS-osoite on sama kuin mikä tahansa tavallinen HTTP-URL, ja siihen lisätään vaatimus, että se käyttää suojattua yhteyttä.



URL-osoitteen syntaksi jaoteltu sen osiin. URL-osoite määrittää tietyn resurssin sijainnin, joka voi sisältää verkkosivuja. Tässä opetusohjelmassa me

URL-osoitteen syntaksi jaoteltu sen osiin. URL-osoite määrittää tietyn resurssin sijainnin, joka voi sisältää verkkosivuja. Tässä opetusohjelmassa keskitymme HTTP-protokollaa käyttäviin verkko-osoitteisiin

Verkkotunnus

Vaikka verkkotunnuksen osa on ilmeinen, on syytä mainita, että www. ei ole osa verkkotunnusta. Se on vain aliverkkotunnus, jota verkkosivustot käyttävät yleisesti, mutta on teknisesti tarpeetonta. Monet ei-tekniset ihmiset ajattelevat, että sitä tarvitaan, joten onko sinun käytettävä www.omaverkkotunnus.com vai vain verkkotunnus.com markkinoinnissasi vai ensisijaisena verkko-osoitteena, riippuu yleisöstäsi. Molempien osoitteiden pitäisi kuitenkin saada kävijät yhdelle ja samalle verkkosivustolle.

Polku

Polku on yksi URL-suunnittelun tärkeimmistä osista, ja se on luotava kansiorakenteen tavoin eteenpäin viivoja käyttäen, riippumatta taustapalvelimen asetuksista. Jokaisella verkkosivustosi tai verkkosovelluksesi ainutlaatuisella sivulla on oltava oma ainutlaatuinen polku.

Tämän on oltava mahdollisimman kuvaava ja mielekäs, ja sen on oltava luettavissa ihmisille. Loppujen lopuksi URL-osoitteet on tarkoitettu ihmisille, ei hakukoneille - viimeksi mainituilla ei ole vaikeuksia muistaa pitkiä satunnaisia ​​merkkejä, mutta käyttäjät jakavat URL-osoitteesi muiden ihmisten kanssa.

Pidä polkusi mahdollisimman lyhyinä. / tästä yrityksestä on tarpeettoman pitkä; / noin tekee. Luettavissa olevat lauseet, kuten nimesi.com/kirjoitettu/joku-blogiposti tai nimesi.com/työt--/jäähdytysyritys, voivat lisätä mukavan kosketuksen, mutta on suositeltavaa säilyttää lyhyyys.

Kyselyjonot

Suurin osa verkkosivustoista antaa kävijöille mahdollisuuden tehdä hakuja. Tähän kyselymerkkijonot ja siihen liittyvät toiminnot, kuten sivun sisällön suodatus ja lajittelu, sopivat parhaiten.

Aikaisemmin monet palvelinpuolen järjestelmät käyttivät väärin kyselymerkkijonoparametreja palvelemaan sivuston eri sivuja, kuten somesite.com/index.php?p=about. Muut sivustot menivät yhden askeleen liian pitkälle oikeaan suuntaan ja kirjoittivat hakukyselymerkit uudelleen poluksi, mikä muistuttaa tätä: / q / Oma% 20haku% 20 kysely / lajittelu / päivämäärä / järjestys / desc /.

Molemmat näistä lähestymistavoista ovat huonoja käytäntöjä, joita suosittelen välttämään. Mikä tärkeintä, kyselymerkkijonoa tulisi käsitellä valinnaisena sivun lisäyksenä; URL-osoitteen pitäisi toimia kelvollisen ja hyödyllisen sivun tuottamiseksi, vaikka se poistettaisiin. Sivutus on kelvollinen kyselymerkkijono sivuille, joilla on muuttuva sisältövirta.

Katkelmatunnisteet

Hauska tosiasia: fragmenttitunniste on ainoa URL-osoitteen osa, jota ei lähetetä sivua isännöivälle palvelimelle. Sen sijaan sen on tarkoitus tunnistaa tietty paikka tuloksena olevan sivun sisällä, kuten tietty FAQ-osio tai alaviite artikkelin lopussa.

Selaimet voivat liikkua useiden fragmenttitunnisteiden välillä lataamatta sivua uudelleen, ja juuri tämän mekanismin ihmiset ovat valinneet väärin saadakseen kokonaiset sivustot toimimaan ilman sivujen lataamista navigoinnin välillä (uusi twitter.com , esimerkiksi).

Koska tämä on toivottava käyttökokemus, selaimen toimittajat loivat HTML5 History -sovellusliittymän, joka on sopiva (vaikkakin upouusi) tekniikka sivustojen selaamiseen käynnistämättä sivujen lataamista uudelleen tai väärinkäyttäen fragmenttitunnisteita.

Yksityiskohtaisia ​​ohjeita HTML5 History -sovellusliittymän käytöstä suosittelen Manipuloiminen historiaan Mark Pilgrimin online-kirjan Dive Into HTML5 online-kirja.

Selkeä ja tiivis anatomia verkko-osoitteesta, siellä

Doepud Web Design -sivustolta löytyy erinomainen artikkeli, jotta web-osoitteen anatomia olisi selkeä ja tiivis

Sopimuksen rikkominen

Mikä tahansa URL-komponenttien yhdistelmä edustaa hiljaista sopimusta: tämä URL-osoite palauttaa yksilöllisen resurssin tai dataobjektin, viitaten valinnaisesti kyseisen resurssin tiettyyn alaosaan.

Koska fragmenttitunnisteita ei lähetetä palvelimelle, voidaan väittää, että hash-bang-URL-osoitteet eivät ole teknisesti kelvollisia.

Viitaten Wikipedia-sivu URL-osoitteista : 'Laskennassa yhtenäinen resurssihaku (URL) on yhtenäinen resurssitunniste (URI), joka määrittää, missä tunnistettu resurssi on käytettävissä, ja mekanismin sen hakemiseksi.' Hash-bang-pohjainen URL-osoite ei riitä määrittelemään sisällön noutomekanismia riittävästi, koska se vaatii JavaScriptiä paluupalvelimelle sen jälkeen, kun palvelin on jo lähettänyt selaimelle HTML-sivun - sivun, johon ei ole linkitetty pyydetty URL (vielä).

Toisin sanoen hash-bangs muuttaa mekanismia resurssin hakemiseen. Sitä ei enää määritellä yksinkertaisesti ja yksinomaan URL-osoitteen mallilla, vaan 'täysin toimivalla JavaScript-palvelimella, jonka palvelin on määrittänyt ja toimittanut ja jota selainkohtainen JavaScript-prosessori tulkitsee'.

Tämä saattaa tuntua pedanttiselta, mutta merkitys käy selväksi, kun tarkastellaan resurssien käytön todellisuutta. URL-osoitetta lataava selain on tietysti yleisin tapa ladata verkkosivusto, mutta se ei ole ainoa tapa. Kaikki yksinkertaiset wget- tai curl-pohjaiset yritykset hakea sisältöä verkosta eivät enää toimi, ja kaikkiin web-sisältöä lataaviin ohjelmistoihin on nyt sisällytettävä täydellinen JavaScript-jäsennin tällaisten URL-osoitteiden tukemiseksi. Ja kaikki olettaen, että JavaScriptiä ei suodata välityspalvelimen tai palomuurin kautta, eikä se sisällä virheitä missään sivulla. Kun käyttäjät sammuttavat JavaScriptin selaimessaan, nämä sivustot lakkaavat toimimasta.

Jos hiljaisen sopimuksen rikkominen ja koko sivuston turvautuminen hauras tekniikoihin ei ole tarpeeksi huono, hash-bangs ovat myös yksisuuntainen katu pysyvään ylläpitoon ja tukeen. Et voi käyttää URL-osoitteidesi palvelinpuolen uudelleenkirjoittamista, vaikka suunnittelisit uudestaan. Jos siis et halua rikkoa saapuvia linkkejä ja ihmisten kirjanmerkkejä, sinun on aina tehtävä jonkin verran käsittelyä verkkotunnuksesi ensisijaisella aloitussivulla näiden URL-osoitteiden tukemiseksi, kun olet asettanut ne siellä.

Siellä

AppStormissa on erinomainen yhteenveto hash-bang-ongelmasta

Huonoja käytäntöjä

URL-osoitteiden suunnittelussa on monia eri tapoja. Yllä olevat perustekijät ovat kaikki hienoja tekniikoita, mutta meidän pitäisi tietää, mikä tekee huonosta URL-suunnittelusta ymmärtämään ja arvostamaan sitä, mikä tekee hyvästä URL-suunnittelusta hyvää. Tässä on joitain vältettäviä käytäntöjä, alkaen pahimmista rikoksentekijöistä ja siirtymällä menetelmiin, jotka ovat vain huonosti suositeltuja:

Sivun tunnistemerkinnät

Jotkut (enimmäkseen muinaiset) sisällönhallintajärjestelmät tai blogimoottorit tunnistavat jokaisen ainutlaatuisen sivun pitkällä satunnaismerkkijonolla; jotain tällaista: 5F0C866C-6DDF-4A9A-9515-531B0CA0C29C.html. Jos sisällönhallintajärjestelmäsi tai sivustosi moottori luo tällaisia ​​URL-osoitteita, katso, miten tämä toiminto voidaan korvata tai poistaa käytöstä välittömästi. jos se ei ole mahdollista, sinun on parempi hankkia nykyaikaisempi CMS. Näillä URL-osoitteilla on vain haittoja - käyttäjille ja itsellesi - ja lukemattomia hyviä, moderneja järjestelmiä, jotka ovat käytettävissä sivustosi tehostamiseksi ja jotka välttävät tämän kauhean tekniikan.

Istunnon hajautukset

Vaikka sivustosi istunnoissa käytettävät hajautukset eivät olekaan niin pahoja kuin sivuille käytettynä, ne ovat silti huonoja.

Aluksi ne voivat vaikuttaa kielteisesti hakukoneoptimointiin. Suurempi huolenaihe on kuitenkin se, että useimmat heitä käyttävät järjestelmät käyttävät SHA-1: tä, joka on suhteellisen epävarmaa - varmasti käyttäjän istunnoissa tai kirjautumisissa, jotka sisältävät arkaluontoisia tietoja.

Tiedostotunnisteet

URL-osoitteissa ei saa olla .php, .aspx ja niin edelleen. Tiedostotunnisteet eivät ole yhteensopivia eteenpäin, joten jos muutat taustajärjestelmää ja kaikki URL-osoitteesi sisältävät .aspx-tiedoston, sinun on pakko tehdä palvelinpuolen uudelleenkirjoittaminen jokaiselle sivustosi sivulle. Kallis, tehoton ja täysin tarpeeton. Myöskään .html-laajennusta ei suositella, mutta jos olet varma, että palvelet rakennettavia sivuja vain staattisina tiedostoina, se on hyväksyttävä tekniikka.

Muut kuin ASCII-merkit

Sivustot, joissa merkkikieli on ensisijainen sisältökieli, ovat hieman tekosyynä, mutta aksenttista latinaa ja muita kuin välimerkkejä on parasta välttää.

kuinka puhdistaa iho Photoshopissa

Alaviivat

Näillä on huonompi käytettävyys ja SEO-arvo, eikä niistä ole konkreettisia etuja yli-väliviivoille.

Avainsanojen täytteet

Useiden avainsanojen lisääminen URL-osoitteisiin voi auttaa hakukoneoptimoinnissa, mutta se hämmentää käyttäjiäsi. Lisäksi vaarana on, että sinut merkitään avainsanan roskapostittajaksi.

Sisään

Vanhassa Twitterissä koko tämä yksittäinen twiitti on läsnä kahdesti: kerran sisällössä kuvauksena ja kerran sivulla. Kuitenkin...

... uusi Twitter ei sisällä lainkaan twiittiä, ja sen koko on 44 kilotavua. Sivun on suoritettava JS-jäsentelyympäristössä lataamaan tweetti tai se

... uusi Twitter ei sisällä lainkaan twiittiä, ja sen koko on 44 kilotavua. Sivun on suoritettava JS-jäsennysympäristössä, jotta tweetti ladataan, tai sitä ei voi noutaa

Hyvät käytännöt

Vaikka on tärkeää tietää, mitä tekniikoita kannattaa välttää, kannattaa tietysti tietää, mitä sinun tulisi käyttää. Meillä on nyt kaikki perusasiat käsitelty, joten katsotaanpa edistyneitä taktiikoita, jotka tekevät loistavista URL-osoitteista.

'Viileät URI-tunnukset eivät muutu', kuten Tim Berners-Lee sanoi vuonna 1998, mutta mikä paitsi tekee loistavista osoitteista sen lisäksi, että ne pysyvät pysyvinä uudelleensuunnittelussa? Joitakin keskeisiä näkökohtia ovat kestävyys, hakkerointi ja nimiavaruus.

Vankka URL-kartoitus

Ihmiset jakavat URL-osoitteesi, ja joskus he tekevät sen tietovälineessä, jossa vastaanottajien ympäristö saattaa kääri URL-osoitteen kahteen riviin. Tämä on yleisintä blogiviesteissä, joissa URL-osoitteessa on koko päivämäärä ja pitkä otsikko.

Yksi ratkaisu on pitää kaikki URL-osoitteet alle 70 merkkiä, mutta se ei ole aina ihanteellista. Lisäksi relaatiotietokantajärjestelmien luonne on sellainen, että ID-arvot etsivät nopeasti, mutta merkkijonot eivät.

Suurella liikennemäärällä tämä voi olla riittävän vakava pullonkaula palvelimen kaatamiseksi. Lisää laitteistoja voi olla kallis ratkaisu.

Vankka URL-kartoitus voi ratkaista molemmat ongelmat puolestasi. Upottamalla yksilöllinen tunnus varhaisessa vaiheessa polkuasi, sinulla voi olla pitkiä, täysin kuvaavia URL-osoitteita tarvittaessa, mutta voit silti nauttia lyhyempien URL-osoitteiden luotettavuudesta ja tunnisteiden hakujen nopeudesta.

Valitse tämä URL: yourdomain.com/news/1982-this-is-a-longer-news-posts-title- joka-melkein varmasti rikkoutuisi uudelle riville joissakin- asiakkaita. Tässä esimerkissä ’1982’ on tietyn tietokannan tietueen arvo tälle viestille. Sisällönhallintajärjestelmäsi voisi käyttää onnistuneen haun vain URL-osoitteen tätä osaa: yourdomain.com/news/1982.

Kaikki sen jälkeen on valinnaista ja mukavaa ihmisille ja hakukoneoptimoijille, mutta ei ole väliä, kääritäänkö se kahteen riviin.

Ainoa haittapuoli tässä tekniikassa on, että henkilötodistukset eivät itse ole niin ihmisystävällisiä, joten se on harkittava kauppaa.

Hakkattavat URL-osoitteet

Hyvässä hakkeroitavassa URL-osoitteessa ihminen voi säätää tai poistaa polun osia ja saada odotettuja tuloksia sivustoltasi. Ne antavat kävijöille paremman orientaation sivuillesi ja mahdollistavat helpon tason siirtymisen ylöspäin. Esimerkki: yourdomain.com/blog/2011/05/20/some-article. Pienentämällä se eteenpäin jokaiseen kauttaviivaan pitäisi tuottaa odotettavissa olevia tuloksia. Esimerkiksi verkkotunnuksesi.com/blog/2011/05/20/ pitäisi palauttaa kaikki 20. toukokuuta 2011 julkaistut viestit. Yourdomain.com/blog/2011/05/ antaa yleiskatsauksen toukokuun 2011 viesteistä, kun taas yourdomain.com/blog / 2011 / -toimintoa voidaan käyttää yleiskatsauksen julkaisemiseen vuoden 2011 viesteistä tai, jos se on liian rakeista, kirjoita vain jokaisen kuukauden kokonaissummat. yourdomain.com/blog/ pitäisi palauttaa viimeisimmät päivitykset niiden todellisesta julkaisupäivästä riippumatta.

Kuinka yksityiskohtainen sinun pitäisi olla tällaisten URL-osoitteiden suunnittelussa, riippuu todella sivuston sisällöstä ja yleisöstä. Mitä ajankohtaisempi sisältö on, sitä enemmän se hyötyy julkaisupäivistä URL-osoitteessa; mitä useammin uutta sisältöä julkaistaan, sitä enemmän se hyötyy hienommasta tarkkuudesta.

Muut alueet - kuten luokat, tuotteet ja palvelut - eivät tarvitse päivämääräkomponentteja, mutta riippumatta siitä, kuinka yksityiskohtaiset (tai eivät) URL-osoitteesi päätyvät, niiden pitäisi viime kädessä olla täysin hakkeroitavissa.

On virhe sanoa, että hakkeroitavia URL-osoitteita käyttävät vain teknisesti taitavat kävijät, ja hylätä ne, jos yleisösi ei ole kyseisessä kapealla. Ensinnäkin, käyttäjät saavat vain enemmän teknistä taitoa ajan myötä, ei vähemmän. Mutta mikä tärkeintä, et tunne kaikkia kävijöitäsi, nykyisiä ja tulevia.

Nimitilat

Polun ylätason osa on URL-osoitteen arvokkain kiinteistö. Jos sivustosi avulla käyttäjät voivat rekisteröityä ja heillä on oma profiili tällä tasolla, sinun on luotava musta luettelo käyttäjänimistä, joka sisältää kaikki nykyiset ja mahdolliset tulevat ominaisuudet, joita saatat haluta olla. Löydät hienoja esimerkkiluetteloita Quora tätä varten.

Käyttäjätunnuksen takana olevat nimiavaruusominaisuudet: luettelot tai / seuraajat ovat loistavia ratkaisuja julkisiin ominaisuuksiin, jotka kuuluvat jokaiselle käyttäjälle erikseen.

Yksityisiä asioita, kuten tilin asetuksia, ei saa koskaan jättää nimiavaruuteen käyttäjänimen taakse, ja niiden pitäisi näkyä vain / account tai / settings jälkeen. Älä myöskään sekoita tekniikoita täällä. Jos aloitat joidenkin ominaisuuksien asettamisen / feature / ja toiset / feature -ominaisuuksien alle, saat vain hämmentää käyttäjiäsi.

Jos aloitat sivuston blogina, mutta aiot rakentaa sitä tulevaisuudessa, harkitse kaikkien viestien lisäämistä / blog / -kansioon ylätason nimitilaksi, jotta vältetään mahdolliset ristiriidat myöhemmin.

Quoralla on hyviä neuvoja estää käyttäjätunnuksesi rekisteröinti

Quoralla on hyviä neuvoja estää käyttäjätunnuksesi rekisteröinti 'varastamasta' arvokkaita URL-avainsanoja

Liiketoiminta

Koska URL-osoitteet ovat niin tärkeä osa verkkosivustoasi tai sovellustasi, niiden pitäisi olla ensimmäisiä asioita, jotka suunnittelet ja työskentelet tiimisi kanssa. Ei vain siksi, että et halua joutua muuttamaan niitä ajan myötä, vaan siksi, että suuren rakenteen luominen etukäteen auttaa ymmärtämään ja kiteyttämään käyttäjän tarpeita ja vaatimuksia sekä omia liiketoiminnan vaatimuksiasi.

Hyvien URL-osoitteiden suunnittelun tulisi olla yhteistoimintaa; jos tiimissäsi on omistautuneita tietoarkkitehteja, heidän tulisi olla mukana. Sama koskee tietokanta-arkkitehteja, käyttöliittymän johtajia ja pääsuunnittelijoita. Hyvän URL-osoitteen keksiminen ei ole pelkästään markkinointi- tai käyttäjäkokemustesi tehtävä; se on merkityksellistä ja tärkeää kaikille tuotteen valmistamiseen osallistuville.

Kun sinulla on URL-rakenteenne, voit suunnitella täydellisen sivustokartan nopeasti ja helposti. Tämä auttaa informaatioarkkitehteja suunnittelemaan suuren hierarkian ja navigoinnin, taustaprojektit työskentelevät tehokkaasti ja käyttöliittymäkehittäjät muuttavat osioiden ja sivujen laajuuden puhtaiksi merkinnöiksi ja koodeiksi. Käsitteellisestä suunnitteluvaiheesta eteenpäin suunniteltu ja yhteistyössä suunniteltu loistava URL-rakenne auttaa parantamaan verkkotuotettasi kaikin tavoin.