Taigi, tam, kad sukurti pakankamai patogų interfeisą, reikia rašyti daug kodo eilučių. Tai natūraliai turi įtakos veikimo greičiui. Tam, kad sistema veiktų greitai, kartais tenka aukoti funkcionalumą, o kartais tenka rašyti visiškai nesuprantamą galvosūkį keistų simbolių, kurių net patyrę programuotojai nesupranta. Tam, kad kodas būtų lengvai skaitomas ir nekeltų daug problemų, kai reikia jį tvarkyti, tenka aukoti kitus dalykus, pvz. tą patį accessibility. Kad padaryti kažką arčiau tobulumo, tenka sugaišti begalybę laiko ir pinigų, ir tada atsiranda problema su tais, kas užsakinėja muziką.

Žiūrint prezentacijas, įvairūs specialistai vis kartoja savo srities mantras – “daryk taip ar anaip, ir sutaupyk trečdalį sekundės siuntimo laiko”, “agile procesas sako, kad nereikia per daug laiko skirti planavimui”, “user centered procesas sako, kad reikia skirti pakankamai laiko vartotojų tyrimams ir pasiruošimui”. Dar anądien ir pats norėjau parašyti blog’ą apie tai, kaip paprasta naudojant naujus HTML5 atributus ir elementarias “geriausias praktikas” suprogramuoti patvirtinimo dialogą, kuris veikia visose situacijose, įdedant “vos keletą eilučių daugiau” kodo (gal ir parašysiu kada kai bus gera nuotaika).

Atmetus seną gerą taisyklę, kad iš “gerai”, “pigiai” ir “greitai” galima pasirinkti tik du, aš savo kasdieniame darbe, kodą rašau remdamasis maždaug tokiais principais:

0. Kodo grožis – žr. paskutinį punktą šiame sąraše.
1. Produkto patogumas – aš linkęs paaukoti labai daug kitų dalykų tam, kad galutinis rezultatas patenkintų galutinį vartotoją – ar tai būtų klientas, ar kitas programuotojas naudojantis mano API.
2. Minimalizmas – jeigu kažko galima nedaryti – aš padarysiu viską, kad to nedaryti. Šitas principas iš esmės paaiškina du žemiau esančius punktus. Papildoma taisyklė – blogas programuotojas tas, kuris nėra tinginys.
3. Palaikymo kaina – iš esmės susiveda į tai, kad reikia rašyti mažiau kodo ir reikia jį organizuoti kuo mažesniais, suprantamais gabaliukais. Visa tai galutiniam rezultate reiškia a) mažiau šansų vabaliukams b) lengviau suvokti. Be abejo, sutrauktas ir minimalizuotas kodas nereiškia, kad jis yra lengviau suprantamas ar palaikomas (čia ypač tinka kalbant apie tokius dalykus kaip visa Perl kalba, regex arba LINQ) – šis principas yra iš esmės narciziškas ir remiasi į tai, kad atėjęs kitas žmogus nesugadins veikiančio dalyko.
4. Sukūrimo kaina / produktyvumas – šis punktas yra skiriamoji linija – dėl visko, kas yra aukščiau jo, aš linkęs aukotis ir sėdėti viršvalandžius. O kalbant apie tai, kas yra žemiau jo, tai tikėtinas variantas yra, kad aš paliksiu @todo žymeles.
5. Standartai, best practices ir “teisingumas” – šis principas anksčiau būdavo gerokai aukščiau šiame sąraše – turbūt dėl to dabar dėl tokių dalykų nebereikia jaudintis, nes jie ateina natūraliai. Tiesiog, įvertindamas kitus faktorius mieliau pasirinksiu paprastumą vietoj devynaukščio objektinio dizaino pattern‘o. “Teisingumas” šiuo požiūriu reiškia puritoniškumą ir naivų idealo siekimą, o ne tiesiog “veikiantį kodą”.
6. Accessibility – iš dalies čia truputį gėda. Iš kitos pusės, lygiai kaip ir su standartais ir “teisingumu” – tiesiog esu įpratęs padaryti tam tikrą kiekį šito darbo automatiškai ir nesistengdamas, o daugiau papildomų pastangų tam nededu, nes jos daugiau kainuoja, negu duoda naudos.
7. Plečiamumas – praktiškai niekada nededu papildomų pastangų vien tam, kad patenkinti vidinį spirgėjimą “o jeigu netyčia prireiktų padaryti XYZ” – net jeigu ateityje nepavyksta padaryti chirurgiškai tikslaus, vienos kodo eilutės dydžio, įpjovimo tam, kad sukurti papildomų funkcijų, susumavus vistiek išeina tiesiog pigiau refactorinti ar net perrašyti.
8. Veikimo greitis – čia nekalbu apie varotojo suvokimą/įsivaizdavimą apie interfeisą – daugiau apie realius CPU/atminties resursus. Manau, kad geriausia yra žinoti tobulintinus dalykus, tačiau pasitenkinti tiesiog “gerais programavimo įpročiais” tol, kol nereikia to tvarkyti. O kai prisireikia tvarkyti – visų pirma gerai pamatuoti!
9. Kodo grožis – paminėjau šitą dalyką pirmu numeriu, tačiau labai retai darau taip, kad kodas atrodytų “gražus”. Grožis yra subjektyvus, o patenkinus visus aukščiau esančius reikalavimus, kodas pats savaime atrodo gražus.

Dabar kai jau surašiau juodu ant balto klaviatūra į ekraną, viskas atrodo taip akivaizdu… Ką praleidau? Kokia jūsų prioritetų tvarka?

Renkantis turinio valdymo sistemą, visada dera įvertinti tai, kad ją reikės keisti. Štai WP nėra pritaikytas PHP5 – ką jau bekalbėti apie PHP6, be to laikas nuo laiko išeina naujos jo versijos. Ir apskritai soft’as nėra amžinas – jo keitimas yra tiesiog garantuotas ilgalaikiu laikotarpiu. Tuo tarpu renkantis svetainės struktūrą reikėtų atsiminti, kad jos keitimas gali brangiai kainuoti. Renkantis adresų struktūrą visų svarbiausia įsidėmėti, kad jos keitimas užtruks ilgą laiką – tokio pragaro nelinkiu niekam.

Robotams ir vartotojams

Pirma adreso taisyklė SEO (einanti po nulinės “prikišk daug keywordų”) – jis neturėtų keistis ir idealiame pasaulyje turėtų būti amžinas. Jeigu jis pasikeitė – be abejo galima sudėlioti teisingus HTTP redirektus (301 Moved Permanently į naują adresą, vėliau laikui bėgant pakeisti į 410 Gone). Tačiau net su redirektais, adreso keitimas užsitraukia paieškos robotų nemalonę. Pavyzdys iš realybės: dar dabar kai kurie paieškos varikliai yra sucache’inę seno mano darbovietės puslapio variantą su ASP adresais ir nenori jo užmiršti. Keitimas įvyko prieš 2 metus.

Adreso pasikeitimas taipogi turi reikšmės tarp lankytojų – jų išsaugotos nuorodos pradingsta – nesvarbu ar tai buvo tiesiog browseryje, digg’e, del.ici.ous ar kaip.tikten.lt. Jeigu siekiate gero ir ilgalaikio rezultato – svetainės (ar blog’o) struktūra turėtų išlikti pastovi, net išėjus naujai PHP ar WordPress versijai, o tuo labiau pasikeitus pačiam administravimo įrankiui.

Dar viena SEO taisyklė yra “Vienas turinys – vienas adresas”. Google gana aiškiai yra išreiškusi savo poziciją apie duplicate content – ir nors dažnai jis gali atsirasti “netyčia”, į tai reikia atsižvelgti ir bent pasistengti to vengti. WordPress iki 2.3 versijos leisdavo pasiekti tą patį įrašą bent 3-4 būdais. Nors dažniausiai tos nuorodos būdavo standartinės, tai mažų mažiausiai kėlė betvarkę – fui. Net nepaisant papildomos paieškos variklių nuobaudos “neįvertinimo” pasikartojančiam turiniui, nesilaikant vieningos nuorodų struktūros prarandama dalis link juice – t.y. turinio (įrašo) reitingas padalinamas keliems adresams, o ne vienam.

Tai ko aš nepatenkintas?

WP 2.3 versija standartiškai stengiasi perkelti į canonical adresą – t.y. adresų taisyklė yra enforce’inama. Tačiau ar to pakanka? Naršant po kategorijas, archyvus, žymes ir kt. WP standartiškai rodo visą įrašo tekstą (nebent naudojama more žymė ir/arba papildomi nustatymai. Tai reiškia, kad duplicate content problema nėra išspręsta. Taipogi problematiška dalis yra puslapiavimas – įdėjus naują įrašą, viskas persislenka žemyn – tuo pačiu, tas pats turinys kuriam laikui atsiranda keliuose puslapiuose (bent laikinai – page/2, page/3). Viena bjauriausių situacijų su radinukais paieškoje būna kai ieškomas tekstas yra pvz. adrese forum.php?page=10 – tačiau kadangi virš ieškomo teksto jau žmonės yra papildomai ką nors parašę – tikrasis tekstas yra atsidūręs jau forum.php?page=12.

Paprasto sprendimo šiai problemai nėra, tačiau tiek kategorijos, tiek archyvai blog’e tėra rodyklės (turinys, index, sugalvok savo žodį) – todėl jie ir turėtų elgtis kaip tokie. Kadangi blog’as pagal savo definitioną yra chronologinis dalykas, manau, kad vienas iš mažiausiai kenksmingų variantų būtų rodyti kategorijos (tago) puslapyje kelis paskutinius įrašus, o toliau leisti browsinti pagal datą – jeigu kategorija (ar visas blogas) ganėtinai aktyvus – rodyti sakykim mėnesio įrašus, jeigu mažiau aktyvus – rodyti visus metų įrašus, taip atsikratant puslapiavimo poreikio, o tuo pačiu – niekam tikusių puslapiuotų adresų.

Adreso bei turinio pastovumas ir “patikimas” buvo dvi esminės problemos, kurios mane ilgiausiai stabdė paleidžiant savo blog’ą – norėjosi skirti pakankamai laiko apmąstymams ir šiaip dėsningumų įvertinimui tam, kad nesigailėčiau tada kai pradėsiu pasitikėti Habari. Artimiausiame įraše – mano apsisprendimas dėl struktūros.

• URL, kaip failų sistemos atspindys, reiškia failą
• URL identifikuoja failo vietą – direktoriją, kurioje jis guli
• URL identifikuoja failo turinį (failo pavadinimas – turinio pavadinimas)
• URL identifikuoja failo tipą (pagal išplėtimą)
• URL padeda indetifikuoti failo statiškumą/dinamiškumą

URL identifikuoja failą

Pati URL sąvoka reiškia būtent tai, kad jis yra nuoroda į kažkokį resursą. Jeigu kalbėti apie web svetaines – senų senovėje HTTP metodas GET reikšdavo “atsiųsk man šitą hipertekstinį failą, iš anos direktorijos, iš to serverio”. Tai be abejo tiko statiškam turiniui, ir atsiradus visokiai dinamikai tai nustojo šiek tiek galioti.

URL identifikuoja failo vietą

Aš esu per jaunas, kad atsiminti vienos dimensijos failų sistemas, nors ir teko naudotis santakomis, kurios užsikraudavo iš kasečių. Bet kuri padori failų sistema yra hierarchija suskirstyta į direktorijų medį, su failais juose. Bet kuri didesnė web svetainė taipogi turi savo struktūrą – dažniausiai užtenka elementaraus medžio. Kalbant apie blog’us – to pakanka.

URL identifikuoja failo turinį

Šitą principą jau seniai įsikando visi optimizuotojai ir dauguma turinio valdymo sistemų jam yra pritaikytos. Paprastais žodžiais kalbant – puslapio/įrašo turinys privalo sutapti su tuo, ką matome adrese, t.y. iš esmės su jo pavadinimu.

URL identifikuoja failo tipą

Žiūrint iš vartotojo pusės, jeigu adrese nesimato turinio formos – turinys gali būti pavojingas. Iš dalies, tai yra optinė apgaulė (hell – sandros papai ir panašūs virusai būtent remiasi tuo, kad vartotojas matydamas .jpg išplėtimą tikisi .jpg failo), tačiau aš visiškai nemėgstu spausti nuorodos ir ten netikėtai rasti PDF dokumentą. Ši taisyklė šiek tiek gadina reikalą, jeigu kalbame apie mobile content, nes priklausomai nuo aparato/naršyklės tenka keisti failo tipą (WML <-> cHTML, etc.), tačiau kol kas tą ketinu ignoruoti, nes pradžioje mano turinys vistiek nebus pritaikytas WAP’ui.

URL identifikuoja turinio statiškumą

Kaip jau minėjau aukščiau, atsiradus dinamiškam turiniui tinkle, šiek tiek nustojo galioti principas, kad URL rodo į failą. Mano nuomone, dinamiškumas turi būti atspindėtas query string (elementariaus pavyzdys – paieškos filtras ir jo parametrai adrese). Jeigu kalbėti apie blog’us ir šiaip didžiąją dalį svetainių – turime gana statiškų resursų rinkinį (t.y. nekeičiančių savo prasmės ir turinio) – daug įrašų, kurie iš esmės tėra HTML failai, gulintys savo vietoje. Tam ir yra skirti permalinks.

URL ir SEO yra skirti žmogui

Google savo nurodymuose teigia, kad nereikėtų rūpintis puslapio optimizavimu robotams – reikia rūpintis vartotojais. Net jeigu dalis iš mano išvardintų reikalvimų adresui neturi jokios reikšmės paieškos robotams, jie yra svarbūs lankytojui. Gera nuoroda lengva dalintis, be to ji gerai atrodo ir SERP. Šiuolaikiniame internete, paieškos robotai privalo prisitaikyti prie žmogaus ir prie internetinės realybės (t.y. didelio bardako), tačiau aš mėgstu tvarką ir prasmę. Adresas /2007/12/noriu-padorios-adresu-strukturos.rss2.xml man yra tiesiog malonesnis ir prasmingesnis už /2007/12/noriu-padorios-adresu-strukturos/feed/ ar tuo labiau už /index.php?p=4&feed=rss2

Šiame įraše paminėjau tik esminius meta reikalavimus URL struktūrai – tačiau vien to geram adresui negana. Turint plačias galimybes, galima nesunkiai viską sugadinti, o be to žvelgiant iš SEO perspektyvos – yra ir keletas papildomų reikalavimų, kuriuos dera apžvelgti atskirai.