Mis toimub otsuse ja avaldamise vahel: veebilehe arenduse sammud

Leping on allkirjastatud, ettemaks tehtud, ja siis saabub vaikus. Ettevõte ootab, millal veebileht ilmub, arendaja ootab tekste ja fotosid, ja kumbki ei arva, et ootab täpselt sama nädalat, seega on kuu aja pärast mõlemad pooled rahulolematud ja kumbki pole midagi valesti teinud; lihtsalt keegi ei olnud kirja pannud, kes mida tarnib ja mis kuupäevaks.

See artikkel räägib sellest, mis toimub otsuse ja avaldamise vahel, ja eelkõige tööjaotusest kahe poole vahel, sest just see määrab tähtaja palju sagedamini kui arenduse kiirus või valitud tehnoloogia. Milliseid vigu tellijad teevad, oleme kirjutanud eraldi artiklis kümne vea kohta veebilehe tellimisel, ja siin me neid ei korda. Siin ei ole ka hindu ega võrdlust omal käel tegemise ja tellimise vahel, sest mõlemad on teiste artiklite teemad; jutt on ainult järjekorrast ja sellest, mis millises sammus tuleb ette valmistada.

Eeluuring ei ole ehitamise algus

Peaaegu iga arendusprotsess algab etapiga, mida nimetatakse eeluuringuks (discovery), ja just sellest etapist saadakse kõige sagedamini valesti aru, sest tellija peab seda formaalsuseks enne päris tööd. Nielsen Norman Group, kes seda mõistet professionaalselt kasutab, määratleb selle ettevalmistava etapina, milles uuritakse probleemi ennast ja selle konteksti, sõnastatakse, mis on lahendatav, ja kogutakse piisavalt tõendeid, et teada, mida edasi teha, ning rõhutab otseselt, et eeluuringus lahendusi ei testita.

Avalikus sektoris on see mõte vormistatud veel rangemalt, sest Ühendkuningriigi valitsuse digiteenuste käsiraamat (Government Digital Service Manual) eristab viit etappi — discovery, alpha, beta, live ja retirement — ja eeluuringu kohta on seal kirjas lihtsalt: selles etapis teenust ehitama ei hakata. Etapi lõpus otsustab meeskond, kas minna edasi või peatuda, ja käsiraamat ise kindlat tähtaega ei sea, kuigi märgib, et praktikas kestab see etapp tavaliselt neli kuni kaheksa nädalat.

Siin tuleb kohe teha mööndus, muidu tekib vale pilt: nimetatud käsiraamat kirjeldab riikliku digiteenuse elutsüklit, mitte kümne lehega ettevõtte veebilehte, ja selle tähtaegade ülekandmine tavalisele arendusprojektile oleks eksitav. Väärtuslik on selles põhimõte, mitte kalender: enne ehitamist on etapp, mille eesmärk on ülesanne mõista, ja selle etapi tulemus võib olla ka otsus üldse mitte ehitada.

Praktilises projektis ilmneb see etapp tavaliselt vestlusena protsessidest, kasutajarollidest ja mahust, ja selle tulemus on kirjalik plaan, mitte kujundusvisand, kuigi tellija tahab sageli näha just teist. Tellijale järeldub sellest kaks otsest tagajärge, ja esimene on see, et ilma kirjaliku eeluuringu tulemuseta ei ole hiljem millegagi võrrelda seda, mis valmis ehitati, seega jääb mahuvaidlus mõlemale poolele tõendita. Teine on see, et just selles etapis on meelt muuta odav, seevastu pärast ehitamise algust maksab iga muudatus ka selle, mis juba valmis on ja mis tuleb ümber teha.

Prototüüp on odavaim koht meelt muuta

Plaani ja ehitamise vahel on etapp, mida tellijad peavad mõnikord tarbetuks kuluks, ja just see etapp säästab kõige sagedamini raha. Prototüüp on klikitav veebilehe versioon ilma päris koodita, milles saab läbi käia peamised teekonnad ja näha, kus midagi puudu on, ja selle ainus eesmärk on lubada meelt muuta seni, kuni meelt muuta on veel odav.

Briti valitsuse käsiraamat ütleb selle mõtte säästmata, kirjutades alpha-etapist, et tuleb arvestada sellega, et kogu selles etapis kirjutatud kood ja suur osa testitud ideedest visatakse etapi lõpus minema, ja see ei ole vastuolus hea tööga, vaid on selle mõte: prototüübi äraviskamine on odav, valmis süsteemi äraviskamine ei ole. Ettevõtte veebilehe mastaabis töötab sama põhimõte väiksemas mahus, ja just seetõttu valmistame prototüübi enne esimest produktsioonikoodi rida.

Tellijale järeldub sellest praktiline nõue, mida tasub valjusti öelda: prototüübi kinnitamine ei ole formaalne linnuke, vaid ainus hetk, mil muudatused maksavad ainult aega, seega tasub just siis laua taha kutsuda need inimesed, kes hiljem ütlevad, et keegi neilt midagi ei küsinud. Pärast prototüübi kinnitamist maksab iga selline vestlus juba valmis ehitatut.

Teine, mis selles etapis ära tasub, on sisu mustandis, sest prototüübi täitetekstiga saab kergesti kinnitada ja pärast selgub, et päris tekstid ei mahu või et jaotisele, kuhu oli mõeldud üks lõik, on tegelikult vaja kolme. Kui tekstid ei ole veel valmis, tasub prototüüpi panna vähemalt umbes õige pikkusega mustandid, sest pikkus muudab paigutust rohkem kui ükski värv.

Suurem osa ootamisest toimub kliendi poolel

Projekti tähtaja määrab kõige sagedamini mitte arenduse kiirus, vaid see, kui kiiresti tellija sisu tarnib, ja meie kogemuses on see sagedasim venimise põhjus. Valdkonnas ei ole selle kohta sõltumatut uuringut metoodika ja kuupäevaga, seega ütleme seda oma kogemusena ega teeskle, et selle taga seisavad protsendid.

Siin tasub teha veel üks mööndus, muidu kõlaks see jaotis süü veeretamisena: avalikus sektoris on sisuloome eraldi elukutse ja meeskonnaroll, ja valitsuse käsiraamatus on content designer vajalike oskuste seas, kuid sellest ei järeldu, et tavalises arendusprojektis kirjutab tekstid arendaja. Kes neid kirjutab, on kokkuleppe küsimus, ja ainus vale vastus on see, et seda ei ole enne töö algust selgeks tehtud.

Konkreetselt on tellija poolel tavaliselt viis tarnet, ja igaühele neist tasub panna konkreetne kuupäev juba lepingusse, mitte jätta seda vestluse tasemele. Esimene on tekstid, ja need on kõigist raskeimad, sest neid ei saa kirjutada ühe õhtuga ja neid kirjutab tavaliselt inimene, kellele kirjutamine ei ole põhiosa tööst ja kes peab selle teiste kohustuste vahele pigistama. Teine on fotod ja logod vektorformaadis, kolmas on ligipääsud olemasolevatele süsteemidele, kui neist tuleb midagi üle tuua, neljas on kinnitused kindlates projekti punktides, ja viies, mis ei ole dokument, vaid inimene, on üks kinnitaja, kes tohib ettevõtte nimel öelda jah.

Just see viies puudub kõige sagedamini, ja selle puudumine maksab rohkem kui ükski tehniline keerukus: projekt, milles kinnituse annab komitee, venib mitte sellepärast, et keegi töötab halvasti, vaid sellepärast, et iga kinnitus nõuab koosolekut, koosolekud toimuvad kord kahe nädala tagant ja nende vahel seisab töö lihtsalt. Kui ettevõttes on mitu huvitatud osapoolt, ei ole õige lahendus püüda neid kõrvale jätta, vaid kokku leppida, kes neist on lõplik otsustaja ja millise tähtajaga vastust oodatakse.

Eestis ei ole vastavat sätet, mis nimetaks asutuse juhi ametliku veebilehe sisu omanikuks: avaliku teabe seadus paneb veebilehe nõuded teabevaldajale, mitte nimepidi juhile. Eraettevõtet see niikuinii ei sido, kuid mõte on sama ja selle võib vabatahtlikult üle võtta: sisu vastutus kuulub tellijale ja see tuleb panna konkreetsele inimesele nimega.

Pildid on õiguste küsimus, mitte failide küsimus

Fotod on koht, kus tellijad tegutsevad parimate kavatsustega ja tekitavad ometi riski, sest arvatakse, et fail, mis on arvutis, on ka fail, mida tohib kasutada. Autoriõiguse seaduse järgi on fotograafiateos kaitstud teos, autoriõigus tekib teose loomisega ilma igasuguse registreerimiseta, ja autor on alati füüsiline isik, kes pildi tegi.

Sellest järeldub tõsiasi, mis üllatab peaaegu iga ettevõtet: tasu fotoseansi eest iseenesest ei tähenda, et tellija on saanud autoriõiguse. Fotograaf jääb autoriks, isiklikud mittevaralised õigused, sealhulgas õigus olla nimetatud autoriks, on autori isikust lahutamatud ja ei ole üleantavad, ja varalised õigused lähevad üle ainult litsentsi või loovutuslepinguga, ja ettevõttele, kes kavatseb fotosid kasutada veebilehel, sotsiaalvõrgustikes ja trükis, tähendab see, et litsentsis peavad olema loetletud just need kasutusviisid.

Pildipankadega on täpselt samamoodi, ainult et seal on tingimused kirjutatud selgelt ja avalikult, seega saab need enne ostmist läbi lugeda: Shutterstocki Standard License annab mittevälistava ja edasiandmatu õiguse pilti kasutada, sealhulgas veebilehtedel, ja samal lehel on öeldud, et klient ei saa omandiõigust ega ainuõigust. Seal on ka piirangud, mida rikutakse sageli juhuslikult: pilti ei tohi edasi anda, ei tohi kasutada logona või kaubamärgina, ja pildid, mis on märgitud ainult toimetuslikuks kasutamiseks, ei tohi minna ärilisse kasutusse. Ettevõte, kes on ostnud standardlitsentsi, on saanud õiguse kasutada pilti veebilehel, mitte faili, mida saab arendajale anda kui oma vara.

On veel üks juhtum, millest peaaegu alati saadakse valesti aru. Autoriõiguse seaduse § 20¹ lubab ilma autori loata reprodutseerida ja üldsusele suunata arhitektuuri-, kujutava kunsti, tarbekunsti ja fotograafiateoseid, mis asuvad püsivalt üldsusele avatud kohtades — välja arvatud siis, kui teos on reproduktsiooni põhiobjekt ja seda kavatsetakse kasutada otsesel ärilisel eesmärgil. Ettevõtte veebileht on tavaliselt äriline kasutus, seega foto, mille põhiobjekt on võõras hoone või võõras skulptuur, jääb erandi alt välja ja vajab endiselt luba; juhuslik ilmumine tänavapildis on kaetud.

Lõpuks on inimesed piltidel isikuandmete küsimus, mitte üksnes viisakuse küsimus: isikuandmete kaitse üldmääruse järgi on äratuntava inimese foto isikuandmed ja õiguslik alus võib olla nõusolek või leping; nõusolek peab olema vabatahtlik, konkreetne, teadlik ja ühemõtteline. Olulisim praktiline järeldus on see, et nõusoleku saab igal ajal tagasi võtta ja pärast tagasivõtmist tuleb pildid avalikust keskkonnast eemaldada, seega tuleb meeskonnafotod veebilehel seada nii, et lahkuva töötaja pilt ei muutuks probleemiks.

Arenduskeskkond ja viga, mida tehakse heade kavatsustega

Enne avaldamist käib töö eraldi keskkonnas, ja seda on vaja lihtsal põhjusel: tellija peab nägema päris lehte päris brauseris, mitte pilti disainitööriistast, ja vead tuleb püüda kohas, kus kliendid neid ei näe. Küsimus on ainult selles, kuidas see keskkond sulgeda, ja just siin tehakse viga, mis näib õige.

Levinud lahendus on kirjutada keeld robots.txt-faili, ja see ei tee seda, mida inimesed arvavad, sest Google'i dokumentatsioonis on selle kohta otse kirjas: see fail ütleb otsingurobotitele, millistele aadressidele nad tohivad ligi pääseda, ja see teenib peamiselt seda, et veebilehte ei koormataks päringutega, kuid see ei ole mehhanism, millega lehte Google'ist eemal hoida. Et leht otsingutulemustes ei ilmuks, tuleb kasutada noindex-märget või kaitsta keskkond parooliga.

Järgneb detail, mille tõttu töötavad mõlemad meetodid koos halvemini kui kumbki eraldi. Noindex-märge toimib ainult siis, kui otsingurobot pääseb lehele ligi, sest ta peab selle läbi lugema; kui leht on robots.txt-failis keelatud, ei näe robot seda märget kunagi, ja leht võib tulemustes ikkagi ilmuda, näiteks kui sellele viivad lingid mujalt; pealegi ei toeta Google noindex-märget robots.txt-failis üldse.

On ka teine põhjus, miks see ei ole teoreetiline probleem: kui arenduskeskkond sisaldab sama sisu kui valmis veebileht, võib otsingumootor pidada just seda põhiversiooniks ja näidata seda tulemustes teie veebilehe asemel, mis tähendab, et külastaja jõuab pooleliolevale lehele testandmetega. Seda viga on raske märgata, sest veebileht ise töötab laitmatult ja probleem on näha ainult otsingutulemustes.

Praktiline vastus on seega lihtne ja seda tasub küsida otse: kaitske arenduskeskkond parooliga. See on ainus lahendus, mis otsingurobotite käitumisest sõltumata tagab, et pooleliolev veebileht ei ilmu kuhugi, ja samal ajal kõrvaldab teise riski, millele mõeldakse harvem: et sama sisuga arenduskeskkond võidakse võtta põhiversiooniks ja see hakkab päris veebilehega konkureerima.

Millised valikud pärast avaldamist kõige rohkem maksavad

Enamikku otsuseid veebileheprojektis saab muuta ka pärast avaldamist, ja seda tasub öelda selgelt, sest tellijad muretsevad sageli just nende asjade pärast, mida hiljem on kõige kergem muuta. Värvid, paigutus, mall, tekstid ja isegi lehtede koht menüüs on muudetavad peaaegu igal hetkel, ja see maksab ainult töötunde, mitte ümberehitust, kuid kaks asja on siiski teistsugused, ja just nendele tasub mõelda enne avaldamist, kuni muutus ei maksa veel midagi.

Esimene on aadressistruktuur, ja see muutub otsuseks just sel hetkel, kui lehed on indekseeritud ja neile viivad võõrad lingid, sest sellest hetkest ei ole aadresside muutmine enam visuaalne valik, vaid kolimine, mida Google kirjeldab eraldi protseduurina oma nõuetega. Tuleb kasutada serveripoolseid püsivaid ümbersuunamisi ja hoida need alles vähemalt aasta; Google hoiatab ka, et ühe hooga ei muudetaks nii aadresse, sisuhaldussüsteemi kui ka paigutust, ja tavalisele ettevõtte veebilehele soovitab kolida kõik aadressid korraga, mitte osade kaupa. Samal lehel on kasulik märkus, mis hirmu vähendab: püsivad ümbersuunamised iseenesest PageRanki ei vähenda, kuigi positsioonid võivad mõnda aega kõikuda.

Teine on domeen ise, sest domeeni vahetus on sama kolimine kõigi selle nõuetega, ainult suuremas mastaabis, ja sellele lisandub kõik, mis on juba trükitud visiitkaartidele ja kirjaplankidele. Selle kohta, kelle nimele domeen tuleb registreerida, oleme kirjutanud artiklis kümne vea kohta veebilehe tellimisel, ja siin me seda ei korda; siin tasub öelda ainult, et domeeni valik on üks väheseid otsuseid, mille hilisem muutmine maksab rohkem kui kohe õigesti tegemine.

On üks protseduuri detail, mida tasub teada, et seda ilma vajaduseta ei nõutaks: aadressimuutuse taotlus Search Console'is esitatakse ainult siis, kui muutub domeen või alamdomeen; üleminekuks ebaturvaliselt turvalisele ühendusele või valikuks aadressi vahel www-eesliitega ja ilma samas domeenis see ei ole ette nähtud, ja seal piisab õigetest ümbersuunamistest. Ettevõttele tähendab see, et suurem osa muudatusi lahendatakse serveri poolel, mitte mingis vormis.

Praktiliselt järeldub sellest üks soovitus enne avaldamist: kui vana veebileht juba olemas on ja sellel on külastajaid otsingumootoritest, tuleb aadresside nimekiri ümbersuunamistega uutele aadressidele valmistada enne avaldamist, mitte pärast seda, kui keegi märkab külastuste langust. See nimekiri on ka üks neist töödest, mille tellija saab ise ette valmistada ja mis, kui seda keegi ei valmista, muutub pärast avaldamist nädalaks otsimistööks.

Ligipääsetavus: kellele see on kohustus ja kellele mitte

Avaliku sektori asutustele on ligipääsetavus kohustus juba mitu aastat; eraettevõttele ainult siis, kui ta osutab seaduses loetletud teenust, kõige sagedamini e-kaubandust, ja ei ole mikroettevõtja. Tutvustav veebileht, mis midagi ei müü, loetellu ei kuulu. Turul aetakse need kaks akti sageli segamini, ja see on viga, mis maksab.

Esimene puudutab avalikku sektorit ja on jõus juba mitu aastat, seega ei ole see asutustele uudis. Euroopa Liidu direktiivi avaliku sektori asutuste veebilehtede ligipääsetavuse kohta võtab Eestis üle avaliku teabe seadus, koos veebilehe ja mobiilirakenduse ligipääsetavuse nõuete määrusega, ja need nõuavad, et veebilehed oleksid tajutavad, talitlusvõimelised, mõistetavad ja töökindlad, ning et avaldataks eraldi ligipääsetavuse avaldus. See regulatsioon seob asutusi ega kehti tavalise eraettevõtte kohta, kuigi turul pakutakse seda mõnikord üldise nõudena.

Teine on uuem, ja just see tekitab suurema osa arusaamatusi, sest jõustumise kuupäev on laialt teatavaks tehtud, ulatus aga mitte: Euroopa ligipääsetavuse akti võtab Eestis üle toodete ja teenuste ligipääsetavuse seadus, mida kohaldatakse alates 28. juunist 2025, koos sotsiaalkaitseministri määrusega toote ja teenuse funktsionaalsete ligipääsetavusnõuete kohta. See ei tähenda, et alates nimetatud kuupäevast peaks iga ettevõtte veebileht vastama ligipääsetavusstandardile, ja just seda liiga laia väidet korratakse turul kõige sagedamini, mõnikord koos pakkumisega see korda teha.

Seadus kehtib konkreetsele teenuste loetelule, mitte igale veebilehele, ja sinna kuuluvad elektroonilise side teenused, audiovisuaalmeedia teenustele ligipääsu andvad teenused, lennu-, bussi-, raudtee- ja veeliikluse sõitjateveoteenuse teatavad osad, loetletud tarbijafinantsteenused, e-raamatud ja e-kaubanduse teenused. Ettevõtte tutvustav veebileht, mis midagi ei müü ega ole pank, veoettevõtja või raamatuplatvorm, sellesse loetellu ei kuulu.

On ka erand väikestele ettevõtetele, ja see tuleb sõnastada täpselt, sest seda jutustatakse sageli liiga laialt. Ettevõtja, kellel on alla kümne töötaja ja kelle aastakäive või aastane bilansimaht ei ületa kahte miljonit eurot ja kes osutab seaduse kohaldamisalas olevat teenust, on vabastatud teenuste ligipääsetavusnõuete täitmise kohustusest. Erand kehtib teenustele; toodetega seotud kohustused on mikroettevõtjale kergemad, kuid mitte tühistatud, seega lause, et mikroettevõtjad on seadusest vabastatud, ei ole õige.

Praktiline järeldus tellijale on lühike: kui teete e-poodi ja ei ole mikroettevõtja, tuleb ligipääsetavusnõuded kirjutada juba lähteülesandesse, sest hiljem tähendavad need ümbertegemist. Kui teete tutvustavat veebilehte, ei ole juriidilist kohustust tõenäoliselt, kuid see on endiselt argument selle kasuks, et leht oleks kasutatav klaviatuuriga ja loetav ekraanilugejaga, sest osa teie klientidest kasutab neid seadusest sõltumata.

Kui kaua see kõik aega võtab

Tähtaja küsimus on see, millele tellija tahab vastust esimesena, ja see on ka see, millele ausat vastust on kõige raskem anda. Valdkonnas avaldatud tähtajad tulevad peaaegu alati arendajate enda lehtedelt, kus need teenivad lubadusena kiiruse kohta, seega ei saa neid kasutada sõltumatu andmepunktina, ja sõltumatut uuringut metoodikaga me ei leidnud.

Seetõttu on õigem rääkida sellest, mis tähtaja määrab, mitte otsida keskmist arvu, mis ühelegi konkreetsele projektile niikuinii ei sobi: tähtaja määravad maht, kinnituste kiirus ja sisu valmidus, ja kahes viimases neist kolmest on otsustav mõju tellija poolel. Projekt, milles tekstid on valmis enne algust ja otsuseid teeb üks inimene, kulgeb märksa kiiremini kui sama mahuga projekt ilma nende kahe tingimuseta, ja see on vahe, mida saab mõõta nädalates.

Meie enda avaldatud tähtaeg WordPressi arenduslehel on neli kuni kümme nädalat, ja see kehtib tavalise ettevõtte veebilehe kohta, seevastu keerukamate projektide puhul on see pikem ja e-kaubandusel veel pikem, kuid konkreetse projekti ainus kasulik tähtaeg on see, mis järeldub mahust, mitte keskmisest näitajast.

On veel üks viis seda küsimust vaadata, ja tellijale on see tavaliselt kasulikum kui ükski arv: küsige arendajalt mitte seda, kui kaua see aega võtab, vaid millised nädalad sõltuvad teist ja millised temast. Vastus sellele küsimusele on kontrollitav ja näitab kohe, kui suure osa tähtajast te ise kontrollite.

Ja veel üks asi, mis tähtaega mõjutab rohkem, kui paistab, on mahu kasv töö käigus: iga uus soovitus on eraldi väike ja põhjendatud, kuid koos nihutavad need üleandmise kuupäeva, ja see toimub märkamatult, sest ükski neist ei näe kunagi välja nagu otsus projekti pikendada. Ainus, mis selle vastu aitab, on kokkulepe, et muudatused väljaspool algset mahtu kirjutatakse eraldi üles koos nende mõjuga tähtajale, mitte ei võeta vaikselt sisse.

Mida kokku leppida enne töö algust

Enne esimest arverida tasub läbi rääkida ja kirja panna sisugraafik kuupäevadega: kes kirjutab tekstid, mis kuupäevaks on need arendaja käes ja mis juhtub, kui need hilinevad, sest ilma selle punktita näeb venimine alati välja arendaja süül.

Teine on piltide päritolu ja õigused, nimelt kust fotod tulevad, milline litsents neil on, kas litsentsis on nimetatud kasutus just veebilehel ja kas inimesed piltidel on andnud nõusoleku, mille nad saavad hiljem tagasi võtta. Kolmas on üks kinnitaja ees- ja perekonnanimega ning kokkulepe selle kohta, mitme tööpäeva jooksul oodatakse vastust kinnitustaotlusele, sest ilma tähtajata ei ole kinnitus planeeritav suurus.

Neljas on arenduskeskkond, mis on kaitstud parooliga, mitte keeluga robots.txt-failis, ja viies on ümbersuunamiste nimekiri vanadelt aadressidelt uutele, kui vana veebileht juba olemas on ja sellel on külastajaid. Kuues on küsimus ligipääsetavuse kohta, millele vastus sõltub sellest, mida teie veebileht teeb, ja mida on palju odavam küsida lähteülesande kirjutamise hetkel kui pärast üleandmist.

Seda nimekirja tasub vaadata ühes vestluses, mitte tükkide kaupa, sest just koos näitab see, kui suur osa projektist sõltub tellijast, ja see on tavaliselt suurem, kui tellija ootas. Ükski neist nõuetest ei ole kallis ja ükski neist ei nõua tehnilisi teadmisi; need nõuavad ainult seda, et keegi need enne töö algust küsiks.

Ja seitsmes, mis ei ole tehniline, kuid otsustab rohkem kui ülejäänud kuus: kokkulepe selle kohta, mis on vähim maht, millega veebilehe saab avaldada. Projekt, milles avaldatakse ainult siis, kui kõik on valmis, kipub mitte kunagi avalduma, seevastu projekt selge vähima mahuga avaldub õigel ajal ja kasvab pärast. Kui soovite, et räägiksime selle vestluse teiega koos läbi, kirjutage meile.