SEO

Veebilehe optimeerimine otsingumootorite jaoks oli kunagi kas maagia, häkkimine või soolapuhumine – oleneb kellega rääkisid. Tänapäeval mõistavad kõik selle tegevuse kasu ja vajadust ning reeglina on teenus sisse ehitatud ka juba mingi suurema paketi sisse. Samuti on aja jooksul ka otsingumootorite algoritmid mis aitavad kaasa SEO-le muutunud läbipaistvamaks ja selgemaks.

Põhiline optimeerimine on reeglina lihtsalt rusikareeglite järgmine ja heade tavadega kooskõlas olemine. Hoia leht puhtana pahavarast, turvaline ja ära uputa üle reklaamidega. Juba sellega oled teinud ära suure töö oma veebilehe nähtavamaks muutmiseks. Sealt edasi saad minna peaasjalikult ilma liigset SEO-d tundmata loogilist teed pidi. Ehk struktureerides oma leht loogiliselt, kasutades pealkirju mõistlikes järjekordades, kasutades alt teksti oma graafikal ning arial labeleid oma navigatsioonil aitab sind viia oma leht laiemale publikule läbi võimaldades lehe külastamist näiteks vaegnägijatel kui isikutel kes kasutavad vananenud tehnoloogiat kui ka robotitel kes indekseerivad sinu veebilehte otsingumootorite jaoks.

Nii nagu turvalisuseski kipuvad ka optimeerimistes (olgu kiiruse, otsingumootorite või kasutajamugavuse heaks) olema põhimuredeks juba üldtuntud praktikate mitte järgimine ning lihtsalt halb konfiguratsioon. Kõik mis sealt edasi tuleb on siiani mingil määral maagia, häkkimine või soolapuhumine : )

link

A/B testimine

Veebilehestiku testimine on aastatega läinud tunduvalt palju keerulisemaks ja abstraktsemaks. Ennekõike seetõttu, et kui veel hiljaaegu peeti oluliseks vaid seda kas klikkides lingil ka link avaneb või sooritades ostu ka arve laekub siis nüüd loevad juba laiemad ja raskemini hoovatavamad mõisted.

Üks keskne mõiste selleks on UX, lühend mis tekitab hirmu ja segadust arendajate seas ja mida justkui hõbekuulina tulistavad disainerid söögi alla ja söögi peale. Eesti keeleski kõlab kasutajakogemus justkui kliiniliselt ja elukaugelt.
Sellise abstrakse mõiste testimine on aga keeruline. Suisa keeruline, et juba omaette teadusharuks kujunenud ja kõik interaktsioonidisaini fanaatikud omadel konverentsidel arutama tulevad kas punane värv on hoiatuslik või keelav.

Selle kõige lihtsamaks tegemiseks on tekkinud terve haru teste mille keskmes on kasutaja ise ja seda testijana. Vaid kasutaja teab mis tema jaoks loogiline tundub ja kuidas erinevad veebilehe aspektid (olgu ned CTA-d või muud taolised) paremini esile tulevad. Kas see punane värv on õigel kohal või mitte.
Üks populaarsemaid testimis meetodeid on A/B testimine kus kasutajad suunatakse erinevatele versioonidele samast lehest ning hiljem kas antakse kasutajale võimalus tagasiside esitamiseks või tehakse n.ö black-box meetodil kus vaadatakse hiljem kumma lehe versiooni puhul oli rohkem kasutajaid kes järgisid mingit CTA-d, linki või muud mõõdetavat väärtust.

Tehniliselt on A/B testimine võrdlemisi lihtne, vähemalt meie keskkonnas kus meil on rakendatud Google Analytics ja WordPress. Küsimus on vaid mõningase üksiku plugina installimises ning saadki juba otse oma GA kontolt seadistada A/B testimise sätteid.
Küll aga selleks, et saada maksimumi oma testimisest ning mitte kaotada palju kliente (paljud meist ikka tahavad olla osa eksperimendist) on soovitatav õppida tundma asja rohkem koodilähedaselt. Sest ega ka A/B testimine on osa sinu lehe UX-ist.

 

link

Disain vs UX

Analüüsides ühe veebilehe muutmise lugu (kujutame ette, et tegemist on ühe suurima Eesti jaekaubandusketiga) siis silma kipub jääma vastakad seisukohad ja möödarääkimised.

Selles kõiges julgen laiemas laastus süüdistada tehnilist valdkonda ja seda, et tihti peavad koos töötama turundus (kliendi poolt) ja IT arendus (teostaja poolt).
Mõlemad, olles tunnustatud ja hinnatud spetsialistid kipuvad aga ära unustama, et on inimesed ja ennekõike erinevad. Seetõttu tihti räägitakse üksteisest mööda ja seda juba maast madalast.
Ise olen tõdenud ühe suure jaekabandus keti veebilehele uuenduskuuri tegemisel, et just kommunikatsioon on see põhiline mure mis tekitab nii ajalise kitsikuse kui eelarvest väljumised.
Turundus inimesed kipuvad veebilehte nägema kui ühe suurema reklaamtahvlina (mis ta mõningas mõttes ka paratamatult on), küll aga unustatakse selle juures ära, et kient peab suutma sellelt reklaamtahvlilt üles leida info mis just teda huvitab ja ka tegema selle liigutuse (olgu lingi klikkimine või toote ostmine) mis ettevõtet huvitab. Ehk kaks asja mis kipub tihti kliendi endi esindajaid segadusse ajama on “reklaamtahvli” interaktiivsus, navigeeritavus, arusaadavus jmt. ning kasutajakogemuse aina süvenev isiklikustumine ja kohandatavus.
Seetõttu kipuvadki kliendi poolsed esindajad tihti rääkima veebilehe puhul disainist, CVI-st ja CTA-st nagu hõbekuulidest samas kui kogenud veebilehtede looja räägib UI, UX ja ID-st kui religioonist mida tuleb laiemalt mõista.
Seetõttu ongi vaja neutraalset poolt, kedagi kes mõistab põgusalt nii tehnilist poolt kui turundust, nii disaini kui kasutajakogemust. Olgu see keegi kas product owner või projektijuht või mõni kolmas osapool on tema töö olla tõlk. Tuua kõik ühe laua taha ja ühe lehe peale. Hoida silma peal ja vajadusel vastutada. Ja ennekõike – üritada vältida selliste stereotüüpi teket nagu “kliendid ei tea mida nad tahavad” või “arendajad ei oska rääkida”.

 

 

link

Domeeni registreerija, nimeserver ja majutus.

Sissejuhatavaks teemaks valisin praktiliselt läbi proovitud ja endalegi üllatustega vastuseid toonud küsimuse. Kui seada üles veebilehte, kas eelistada kõiki teenuseid ühe komplektina või eraldi? Eriti kui räägime nii elemetaarsetest teenustest nagu domeeni registreerimine, nimeserveri teenused ja majutus.

Mõned ajad tagasi kui veebilehtede loomine liikus teismeliste magamistoast ja hobiliste keldritest kesklinna kontoritesse hakkasid tekkima nõuded ja standardid. Algselt olid küll igal ettevõttel omad arusaamad mis on veebi puhul oluline ja mis mitte, rääkimata mustmiljonist tõlgendamise võimalusest. Küll aga päris ruttu jõuti arusaamale, et mingid põhi punktid peavad olema kõigil täidetud.
Nendeks põhipunktideks veebilehe puhul said kättesaadavus ja stabiilsus.

Olenemata katsetest tõlgendada ka neid väheseid põhimõtteid igaühe poolt erinevalt oli selge, kui ikka nimeserver ei vasta siis ei ole vahet kui vinge su veebileht on või ei ole.
Seetõttu ka mina oma esimesel veebitööl olin kimbatuses, kuidas garanteerida need eelpool nimetatud elementaarsed teenused mida võib ehk nimetada isegi taristulisteks.
Minu valik tol ajal oli eraldi registreerija, eraldi nimeserveri teenuse pakkuja ja eraldi majutus.

Registripidaja

Registripidajatel on palju võimu üle veebilehe. Viimasel ajal on hakatud puht skeemitama odavpakkujate poolt pakkude näiteks TASUTA veebiaadressid kui tellid majutuse. Selle all aga tihtilugu peetakse silmas veebiaadressi renti ning peale seda kui su leht piisavalt suureks saab, et soovid mujale kolida majutuse, tavitatakse sind, et sa isegi ei oma aadressid ja pakutakse päris krõbedat hinda selle omandamiseks.
Peale skeemitamise on registripidajatel võimalus (olles küll paljudes riikides ebaseaduslik) pakkuda igale kliendile erinevat hinda olenevalt püsikliendi taustast. Näiteks kui enamus sinu omatud aadressitest sisaldab sõna insurance, siis võid päris kindel olla, et järgmist taolist domeeni ostes saad oluliselt erinevama hinna võrreldes mõne muu kliendiga.
Endast natuke rohkem lugupidavamad registripidajad aga lähenevad domeenide müümisele nagu aktsiatesse investeerimisele – ilma investeerimata. Nimelt kipuvad kuskil taustal jooksma tarkvara mis kalkuleerib erinevate loogiliste tingimuste kaudu välja domeeni eeldatava hinna enne selle müüki, mille kaudu manipuleeritakse hinda, mis võib kõikuda sadades, kui mitte tuhandetes eurodes.
Seetõttu võib registripidaja valik olla tihti puht majanduslik küsimus millel võib kaugele ulatuvad tagajärjed olla. Pealegi – kõik registripidajad lihtsalt ei paku kõiki TLD-sid, ka see võib olla määrav.

Nimeserverid

Eraldiseisva nimeserveri pidaja juurde minek oli juba rohkemal määral eksperimentaalne küsimus. Kuigi peab mainima, et isegi tänapäeval on paljud majutusteenuse pakkujad jätnud unarusse oma nimeserveri poole ajades sellega kliente eemale.
Ainult nimeserverite pidamisele pühendunud teenusepakkujad aga annavad sulle ligipääsu kõikidele parameetritele. Küll aga mitte sind ülehoomava keerukuse ja raske õpikurviga. Selle viimase osa oluline lihtsustamine on üks suurimaid osi nende tööst.
Peale mugava ja lihtsa (reeglina) veebiliidese kaudu DNS recordite muutmise pakuvad nad tihti äärmiselt kasulikke lisateenuseid nagu DNS tasemel kiir suunamised e-maili teel, või muutujate kasutamine DNS andmetes. Viimane suudab teha mitme päevase näiteks SPF andmete muutmise õige konfiguratsiooni korras, minutite küsimuseks.

Majutus

Veebilehe majutamine on nii populaarne blogiteema, et siin ma sellele pikemalt ei peatukski kui vaid mainida – võttes ära registripidaja ja nimeserveri osa oma majutusteenuse pakkujalt ei ole viimasel enam pea midagi millega sundida sulle peale uusi hinnapoliitikaid, muutunud teenusetingimusi või muud taolist. Majutuse vahetamine tagavarakoopiate olemasolu korral ei tohiks olla rohkema kui mõnekümne minuti küsimus, seda ka keskmise suurusega veebilehtede puhul.

link

Teema paigaldamine

Valisin “teemaks”  Square

Antud disaini valisin soovil kasutada eelvalmistatud disaini millel on mitmetasandilised haldusmenüüd ja korraliku sisu segmenteerimise võimalused. Eesmärgiks on siis katsetada läbi niipalju erinevaid stsenaariumeid kui võimalik ühe ja sama disainiga. Olgu see siis õppe eesmärgil või omaks huviks.

Pildi muutsin ka kolmandal slaidil ära. Selleks kasutasin stockphoto lehte Pixels mis ei nõua viitamist ega autoritasu.

Lisa “teemadeks” valisin järgnevad:

• Integral

Antud kujundus annab hea minimalistliku ja otsekohese blogi vaate. Kus keskmeks above the fold saab olla sinu CTA ning kõik sealt edasi on juba klassikaline blogi. Samas selle otsekohesusega kaasneb raskus muude kasutaja jaoks oluliste osade lisamisega kuna disain on piiratud vaid nende kahe põhi elemendiga.

• Lihthouse

Lihtne blogi kujundus mis prioritiseerib blogi sisu ning seetõttu hoiab eeldatavalt kasutaja tähelepanu sisul. Samuti on olemas mitme meetodiga sisu otsing ning ilma meetodita tavaotsing mis kõik taaskord toob esile selle mille pärast leht üldse olemas on – sinu blogi. Miinused on võrdlemisi sarnased eelmise disainiga kus põhi kitsaskoht on disaini enda vägal kitsal sihtgrupil. Ehk mis on blogi jaoks ideaalne ei pruugi olla vähimalgi määral sobiv näiteks start-upi tutvustamiseks.

• Athena

Athena on juba natukene keerukam disain mis annab võimaluse suunata lehe kasutajat keerukamaid võtteid kasutades ning samuti muuta lehe fookuses olevat sisu tüüpi ilma oluliselt kujundust muutmata. Ehk antud disain saab enda tuumikus kanda nii klassikalist blogi kui toodet või teenust. Samas selle paindlikusega kaasneb natukene kohmakas seadistamine ja ülalpidamis keerukus. Samuti võib kogenematu sisuhalduse kasutaja muuta suhteliselt kerge vaevaga lehe lõppkasutajale segaseks ja raskesti navigeeritavaks.

 

Viide ülesadele

CMSi paigaldamine

https://www.puiestik.ee/kool/veeb

Paigaldatavaks CMS-iks osutus WordPress. Seda ennekõike põhjusel et ei ole varem proovinud täisautomaatseid paigaldusmeetodeid.

Paigaldus toimus ZONE keskkonnas ning läks hõlpsalt. Sai valitud automaatne paigaldus ja automaatne LetsEncrypt sertifikaat. ZONEi scriptid said sellega edukalt hakkama. Omaltpoolt sai lisatud .htaccess restricted area reegel wp-admin kaustale kui juurkaustana ning lisatud WP installatsioonile WordFence Security plugin. Esimene nendest siis oli nõue ja teine sest reeglina olen kasutanud Sucuri Securityt (ennekõike file integrity kontrolli tõttu) kõll aga on WordFence päris palju populaarsust kogunud ja äkki on seda ka väärt. Siiamaani – kena on küll näha rohkem infot dashboardis ent file integrity check puudumine ja brute force kaitse puudumine (päriselt? aastal 2017? veebis ilma brute force protectionita?) tekitab küll tunde nagu living on the wild side, ja mitte heas mõttes.

Üldiselt oli protsess suhteliselt streamlined, aega võttis kuni 10 minutit ja tulemus oli ootuspärane (eeldusel, et automaatse paigaldusega üllatusi ei tehtud, näiteks kas TLS sertifikaadi automaatne uuendamine on sees?). WordFence IDS reeglite kontrollimine võtab tõenäoliselt küll paar järgmist nädalat ent äkki on seda väärt.

Ka kohustuslik meem:

Viide ülesandele

WordPress VS Drupal

Kujutame ette, et meie kliendiks on ilusalong kes soovib veebilehte kogu täiega. Kogu täie all pean silmas galeriid, WYSIWYG teksti redaktorit, blogimisvõimalust, admin paneeli jmt.

Siinkohal tuleb tõdeda, et ükskõik kui hea arendaja sa ka poleks ei suuda sa eales konkureerida kui sa ei kasuta CMS lahendust.

Küll aga mis sisuhaldus on õige valik? Arvestades kliendi ja tema nõudmisi teeme julge oletuse, et klient ei tunne end just kõige kindlamini arvutit kasutades. Samas soovib ta hallata kogu oma veebilehte ise. Siinkohal peab aga klient silmas haldamise all postituste loomist ja muutmist, mitte sisuhaldusesüsteemi uuendamist, nähtavate tekkivate turva aukude lappimist jmt.

Valisin alguspunktiks kaks populaarsemat sisuhaldussüsteemi, Drupal ja WordPress.

Drupal

Drupal on kõrgelt hinnatud sisuhaldusüsteem mis suudab peale klassikalise sisuhaldussüsteemi funktsioonide pakkuda ka pea konkuretsitult parimat turvalisust. Drupal lubab luua keerulisi kasutajate õiguste tasemeid ja piirata ära ka ressursside õigusi.
Selle kõige juures pakub Drupal ka äärmiselt laia modulaarsust läbi mille saab antud sisuhaldussüsteemi tõepoolest muuta milleks iganes süda lustib. Paindlik API ja modulaarsus ka süsteemi tuumas teeb antud CMS lahendusest ühe parimaid.
Kõike arvesse võttes on siiski Dupal vahest lõppkasutajale liiga keeruline. Samuti on arendajale õppimiskurv järsk ning nõuab alguses aega, et rakendada Drupalit tema täies hiilguses.

WordPress

WordPress on vaieldamatult populaarseim sisuhaldussüsteem ja seda enamjaolt põhjusel kui lihtne teda nii üles seada kui kasutada on. Selle lihtsusega kaasneb ka arendamise kiirus mis mis reeglina tähendab odavamat arendust ja õnnelikumat klienti. Samuti on WordPress suutnud aastate jooksul muutuda vägagi modulaarseks ja paindlikuks sisuhaldussüsteemiks.
Siiski jääb WordPress oma tuumalt mõningate rakenduste jaoks liiga jäigaks. Ka WordPressi turvalisus jätab tema populaarsuse juures nii mõndagi soovida.

 

Kokkuvõte

Tänapäeval on sisuhaldussüsteemid (ja seda eriti Drupal ja WordPress) üksteise pealt niipalju laenanud ja aastatega aina sarnasemaks muutunud, et pooli võtta on raske. Kui aga peaks kuhugi poole kalduma siis saame öelda, et kui oled valmis mõningaid lisa tunde panema süsteemi õppimise alla siis võib Drupal tulla kasulikumaks süsteemiks mida õppida tänu eelpool mainitud eelistele.
Siiski kui me vaatame meie hüpoteetilist klienti oleme sunnitud nentima, et antud juhul on WordPress õigem valik. Seda just tema lihtsuse tõttu. WordPressis on lõppkasutajal mugav muudatusi teha ning ka arendaja saab kiiremini ja odavamtl töö tehtud mis antud kliendile on tõenäoliselt olulisem kui turvalisus ja hilisemates töödev vaja minna väiv modulaarsus.

 

Kasutatud allikad:

5 Reasons to use Drupal vs. WordPress https://thoughts.duoconsulting.com/blog/5-reasons-to-use-drupal-vs.-wordpress

WordPress vs Drupal https://www.bigtunainteractive.com/wordpress-vs-drupal

Drupal.org – About https://www.drupal.org/about

WordPress.org – About https://wordpress.org/about/

 

Viide ülesandele