{"id":506,"date":"2020-03-11T21:52:47","date_gmt":"2020-03-11T21:52:47","guid":{"rendered":"https:\/\/ramk.ee\/opikud\/veebidisain\/?post_type=chapter&p=506"},"modified":"2020-03-12T20:01:05","modified_gmt":"2020-03-12T20:01:05","slug":"veebilehe-elutsukkel","status":"publish","type":"chapter","link":"https:\/\/ramk.ee\/opikud\/veebidisain\/chapter\/veebilehe-elutsukkel\/","title":{"rendered":"Veebilehe eluts\u00fckkel"},"content":{"raw":"

Veebi kujunduse eluts\u00fckkel<\/h1>\r\nVeebileht, veebirakendus on p\u00f5him\u00f5tteliselt samasugune toode nagu mistahes tarkvara. Kuigi lihtsama veebilehe loomise ja hooldamisega saab hakkama pea iga inimene, kellel on tehnilist taipu ja silma kujunduseks, eeldab korraliku veebirakenduse loomine lisaks kujundamisele ja arendusele (sisu loomine, koodi kirjutamine jms) siiski ka korralikku planeerimist, anal\u00fc\u00fcsi, testimist ning hilisemat \u00fclalpidamist. Veebirakendusel on nagu igal teisel tootel oma eluts\u00fckkel, milles osalevad erinevate rollidega inimesed. Veebirakenduste loomine on reeglina meeskonnat\u00f6\u00f6 kuna eeldab v\u00e4ga paljude erinevate teadmiste ja oskuste rakendamist (kujundamine, programmeerimine, pildit\u00f6\u00f6tlus, heli- ja videot\u00f6\u00f6tlus, animeerimine jne).\r\n

Rollid veebiarendusmeeskonnas<\/h2>\r\nVeebiarendusmeeskonnad v\u00f5ivad olla erineva suurusega alates \u00fcksikisikust l\u00f5petades suurte mitmek\u00fcmne v\u00f5i isegi mitmesaja liikmelistega. Igal meeskonnaliikmetel on t\u00e4ita kindel roll. Rollide nimed v\u00f5ivad erinevates meeskondades olla erinevalt nimetatud, sama rolli v\u00f5ib t\u00e4ita mitu inimest ja \u00fchel inimesel v\u00f5ib olla t\u00e4ita mitu rolli kuid v\u00e4ga \u00fcldiselt jagunevad meeskonnaliikmed juhtideks (manager<\/em>), disaineriteks (designer<\/em>), arendajateks (developer<\/em>) ja dokumenteerijateks (documenter<\/em>).\r\n\r\nProjektijuht<\/strong> (project manager<\/em>) koordineerib projekti l\u00e4biviimist, jagab meeskonnaliikmetele \u00fclesandeid, hoolitseb vajalike ressursside k\u00e4ttesaadavuse eest, organiseerib kohtumisi ja koost\u00f6\u00f6d k\u00f5igi osapoolte vahel (klient, disainer, arendaja jne). Sageli on juht abiks kui m\u00f5ni projekti osa on ajakavast maha j\u00e4\u00e4nud.\r\n\r\nVeebidisainer<\/strong> (web designer<\/em>) loob toote visuaalse poole, kogub ja loob kasutatava graafika jne. Suuremates meeskondades on disaineri \u00fclesanded kitsamalt jagatud:\r\n
    \r\n \t
  • Graafikadisainer (web graphics designer<\/em>) loob ja t\u00f6\u00f6tleb graafikafaile (illustratsioonid, b\u00e4nnerid jms), optimeerib neid veebi jaoks.<\/li>\r\n \t
  • Multimeediumidisainer (web multimedia designer<\/em>) tegeleb heli ja videoklippide loomise ja t\u00f6\u00f6tlemisega, sageli ka graafikaga. V\u00e4iksemas meeskonnas v\u00f5ib see roll olla \u00fchendatud graafikadisaineri rolliga, suuremas aga v\u00f5ib heli ja video jaoks olla eraldi inimene.<\/li>\r\n \t
  • Kasutajaliidese disainer (user interface designer<\/em>) hoolitseb, et veebileht oleks mugavalt kasutatav (navigatsioon jms).<\/li>\r\n \t
  • Kasutajakogemuse disainer (User eXperience designer<\/em>) on uus roll, tegeleb parima kasutajakogemuse loomisega.<\/li>\r\n<\/ul>\r\nVeebiprogrammeerija<\/strong> (web programmer<\/em>) ehk arendaja (developer<\/em>) loob loogika (koodi), mis t\u00f6\u00f6tab kujunduse taga ning hoolitseb, et rakendus teeks seda, mida n\u00f5utud.\r\n\r\nDokumenteerija <\/strong>(documenter<\/em>) koostab k\u00f5ik projektiga seotud dokumendid, protokollib koosolekuid, hoolitseb, et kogu dokumentatsioon oleks k\u00f5igile meeskonnaliikmetele k\u00e4ttesaadav.\r\n\r\nTestija<\/strong> (tester<\/em>) testib loodud rakendust, selle osi, otsib v\u00f5imalikke vigu ja probleeme ning annab nende kohta infot disaineritele ja arendajatele.\r\n\r\nTellija<\/strong> ehk klient (client<\/em>) ei osale k\u00fcll igap\u00e4evaselt meeskonna t\u00f6\u00f6s kuid ideaalis on ta tihedas kontaktis projektijuhi ning disaineritega, et loodav veebileht vastaks tema soovidele ja ootustele.\r\n\r\nLisaks v\u00f5ib meeskonda kuuluda veel hulk erinevaid spetsialiste, kes hoolitsevad n\u00e4iteks tekstide (sisu) kirjutamise eest, andmebaaside loomise eest, meeskonda v\u00f5ib kuuluda fotograaf jne.\r\n\r\nSuuremate, vastutusrikkamate projektide puhul kuulub meeskonda ka valdkonnaspetsialist, kes peab j\u00e4lgima, et veebileht vastaks k\u00e4sitletava valdkonna vajadustele, n\u00f5uetele. V\u00e4iksemate projektide puhul on valdkonnaspetsialisti rollis sageli tellija ise.\r\n

    Eluts\u00fckkel<\/h2>\r\nIgasuguse toote eluts\u00fckli moodustavad k\u00f5ik temaga seotud tegevused kavandamisest valmimise, hilisema hoolduse ja t\u00e4iendamise ja l\u00f5puks kasutusest k\u00f5rvaldamiseni. \u00dcldiselt vaadeldakse tarkvara puhul tema loomist ja t\u00e4iendamist ning kuna t\u00e4iendamine kordab v\u00e4iksemas mahus m\u00f5ningaid loomise etappe, siis tavaliselt r\u00e4\u00e4gitakse tarkvara ehk siis meie puhul veebilehe loomise eluts\u00fcklist.\r\n\r\nVeebilehe loomise etappe (nagu mistahes tarkvara puhul) loetletakse erinevates allikates erinevate nimedega kuid sisult on tegemist alati j\u00e4rgmistega:\r\n
      \r\n \t
    • n\u00f5uete v\u00e4ljaselgitamine (requirements<\/em>);<\/li>\r\n \t
    • kavandamine (design<\/em>);<\/li>\r\n \t
    • teostamine (implementation<\/em>);<\/li>\r\n \t
    • valideerimine (validation<\/em>);<\/li>\r\n \t
    • tugiteenus (support<\/em>).<\/li>\r\n<\/ul>\r\n\u00dckski meeskond ei saa korralikku veebilehte luua ilma k\u00f5iki neid etappe l\u00e4bimata. H\u00f5lbustamaks t\u00f6\u00f6 planeerimist, on v\u00e4lja t\u00f6\u00f6tatud mitmeid erinevaid mudeleid, kuidas toote loomise eluts\u00fcklit l\u00e4bida (koskmudel (waterfall), spiraalmudel (spiral<\/em>), t\u00e4htmudel (star<\/em>) jpt). Praegusel ajal kasutatakse v\u00e4ga palju nn ADDIE mudelit v\u00f5i selle erinevaid variatsioone. Tegemist on lihtsa, loogilise mudeliga, mille j\u00e4rgimine aitab t\u00f6\u00f6d planeerida ja juhtida. ADDIE mudeli igas faasis saadav tulemus on l\u00e4htematerjaliks j\u00e4rgmisele faasile.\r\n
        \r\n \t
      • Anal\u00fc\u00fcsi (analysis<\/em>) faasis selgitatakse \"probleem\", p\u00fcstitatakse eesm\u00e4rgid, selgitatakse tingimused (n\u00f5uded).<\/li>\r\n \t
      • Disaini (design<\/em>) faasis valitakse strateegia, vahendid, meedia jms.<\/li>\r\n \t
      • Arendusfaasis (development<\/em>) luuakse toode vastavalt disainifaasis tehtud otsustele.<\/li>\r\n \t
      • Rakendusfaasis (implementation<\/em>) testitakse toote protot\u00fc\u00fcpe, valmistatakse l\u00f5plik toode ja v\u00f5etakse see kasutusele (luuakse juhendmaterjalid, koolitatakse kasutajad jne).<\/li>\r\n \t
      • Hindamisfaasis (evaluation<\/em>) testitakse ja hinnatakse toodet (kasutajate tagasiside).<\/li>\r\n<\/ul>\r\n[caption id=\"attachment_507\" align=\"aligncenter\" width=\"750\"]\"ADDIE ADDIE arendusmudel[\/caption]\r\n\r\nHindamist viiakse tegelikult l\u00e4bi praktiliselt k\u00f5ikides etappides, igas etapis toimub t\u00f6\u00f6 iteratiivselt, et saada parim tulemus.\r\n\r\nIteratiivse mudeli kohaselt koosneb igasugune arendusprotsess mitmest j\u00e4rjestikusest ts\u00fcklist (iteratsioonist), mis k\u00f5ik sisaldavad anal\u00fc\u00fcsi, disaini, programmeerimist ja testimist.\r\n\r\nJ\u00e4rgnevalt vaatleme veebilehe loomise eluts\u00fckli etappe just sellest mudelist l\u00e4htudes.\r\n

        Anal\u00fc\u00fcs<\/h1>\r\nVeebilehe loomine algab kokkuleppest tellijaga. Tavaliselt avaldab tellija soovi saada mingisugust veebilehte v\u00f5i veebirakendust, esitab teatud tingimused, l\u00e4hte\u00fclesande ja selle p\u00f5hjal p\u00fc\u00fctakse teha hinnapakkumist. Reeglina on vaja tellijale esitada t\u00e4psustavaid k\u00fcsimusi, et paremini hinnata ees ootavat t\u00f6\u00f6de mahtu ja iseloomu.\r\n\r\nKokkuleppe saavutamise j\u00e4rel algab t\u00e4psem anal\u00fc\u00fcs, mida klient soovib, mida see tegema peab, millised on n\u00f5udmised v\u00e4ljan\u00e4gemisele jne. Kliendi soovide v\u00e4ljaselgitamine ning tema ideede rakendamine kujunduses suurendab rahulolu tulemusega ja v\u00e4hendab hilisemaid kulutusi kasutajatoele ning veebirakenduse hooldamisele.\r\n\r\nToimub n\u00f5uete kogumine (requirements gathering<\/em>). Selgitatakse v\u00e4lja:\r\n
          \r\n \t
        • funktsionaalsed n\u00f5uded (functional requirements<\/em>) \u2013 mida loodav veebileht v\u00f5i veebirakendus peab tegema;<\/li>\r\n \t
        • andmete n\u00f5uded (data requirements<\/em>) \u2013 milliseid andmeid loodav s\u00fcsteem vajab, kasutab,;<\/li>\r\n \t
        • kasutusk\u00f5lbulikkuse n\u00f5uded (usability requirements<\/em>) \u2013 puudutavad tulevasi kasutajaid, nende eeldatavaid kogemusi ja oskusi, millele s\u00fcsteem peab vastama.<\/li>\r\n<\/ul>\r\nN\u00f5uete kogumiseks kasutatakse k\u00f5ige enam intervjuud kliendiga, vesteldakse, k\u00fcsitletakse. Kasulik on kliendiga vestlusesse kaasata mitu meeskonnaliiget (aitab tagada, et kliendi soovidest saadakse \u00f5igesti aru), kindlasti peab kohal olema disainer.\r\n\r\nEelt\u00f6\u00f6na enne intervjuud, saab tutvuda valdkonnaga, mida loodav veebileht k\u00e4sitleb, tutvuda teiste sama valdkonna veebilehtedega, tellija vana veebilehega (kui see on olemas).\r\n\r\nAlustatakse veebilehe eesm\u00e4rkide selgitamisega. Otsitakse vastuseid k\u00fcsimustele:\r\n
            \r\n \t
          • Millist informatsiooni peab loodav veebileht edastama?<\/li>\r\n \t
          • Millised komponendid on olemas k\u00f5igil edukatel veebilehtedel?<\/li>\r\n \t
          • Milliseid aspekte peab loodava veebilehe kujundamisel veel arvestama?<\/li>\r\n<\/ul>\r\nV\u00e4ga t\u00e4pselt tuleb v\u00e4lja selgitada veebilehe sihtgrupp, kes hakkavad seda k\u00fclastama\/kasutama. P\u00fc\u00fcdke leida vastuseid k\u00fcsimustele:\r\n
              \r\n \t
            • Kes hakkavad loodavat veebilehte k\u00fclastama? Millised on nende vajadused? See info aitab otsustada, millist informatsiooni on vaja veebilehele lisada.<\/li>\r\n \t
            • Miks inimesed seda veebilehte k\u00fclastama peaksid? Millistes sotsiaalsetes oludes v\u00f5imalikud k\u00fclastajad elavad, t\u00f6\u00f6tavad?<\/li>\r\n \t
            • Millist dialoogi, milliseid s\u00f5numeid soovivad k\u00fclastajad veebilehelt saada?<\/li>\r\n \t
            • Millist tehnoloogiat kasutada k\u00fclastajatega suhtlemiseks?<\/li>\r\n<\/ul>\r\nKoost\u00f6\u00f6s kliendiga on vaja otsustada, milliseid komponente veebilehel kasutada, millised nende seas on kriitilise t\u00e4htsusega, millised lihtsalt kasulikud ja milliseid v\u00f5iks lisada, kui nende jaoks ressursse j\u00e4tkub. On hulk kliente, kes v\u00e4ga t\u00e4pselt teavad ja n\u00f5uavad, mida leht peab sisaldama ja mida mitte, on ka selliseid, kelle ainus konkreetne soov on saada endale veebileht. Kliendile saab pakkuda erinevaid v\u00f5imalusi, komponente kuid mitte neid peale\r\nsuruda.\r\n\r\nKindlasti tuleb uurida ka kliendi soove loodava veebilehe v\u00e4limuse osas. Milline on kliendi logo (kui see on olemas), kas on olemas nn firmav\u00e4rvid ning kas neid on tarvis kasutada, milliseid kirjastiile eelistatakse jne.\r\n\r\nT\u00e4helepanu tuleb p\u00f6\u00f6rata ka sellele, millised vajadused ja v\u00f5imalused on kliendi veebilehe majutamiseks (hosting<\/em>). T\u00e4psemad tingimused (kui palju kettaruumi vajatakse, milliseid tehnoloogiaid peab veebiserver toetama) saab m\u00e4\u00e4rata alles p\u00e4rast disainiprotsessi kuid juba anal\u00fc\u00fcsi ajal on tarvis sellele m\u00f5elda. V\u00f5imalik, et klient soovib veebilehte majutada kindla teenusepakkuja juures v\u00f5i oma serveris, mis v\u00f5ib seada tehnilisi piiranguid, mida peab juba algusest peale arvesse v\u00f5tma.\r\n\r\nV\u00e4lja tuleb p\u00fc\u00fcda selgitada:\r\n
                \r\n \t
              • kui palju on tarvis kettaruumi (arvestada tuleb ka laiendamisvaru);<\/li>\r\n \t
              • mis tehnoloogiaid tuleb kliendi soovitud veebilehe loomisel kasutada;<\/li>\r\n \t
              • mis t\u00fc\u00fcpi faile soovitakse veebilehel kasutada (m\u00f5ned veebimajutuse pakkujad seavad teatud failivormingutele piiranguid);<\/li>\r\n \t
              • kui suur on planeeritav k\u00fclastatavus, millise andmeliiklusega peaks arvestama.<\/li>\r\n<\/ul>\r\nAnal\u00fc\u00fcsi tulemusena koostatakse loodava veebilehe spetsifikatsioon, kuhu pannakse kirja k\u00f5ik n\u00f5uded, tingimused, mis on v\u00e4lja selgitatud ning loodava veebilehe kirjeldus. N\u00f5uete kirjapanekuks on loodud ka erilisi abstraktseid keeli kuid kasutada v\u00f5ib ka naturaalset keelt, v\u00e4ltida tuleks vaid sl\u00e4ngi.\r\n\r\nKui spetsifikatsioon on kliendiga koosk\u00f5lastatud, algab disainietapp.\r\n

                Disain<\/h1>\r\nK\u00f5igepealt tuleb l\u00e4bi m\u00f5elda veebilehe struktuur, kuidas sisu organiseerida. K\u00f5ik kliendiga kokku lepitud komponendid ja veebilehe sisu jagatakse kategooriateks, hierarhiasse. Arendusmeeskond valib spetsifikatsioonist l\u00e4htudes eesm\u00e4rkide saavutamiseks k\u00f5ige paremini sobivad ning n\u00f5uetele vastavad tehnoloogiad.\r\n\r\nJ\u00e4rgmine samm on juba veebilehe v\u00e4limuse planeerimine. Disainer alustab lihtsatest eskiisidest ning j\u00f5uab l\u00f5puks t\u00e4psete protot\u00fc\u00fcpideni, milledel on paigas visuaalne k\u00fclg: navigatsioonivahendid, komponentide paigutus.\r\n\r\nLuuakse protot\u00fc\u00fcbid, mis tulevast veebilehte kirjeldavad. Keerukamate tegevuste sooritamise kohta luuakse nn kasutajalood \u2013 pannakse detailselt ja sammhaaval kirja, kuidas kasutaja tegevusi sooritab.\r\n\r\nDisaini ja arendusmeeskond loob koost\u00f6\u00f6s mitmeid erinevaid ideekavandeid ja kujundusversioonide eskiise, millede seast koost\u00f6\u00f6s kliendiga valitakse v\u00e4lja k\u00f5ige paremini kliendi vajadustele vastav variant.\r\n

                Protot\u00fc\u00fcpimine<\/h2>\r\nLooge veebilehestiku disaini illustreeriv mudel (sisukaart jms), see v\u00f5imaldab kliendil juba kujundusprotsessi varajases staadiumis tagasisidet anda kui muudatusi on veel v\u00e4ga lihtne teha. Hiljem lisage juba ka kasutajaliidese protot\u00fc\u00fcp (eskiis, joonistus), mis v\u00f5imaldab kliendil aimu saada, milline veebileht tegelikkuses v\u00e4lja n\u00e4gema hakkab.\r\n\r\nT\u00fc\u00fcpiliselt tuleb l\u00e4bida mitu t\u00f6\u00f6ringi: kujundada, hinnata tulemust kliendiga suheldes, \u00fcmber t\u00f6\u00f6tada jne.\r\n\r\nTavaliselt kasutatakse disaini illustreerimiseks j\u00e4rgmist t\u00fc\u00fcpi mudeleid:\r\n
                  \r\n \t
                • sisukaart (site map<\/em>) \u2013 reeglina tekstip\u00f5hine \u00fclesehituse kirjeldus;<\/li>\r\n \t
                • s\u00fc\u017eeetahvel (storyboard<\/em>) \u2013 veebilehestiku graafiline skeem, v\u00f5ib olla paberile joonistatud, loodud mistahes graafikaprogrammiga, genereeritud m\u00f5ne veebiredaktori (HTML editor<\/em>) poolt;<\/li>\r\n \t
                • s\u00f5restikmudel (wireframe<\/em>) \u2013 kest, mis n\u00e4itab loodavaid veebilehti. Iga leht on joonistatud informatsiooniplokkidena, mis n\u00e4itavad kus ja kuidas paiknevad erinevad komponendid. Selliselt esitatakse objektide visuaalne paigutus (layout<\/em>) kuid mitte l\u00f5plik v\u00e4limus.<\/li>\r\n<\/ul>\r\n

                  Sisukaart<\/h3>\r\nSisukaart (site map<\/em>) on \u00fcks kriitilise t\u00e4htsusega ja laialt kasutatav vahend veebidisainis. Kuna sisukaart n\u00e4itab veebilehestiku \u00fcldist struktuuri ja hierarhiat, siis kasutataksegi neid veebilehestiku \u00fcldise \u00fclesehituse ja navigatsiooni kavandamisel.\r\n\r\nAlustada tuleks lihtsast, j\u00e4medakoelisest eskiisist, lisades sinna lihtsalt esmaselt planeeritud, olulised lehed. V\u00e4ltida tuleks detailse info lisamist sisukaardile. Sisukaart muutub ja t\u00e4ieneb projekti edenedes.\r\n\r\nSisukaardid on enamasti tekstip\u00f5hised kuid vahetevahel ka graafilised. Iga lehe kohta pannakse kirja pealkiri ning talle viitav link (URL). T\u00f6\u00f6 k\u00e4igus v\u00f5ivad disainerid sinna lisainfot kirja panna (n\u00e4iteks lehe olulisus terviklikus veebilehestikus, viimase muutmise aeg, kui sageli seda lehte muudetakse jne).\r\n\r\nV\u00e4gagi sageli lisatakse HTML sisukaart valmis veebilehestikule. See on eriti kasulik, kui veebilehestik sisaldab paljusid lehti, lihtsustab navigatsiooni ning v\u00f5imaldab ka otsingumootoritel veebilehestikku l\u00e4bi uurida.\r\n\r\n[caption id=\"attachment_508\" align=\"aligncenter\" width=\"300\"]\"N\u00e4ide N\u00e4ide veebilehe sisukaardist[\/caption]\r\n

                  S\u00fc\u017eeetahvel<\/h3>\r\nS\u00fc\u017eeetahvlit (storyboard<\/em>) kasutatakse lisaks sisukaardile aitamaks teha otsuseid disaini, tehnoloogia aga ka eelarve osas. Hea s\u00fc\u017eeetahvel pakub k\u00f5igile projektiga seotud inimestele selget \u00fclevaadet loodavast veebilehestikust.\r\n\r\nS\u00fc\u017eeetahvlil ei ole n\u00e4ha k\u00f5iki \u00fcksikuid veebilehestiku lehti kuid see katab peamised lehestiku funktsionaalsed osad. Reeglina pannakse iga lehe kohta kirja pealkiri ja m\u00f5ned m\u00e4rkmed tema sisu kohta.\r\n\r\nKa s\u00fc\u017eeetahvel ei sisalda mingit infot lehtede visuaalse disaini kohta kuid v\u00f5imaldab saada ettekujutuse, millised p\u00f5hielemendid igal lehel olemas on.\r\n\r\nS\u00fc\u017eeetahvli v\u00f5ib sarnaselt sisukaardile luua pliiatsiga paberile joonistades v\u00f5i m\u00f5nda graafikaprogrammi kasutades.\r\n\r\n[caption id=\"attachment_509\" align=\"aligncenter\" width=\"500\"]\"N\u00e4ide N\u00e4ide s\u00fc\u017eeetahvlist[\/caption]\r\n

                  S\u00f5restikmudel<\/h3>\r\nS\u00f5restikmudel (wireframe<\/em>) veebidisainis on veebilehele paigutatavate elementide skemaatiline esitus. V\u00f5tmes\u00f5naks s\u00f5restikmudeli puhul on kiirus, neid kasutatakse uute ideedega eksperimenteerimiseks, testimiseks ja sobitamiseks aga mitte kujunduse detailseks kuvamiseks.\r\n\r\nKliendiga suhtlemisel lasevad s\u00f5restikmudelid kliendil keskenduda lehe \u00fclesehitusele (layout<\/em>) laskmata end disainielementidel (pildid, kirjastiilid jt) oluliselt k\u00f5rvale kallutada.\r\n\r\nS\u00f5restikmudeli loomisel kasutatakse lihtsaid graafilisi kujundeid (mitte reaalseid pilte), lisatakse neile pealkiri. S\u00f5restikmudelil peavad n\u00e4htaval olema k\u00f5ik t\u00e4htsad veebilehe elemendid.\r\n\r\n[caption id=\"attachment_510\" align=\"aligncenter\" width=\"500\"]\"N\u00e4ide N\u00e4ide veebilehe s\u00f5restikmudelist[\/caption]\r\n

                  Stsenaarium<\/h3>\r\nStsenaarium (scenario<\/em>) on verbaalne protot\u00fc\u00fcp, mis kirjeldab loodava veebilehe \u00fclesehitust. Siia alla kuuluvad ka kasutajalood (user story<\/em>) \u2013 tegevuste, valikute ja tulemuste verbaalsed kirjeldused.\r\n

                  Visuaalne disain<\/h2>\r\nP\u00e4rast veebilehestiku struktuuri ja \u00fcksikute lehtede \u00fclesehituse (komponentide paigutus) fikseerimist saab asuda visuaalse disaini juurde. Valitakse kirjastiil pealkirjadele ja tekstile, kasutatava graafika stiil ja v\u00e4rviskeem. L\u00e4htepunktiks on veebilehe s\u00f5restikmudel (wireframe<\/em>).\r\n\r\nProtot\u00fc\u00fcpidena kasutatakse siinkohal joonistusi (lihtsatest visanditest detailsete v\u00e4rvipiltideni) ja ekraanipilte. Visandid on sageli k\u00e4sitsi tehtud, v\u00e4rvipiltide loomisel kasutatakse kujundusprogramme.\r\n\r\nKa visuaalsest disainist luuakse mitmeid erinevaid versioone, millede seast koos kliendiga sobivaim v\u00e4lja valitakse.\r\n

                  Detailne protot\u00fc\u00fcp<\/h2>\r\nP\u00e4rast seda, kui k\u00f5ik osapooled on disainiprotsessis osalenud, valmib veebilehestiku detailne protot\u00fc\u00fcp, s\u00fc\u017eeetahvlile (storyboard<\/em>) ja s\u00f5restikmudelile on lisandunud hulk detaile, valminud on visuaalne kujundus.\r\n\r\nKokku on pandud kogu materjal, millest l\u00e4htudes saavad arendajad soovitud veebilehe luua. Protot\u00fc\u00fcpi hinnatakse koos kliendiga ja selle heakskiitmisel algab arendusprotsess.\r\n

                  Arendus<\/h1>\r\nArendusfaasis toimub koostatud spetsifikatsioonile vastava veebilehe loomine: programmeerimine, andmebaaside loomine, rakenduse sidumine visuaalse kujundusega, animatsioonide, graafika, heli- ja videoklippide loomine jms. \u00dcks olulisemaid asju on kogu arendusprotsessi jooksul keskenduda kliendi ja kasutaja vajadustel!\r\n\r\nDisain pole kunagi ideaalne, veatu. Arendusprotsess peab olema iteratiivne \u2013 korduv loomine, \u00fclevaatamine ja muutmine kuni tulemus vastab kliendi ja kasutaja soovidele. \u00dcldiselt on soovitatav ka arendusfaasis kliendiga v\u00f5imalikult tihedat koost\u00f6\u00f6d teha. Klienti ei huvita iga koodirida v\u00f5i loodud pilt kuid mingit funktsionaalsust pakkuvate komponentide valmimisel on m\u00f5istlik neid kohe kliendile n\u00e4idata.\r\n\r\nIteratiivse arendusega v\u00f5ib ka juba olemasolevaid veebilehti edasi arendada tehes regulaarselt v\u00e4ikseid muudatusi. Muudatusi tuleb teha ts\u00fcklitena j\u00e4ttes alati alles osad, mis \"t\u00f6\u00f6tavad\" ning asendades sobimatuid.\r\n

                  Rakendamine<\/h1>\r\n\u00dcleminek arendusfaasist rakendamisfaasi pole v\u00e4ga selgelt m\u00e4\u00e4ratletav. Rakendusfaasis toimub testimine ja vigade leidmisel nende parandamine (mis on sisuliselt arendamine). P\u00e4rast arendusprotsessi algab testimine ja t\u00e4iustamine (refinement<\/em>), mis on samuti iteratiivne protsess. Selle k\u00e4igus otsitakse ja parandatakse tehnilisi vigu, kasutusk\u00f5lbulikkuse (usability<\/em>) vigu, vaadeldakse lehe avanemiseks kuluvat aega ja vajadusel optimeeritakse rakendust.\r\n\r\nTestimisprotsess h\u00f5lmab mitmeid erinevaid hindamisi, n\u00e4iteks:\r\n
                    \r\n \t
                  • Heuristiline l\u00e4bivaatus (heuristic evaluation<\/em>) \u2013 eksperdid vaatavad \u00fcle loodava veebilehe kasutajaliidese (user interface<\/em>) ning hindavad seda kasutusk\u00f5lbulikkuse (usability<\/em>) seisukohalt l\u00e4htudes \u00fcldtunnustatud kasutusk\u00f5lbulikkuse printsiipidest. Erinevad inimesed m\u00e4rkavad erinevaid vigu, seet\u00f5ttu on \u00fchel inimesel \u00fcksinda heuristilist l\u00e4bivaatust teha, tavaliselt soovitatakse kasutada kolme kuni viit eksperti. Leitud vead tuleb loomulikult k\u00f5rvaldada.<\/li>\r\n \t
                  • Korrektuur (proofread<\/em>) \u2013 testitakse k\u00f5iki rakenduse interaktiivseid elemente (ekraanivormid, dialoogiboksid jms). Vajadusel \u00f5petatakse klienti k\u00f5iki rakenduse osi kasutama. Vaadatakse \u00fcle \u00f5igekiri ja grammatika. Kontrollitakse kas k\u00f5ik lingid avanevad ja viitavad \u00f5igetele lehtedele.<\/li>\r\n \t
                  • Mitteformaalne testimine, valjusti m\u00f5tlemine (think aloud<\/em>) \u2013 veebirakendust kasutavad kaks inimest koos, \u00fcks tegutseb ja arutleb valjusti oma tegevuste \u00fcle (avaldab m\u00f5tteid, tekkivaid k\u00fcsimusi jne), teine teeb m\u00e4rkmeid. Sellisel moel tulevad probleemid kiiresti ilmsiks sest protsess h\u00f5lmab reaalset t\u00f6\u00f6d rakendusega. Testkasutajaks peab olema inimene, kes pole seda rakendust enne n\u00e4inud ega tea selle eesm\u00e4rki, otstarvet. Testkasutajale tuleks aega anda 30 minutit, kui ta vajab rohkem aega, siis vajab rakendus \u00fcmbertegemist!<\/li>\r\n<\/ul>\r\nTestimisprotsessi j\u00e4rel tuleks veebirakendus publitseerida testserverile, mis pole k\u00f5igile avalikult k\u00e4ttesaadav, et ka klient saaks tulemust testida.\r\n\r\nRakendusfaasi k\u00e4igus koostatakse ka rakenduse dokumentatsioon (juhendmaterjalid jms), vajadusel koolitatakse kasutajaid (kliendi esindajad, tulevased veebilehe administraatorid jne).\r\n\r\nVajadusel tuleb teha veel t\u00e4iendavaid muudatusi ning alles seej\u00e4rel kui ka klient on tulemuse heaks kiitnud publitseeritakse veebirakendus avalikuks kasutamiseks avalikku serverisse.\r\n\r\nVeebileht on valmis. Siinkohal sageli eluts\u00fckkel katkestatakse!\r\n

                    Hindamine<\/h1>\r\nHindamisfaas on see, mis toimub p\u00e4rast veebilehe valmimist ja publitseerimist. Selle k\u00e4igus toimub formaalne kasutusk\u00f5lbulikkuse hindamine (formal usability studies<\/em>) \u2013 protsess, mille k\u00e4igus anal\u00fc\u00fcsitakse reaalseid kasutusandmeid inimese ja s\u00fcsteemi koost\u00f6\u00f6 kohta. K\u00f5ige tavap\u00e4rasemateks andmeallikateks on veebiserveri logid, veebikasutuse anal\u00fcsaatorid (n\u00e4iteks Google Analytics). Sellist hindamist saabki l\u00e4bi viia alles p\u00e4rast veebilehe publitseerimist (aga n\u00e4iteks ka testkasutamise ajal testserveril) ning v\u00f5ib olla v\u00e4gagi kallis. Hea on see, et\r\npole vaja otsida testkasutajaid v\u00f5i eksperte, kasutada on andmed reaalsete igap\u00e4evaste kasutajate k\u00e4itumise kohta veebilehel.\r\n\r\nHindamisfaasis tuntakse huvi kasutajate tagasiside vastu, uuritakse, kuidas ollakse veebilehega rahul.\r\n\r\nHindamisfaas j\u00e4\u00e4b sageli v\u00e4ga l\u00fchikeseks v\u00f5i seda ei toimugi. Tavaliselt ilmneb hulk v\u00f5imalikke probleeme alles pikema aja jooksul reaalse kasutamise k\u00e4igus ning ka siis oleks tarvis parandusi teha, seda aga tihtipeale arendaja ja kliendi vahel kokku ei lepita.\r\n\r\nM\u00f5istlik oleks juba esimeste kokkulepete s\u00f5lmimisel kliendiga juhtida t\u00e4helepanu ka v\u00f5imalikule vajadusele hiljem t\u00e4iendusi ja parandusi teha ning selle tegevuse tingimustes kokku leppida. Samas on selline hilisem arendust\u00f6\u00f6 arendajale t\u00fclikas sest projektiga seotud meeskond on juba h\u00f5ivatud teiste projektidega v\u00f5i lausa laiali l\u00e4inud.","rendered":"

                    Veebi kujunduse eluts\u00fckkel<\/h1>\n

                    Veebileht, veebirakendus on p\u00f5him\u00f5tteliselt samasugune toode nagu mistahes tarkvara. Kuigi lihtsama veebilehe loomise ja hooldamisega saab hakkama pea iga inimene, kellel on tehnilist taipu ja silma kujunduseks, eeldab korraliku veebirakenduse loomine lisaks kujundamisele ja arendusele (sisu loomine, koodi kirjutamine jms) siiski ka korralikku planeerimist, anal\u00fc\u00fcsi, testimist ning hilisemat \u00fclalpidamist. Veebirakendusel on nagu igal teisel tootel oma eluts\u00fckkel, milles osalevad erinevate rollidega inimesed. Veebirakenduste loomine on reeglina meeskonnat\u00f6\u00f6 kuna eeldab v\u00e4ga paljude erinevate teadmiste ja oskuste rakendamist (kujundamine, programmeerimine, pildit\u00f6\u00f6tlus, heli- ja videot\u00f6\u00f6tlus, animeerimine jne).<\/p>\n

                    Rollid veebiarendusmeeskonnas<\/h2>\n

                    Veebiarendusmeeskonnad v\u00f5ivad olla erineva suurusega alates \u00fcksikisikust l\u00f5petades suurte mitmek\u00fcmne v\u00f5i isegi mitmesaja liikmelistega. Igal meeskonnaliikmetel on t\u00e4ita kindel roll. Rollide nimed v\u00f5ivad erinevates meeskondades olla erinevalt nimetatud, sama rolli v\u00f5ib t\u00e4ita mitu inimest ja \u00fchel inimesel v\u00f5ib olla t\u00e4ita mitu rolli kuid v\u00e4ga \u00fcldiselt jagunevad meeskonnaliikmed juhtideks (manager<\/em>), disaineriteks (designer<\/em>), arendajateks (developer<\/em>) ja dokumenteerijateks (documenter<\/em>).<\/p>\n

                    Projektijuht<\/strong> (project manager<\/em>) koordineerib projekti l\u00e4biviimist, jagab meeskonnaliikmetele \u00fclesandeid, hoolitseb vajalike ressursside k\u00e4ttesaadavuse eest, organiseerib kohtumisi ja koost\u00f6\u00f6d k\u00f5igi osapoolte vahel (klient, disainer, arendaja jne). Sageli on juht abiks kui m\u00f5ni projekti osa on ajakavast maha j\u00e4\u00e4nud.<\/p>\n

                    Veebidisainer<\/strong> (web designer<\/em>) loob toote visuaalse poole, kogub ja loob kasutatava graafika jne. Suuremates meeskondades on disaineri \u00fclesanded kitsamalt jagatud:<\/p>\n

                      \n
                    • Graafikadisainer (web graphics designer<\/em>) loob ja t\u00f6\u00f6tleb graafikafaile (illustratsioonid, b\u00e4nnerid jms), optimeerib neid veebi jaoks.<\/li>\n
                    • Multimeediumidisainer (web multimedia designer<\/em>) tegeleb heli ja videoklippide loomise ja t\u00f6\u00f6tlemisega, sageli ka graafikaga. V\u00e4iksemas meeskonnas v\u00f5ib see roll olla \u00fchendatud graafikadisaineri rolliga, suuremas aga v\u00f5ib heli ja video jaoks olla eraldi inimene.<\/li>\n
                    • Kasutajaliidese disainer (user interface designer<\/em>) hoolitseb, et veebileht oleks mugavalt kasutatav (navigatsioon jms).<\/li>\n
                    • Kasutajakogemuse disainer (User eXperience designer<\/em>) on uus roll, tegeleb parima kasutajakogemuse loomisega.<\/li>\n<\/ul>\n

                      Veebiprogrammeerija<\/strong> (web programmer<\/em>) ehk arendaja (developer<\/em>) loob loogika (koodi), mis t\u00f6\u00f6tab kujunduse taga ning hoolitseb, et rakendus teeks seda, mida n\u00f5utud.<\/p>\n

                      Dokumenteerija <\/strong>(documenter<\/em>) koostab k\u00f5ik projektiga seotud dokumendid, protokollib koosolekuid, hoolitseb, et kogu dokumentatsioon oleks k\u00f5igile meeskonnaliikmetele k\u00e4ttesaadav.<\/p>\n

                      Testija<\/strong> (tester<\/em>) testib loodud rakendust, selle osi, otsib v\u00f5imalikke vigu ja probleeme ning annab nende kohta infot disaineritele ja arendajatele.<\/p>\n

                      Tellija<\/strong> ehk klient (client<\/em>) ei osale k\u00fcll igap\u00e4evaselt meeskonna t\u00f6\u00f6s kuid ideaalis on ta tihedas kontaktis projektijuhi ning disaineritega, et loodav veebileht vastaks tema soovidele ja ootustele.<\/p>\n

                      Lisaks v\u00f5ib meeskonda kuuluda veel hulk erinevaid spetsialiste, kes hoolitsevad n\u00e4iteks tekstide (sisu) kirjutamise eest, andmebaaside loomise eest, meeskonda v\u00f5ib kuuluda fotograaf jne.<\/p>\n

                      Suuremate, vastutusrikkamate projektide puhul kuulub meeskonda ka valdkonnaspetsialist, kes peab j\u00e4lgima, et veebileht vastaks k\u00e4sitletava valdkonna vajadustele, n\u00f5uetele. V\u00e4iksemate projektide puhul on valdkonnaspetsialisti rollis sageli tellija ise.<\/p>\n

                      Eluts\u00fckkel<\/h2>\n

                      Igasuguse toote eluts\u00fckli moodustavad k\u00f5ik temaga seotud tegevused kavandamisest valmimise, hilisema hoolduse ja t\u00e4iendamise ja l\u00f5puks kasutusest k\u00f5rvaldamiseni. \u00dcldiselt vaadeldakse tarkvara puhul tema loomist ja t\u00e4iendamist ning kuna t\u00e4iendamine kordab v\u00e4iksemas mahus m\u00f5ningaid loomise etappe, siis tavaliselt r\u00e4\u00e4gitakse tarkvara ehk siis meie puhul veebilehe loomise eluts\u00fcklist.<\/p>\n

                      Veebilehe loomise etappe (nagu mistahes tarkvara puhul) loetletakse erinevates allikates erinevate nimedega kuid sisult on tegemist alati j\u00e4rgmistega:<\/p>\n

                        \n
                      • n\u00f5uete v\u00e4ljaselgitamine (requirements<\/em>);<\/li>\n
                      • kavandamine (design<\/em>);<\/li>\n
                      • teostamine (implementation<\/em>);<\/li>\n
                      • valideerimine (validation<\/em>);<\/li>\n
                      • tugiteenus (support<\/em>).<\/li>\n<\/ul>\n

                        \u00dckski meeskond ei saa korralikku veebilehte luua ilma k\u00f5iki neid etappe l\u00e4bimata. H\u00f5lbustamaks t\u00f6\u00f6 planeerimist, on v\u00e4lja t\u00f6\u00f6tatud mitmeid erinevaid mudeleid, kuidas toote loomise eluts\u00fcklit l\u00e4bida (koskmudel (waterfall), spiraalmudel (spiral<\/em>), t\u00e4htmudel (star<\/em>) jpt). Praegusel ajal kasutatakse v\u00e4ga palju nn ADDIE mudelit v\u00f5i selle erinevaid variatsioone. Tegemist on lihtsa, loogilise mudeliga, mille j\u00e4rgimine aitab t\u00f6\u00f6d planeerida ja juhtida. ADDIE mudeli igas faasis saadav tulemus on l\u00e4htematerjaliks j\u00e4rgmisele faasile.<\/p>\n

                          \n
                        • Anal\u00fc\u00fcsi (analysis<\/em>) faasis selgitatakse “probleem”, p\u00fcstitatakse eesm\u00e4rgid, selgitatakse tingimused (n\u00f5uded).<\/li>\n
                        • Disaini (design<\/em>) faasis valitakse strateegia, vahendid, meedia jms.<\/li>\n
                        • Arendusfaasis (development<\/em>) luuakse toode vastavalt disainifaasis tehtud otsustele.<\/li>\n
                        • Rakendusfaasis (implementation<\/em>) testitakse toote protot\u00fc\u00fcpe, valmistatakse l\u00f5plik toode ja v\u00f5etakse see kasutusele (luuakse juhendmaterjalid, koolitatakse kasutajad jne).<\/li>\n
                        • Hindamisfaasis (evaluation<\/em>) testitakse ja hinnatakse toodet (kasutajate tagasiside).<\/li>\n<\/ul>\n
                          \"ADDIE
                          ADDIE arendusmudel<\/figcaption><\/figure>\n

                          Hindamist viiakse tegelikult l\u00e4bi praktiliselt k\u00f5ikides etappides, igas etapis toimub t\u00f6\u00f6 iteratiivselt, et saada parim tulemus.<\/p>\n

                          Iteratiivse mudeli kohaselt koosneb igasugune arendusprotsess mitmest j\u00e4rjestikusest ts\u00fcklist (iteratsioonist), mis k\u00f5ik sisaldavad anal\u00fc\u00fcsi, disaini, programmeerimist ja testimist.<\/p>\n

                          J\u00e4rgnevalt vaatleme veebilehe loomise eluts\u00fckli etappe just sellest mudelist l\u00e4htudes.<\/p>\n

                          Anal\u00fc\u00fcs<\/h1>\n

                          Veebilehe loomine algab kokkuleppest tellijaga. Tavaliselt avaldab tellija soovi saada mingisugust veebilehte v\u00f5i veebirakendust, esitab teatud tingimused, l\u00e4hte\u00fclesande ja selle p\u00f5hjal p\u00fc\u00fctakse teha hinnapakkumist. Reeglina on vaja tellijale esitada t\u00e4psustavaid k\u00fcsimusi, et paremini hinnata ees ootavat t\u00f6\u00f6de mahtu ja iseloomu.<\/p>\n

                          Kokkuleppe saavutamise j\u00e4rel algab t\u00e4psem anal\u00fc\u00fcs, mida klient soovib, mida see tegema peab, millised on n\u00f5udmised v\u00e4ljan\u00e4gemisele jne. Kliendi soovide v\u00e4ljaselgitamine ning tema ideede rakendamine kujunduses suurendab rahulolu tulemusega ja v\u00e4hendab hilisemaid kulutusi kasutajatoele ning veebirakenduse hooldamisele.<\/p>\n

                          Toimub n\u00f5uete kogumine (requirements gathering<\/em>). Selgitatakse v\u00e4lja:<\/p>\n

                            \n
                          • funktsionaalsed n\u00f5uded (functional requirements<\/em>) \u2013 mida loodav veebileht v\u00f5i veebirakendus peab tegema;<\/li>\n
                          • andmete n\u00f5uded (data requirements<\/em>) \u2013 milliseid andmeid loodav s\u00fcsteem vajab, kasutab,;<\/li>\n
                          • kasutusk\u00f5lbulikkuse n\u00f5uded (usability requirements<\/em>) \u2013 puudutavad tulevasi kasutajaid, nende eeldatavaid kogemusi ja oskusi, millele s\u00fcsteem peab vastama.<\/li>\n<\/ul>\n

                            N\u00f5uete kogumiseks kasutatakse k\u00f5ige enam intervjuud kliendiga, vesteldakse, k\u00fcsitletakse. Kasulik on kliendiga vestlusesse kaasata mitu meeskonnaliiget (aitab tagada, et kliendi soovidest saadakse \u00f5igesti aru), kindlasti peab kohal olema disainer.<\/p>\n

                            Eelt\u00f6\u00f6na enne intervjuud, saab tutvuda valdkonnaga, mida loodav veebileht k\u00e4sitleb, tutvuda teiste sama valdkonna veebilehtedega, tellija vana veebilehega (kui see on olemas).<\/p>\n

                            Alustatakse veebilehe eesm\u00e4rkide selgitamisega. Otsitakse vastuseid k\u00fcsimustele:<\/p>\n

                              \n
                            • Millist informatsiooni peab loodav veebileht edastama?<\/li>\n
                            • Millised komponendid on olemas k\u00f5igil edukatel veebilehtedel?<\/li>\n
                            • Milliseid aspekte peab loodava veebilehe kujundamisel veel arvestama?<\/li>\n<\/ul>\n

                              V\u00e4ga t\u00e4pselt tuleb v\u00e4lja selgitada veebilehe sihtgrupp, kes hakkavad seda k\u00fclastama\/kasutama. P\u00fc\u00fcdke leida vastuseid k\u00fcsimustele:<\/p>\n

                                \n
                              • Kes hakkavad loodavat veebilehte k\u00fclastama? Millised on nende vajadused? See info aitab otsustada, millist informatsiooni on vaja veebilehele lisada.<\/li>\n
                              • Miks inimesed seda veebilehte k\u00fclastama peaksid? Millistes sotsiaalsetes oludes v\u00f5imalikud k\u00fclastajad elavad, t\u00f6\u00f6tavad?<\/li>\n
                              • Millist dialoogi, milliseid s\u00f5numeid soovivad k\u00fclastajad veebilehelt saada?<\/li>\n
                              • Millist tehnoloogiat kasutada k\u00fclastajatega suhtlemiseks?<\/li>\n<\/ul>\n

                                Koost\u00f6\u00f6s kliendiga on vaja otsustada, milliseid komponente veebilehel kasutada, millised nende seas on kriitilise t\u00e4htsusega, millised lihtsalt kasulikud ja milliseid v\u00f5iks lisada, kui nende jaoks ressursse j\u00e4tkub. On hulk kliente, kes v\u00e4ga t\u00e4pselt teavad ja n\u00f5uavad, mida leht peab sisaldama ja mida mitte, on ka selliseid, kelle ainus konkreetne soov on saada endale veebileht. Kliendile saab pakkuda erinevaid v\u00f5imalusi, komponente kuid mitte neid peale
                                \nsuruda.<\/p>\n

                                Kindlasti tuleb uurida ka kliendi soove loodava veebilehe v\u00e4limuse osas. Milline on kliendi logo (kui see on olemas), kas on olemas nn firmav\u00e4rvid ning kas neid on tarvis kasutada, milliseid kirjastiile eelistatakse jne.<\/p>\n

                                T\u00e4helepanu tuleb p\u00f6\u00f6rata ka sellele, millised vajadused ja v\u00f5imalused on kliendi veebilehe majutamiseks (hosting<\/em>). T\u00e4psemad tingimused (kui palju kettaruumi vajatakse, milliseid tehnoloogiaid peab veebiserver toetama) saab m\u00e4\u00e4rata alles p\u00e4rast disainiprotsessi kuid juba anal\u00fc\u00fcsi ajal on tarvis sellele m\u00f5elda. V\u00f5imalik, et klient soovib veebilehte majutada kindla teenusepakkuja juures v\u00f5i oma serveris, mis v\u00f5ib seada tehnilisi piiranguid, mida peab juba algusest peale arvesse v\u00f5tma.<\/p>\n

                                V\u00e4lja tuleb p\u00fc\u00fcda selgitada:<\/p>\n

                                  \n
                                • kui palju on tarvis kettaruumi (arvestada tuleb ka laiendamisvaru);<\/li>\n
                                • mis tehnoloogiaid tuleb kliendi soovitud veebilehe loomisel kasutada;<\/li>\n
                                • mis t\u00fc\u00fcpi faile soovitakse veebilehel kasutada (m\u00f5ned veebimajutuse pakkujad seavad teatud failivormingutele piiranguid);<\/li>\n
                                • kui suur on planeeritav k\u00fclastatavus, millise andmeliiklusega peaks arvestama.<\/li>\n<\/ul>\n

                                  Anal\u00fc\u00fcsi tulemusena koostatakse loodava veebilehe spetsifikatsioon, kuhu pannakse kirja k\u00f5ik n\u00f5uded, tingimused, mis on v\u00e4lja selgitatud ning loodava veebilehe kirjeldus. N\u00f5uete kirjapanekuks on loodud ka erilisi abstraktseid keeli kuid kasutada v\u00f5ib ka naturaalset keelt, v\u00e4ltida tuleks vaid sl\u00e4ngi.<\/p>\n

                                  Kui spetsifikatsioon on kliendiga koosk\u00f5lastatud, algab disainietapp.<\/p>\n

                                  Disain<\/h1>\n

                                  K\u00f5igepealt tuleb l\u00e4bi m\u00f5elda veebilehe struktuur, kuidas sisu organiseerida. K\u00f5ik kliendiga kokku lepitud komponendid ja veebilehe sisu jagatakse kategooriateks, hierarhiasse. Arendusmeeskond valib spetsifikatsioonist l\u00e4htudes eesm\u00e4rkide saavutamiseks k\u00f5ige paremini sobivad ning n\u00f5uetele vastavad tehnoloogiad.<\/p>\n

                                  J\u00e4rgmine samm on juba veebilehe v\u00e4limuse planeerimine. Disainer alustab lihtsatest eskiisidest ning j\u00f5uab l\u00f5puks t\u00e4psete protot\u00fc\u00fcpideni, milledel on paigas visuaalne k\u00fclg: navigatsioonivahendid, komponentide paigutus.<\/p>\n

                                  Luuakse protot\u00fc\u00fcbid, mis tulevast veebilehte kirjeldavad. Keerukamate tegevuste sooritamise kohta luuakse nn kasutajalood \u2013 pannakse detailselt ja sammhaaval kirja, kuidas kasutaja tegevusi sooritab.<\/p>\n

                                  Disaini ja arendusmeeskond loob koost\u00f6\u00f6s mitmeid erinevaid ideekavandeid ja kujundusversioonide eskiise, millede seast koost\u00f6\u00f6s kliendiga valitakse v\u00e4lja k\u00f5ige paremini kliendi vajadustele vastav variant.<\/p>\n

                                  Protot\u00fc\u00fcpimine<\/h2>\n

                                  Looge veebilehestiku disaini illustreeriv mudel (sisukaart jms), see v\u00f5imaldab kliendil juba kujundusprotsessi varajases staadiumis tagasisidet anda kui muudatusi on veel v\u00e4ga lihtne teha. Hiljem lisage juba ka kasutajaliidese protot\u00fc\u00fcp (eskiis, joonistus), mis v\u00f5imaldab kliendil aimu saada, milline veebileht tegelikkuses v\u00e4lja n\u00e4gema hakkab.<\/p>\n

                                  T\u00fc\u00fcpiliselt tuleb l\u00e4bida mitu t\u00f6\u00f6ringi: kujundada, hinnata tulemust kliendiga suheldes, \u00fcmber t\u00f6\u00f6tada jne.<\/p>\n

                                  Tavaliselt kasutatakse disaini illustreerimiseks j\u00e4rgmist t\u00fc\u00fcpi mudeleid:<\/p>\n

                                    \n
                                  • sisukaart (site map<\/em>) \u2013 reeglina tekstip\u00f5hine \u00fclesehituse kirjeldus;<\/li>\n
                                  • s\u00fc\u017eeetahvel (storyboard<\/em>) \u2013 veebilehestiku graafiline skeem, v\u00f5ib olla paberile joonistatud, loodud mistahes graafikaprogrammiga, genereeritud m\u00f5ne veebiredaktori (HTML editor<\/em>) poolt;<\/li>\n
                                  • s\u00f5restikmudel (wireframe<\/em>) \u2013 kest, mis n\u00e4itab loodavaid veebilehti. Iga leht on joonistatud informatsiooniplokkidena, mis n\u00e4itavad kus ja kuidas paiknevad erinevad komponendid. Selliselt esitatakse objektide visuaalne paigutus (layout<\/em>) kuid mitte l\u00f5plik v\u00e4limus.<\/li>\n<\/ul>\n

                                    Sisukaart<\/h3>\n

                                    Sisukaart (site map<\/em>) on \u00fcks kriitilise t\u00e4htsusega ja laialt kasutatav vahend veebidisainis. Kuna sisukaart n\u00e4itab veebilehestiku \u00fcldist struktuuri ja hierarhiat, siis kasutataksegi neid veebilehestiku \u00fcldise \u00fclesehituse ja navigatsiooni kavandamisel.<\/p>\n

                                    Alustada tuleks lihtsast, j\u00e4medakoelisest eskiisist, lisades sinna lihtsalt esmaselt planeeritud, olulised lehed. V\u00e4ltida tuleks detailse info lisamist sisukaardile. Sisukaart muutub ja t\u00e4ieneb projekti edenedes.<\/p>\n

                                    Sisukaardid on enamasti tekstip\u00f5hised kuid vahetevahel ka graafilised. Iga lehe kohta pannakse kirja pealkiri ning talle viitav link (URL). T\u00f6\u00f6 k\u00e4igus v\u00f5ivad disainerid sinna lisainfot kirja panna (n\u00e4iteks lehe olulisus terviklikus veebilehestikus, viimase muutmise aeg, kui sageli seda lehte muudetakse jne).<\/p>\n

                                    V\u00e4gagi sageli lisatakse HTML sisukaart valmis veebilehestikule. See on eriti kasulik, kui veebilehestik sisaldab paljusid lehti, lihtsustab navigatsiooni ning v\u00f5imaldab ka otsingumootoritel veebilehestikku l\u00e4bi uurida.<\/p>\n

                                    \"N\u00e4ide
                                    N\u00e4ide veebilehe sisukaardist<\/figcaption><\/figure>\n

                                    S\u00fc\u017eeetahvel<\/h3>\n

                                    S\u00fc\u017eeetahvlit (storyboard<\/em>) kasutatakse lisaks sisukaardile aitamaks teha otsuseid disaini, tehnoloogia aga ka eelarve osas. Hea s\u00fc\u017eeetahvel pakub k\u00f5igile projektiga seotud inimestele selget \u00fclevaadet loodavast veebilehestikust.<\/p>\n

                                    S\u00fc\u017eeetahvlil ei ole n\u00e4ha k\u00f5iki \u00fcksikuid veebilehestiku lehti kuid see katab peamised lehestiku funktsionaalsed osad. Reeglina pannakse iga lehe kohta kirja pealkiri ja m\u00f5ned m\u00e4rkmed tema sisu kohta.<\/p>\n

                                    Ka s\u00fc\u017eeetahvel ei sisalda mingit infot lehtede visuaalse disaini kohta kuid v\u00f5imaldab saada ettekujutuse, millised p\u00f5hielemendid igal lehel olemas on.<\/p>\n

                                    S\u00fc\u017eeetahvli v\u00f5ib sarnaselt sisukaardile luua pliiatsiga paberile joonistades v\u00f5i m\u00f5nda graafikaprogrammi kasutades.<\/p>\n

                                    \"N\u00e4ide
                                    N\u00e4ide s\u00fc\u017eeetahvlist<\/figcaption><\/figure>\n

                                    S\u00f5restikmudel<\/h3>\n

                                    S\u00f5restikmudel (wireframe<\/em>) veebidisainis on veebilehele paigutatavate elementide skemaatiline esitus. V\u00f5tmes\u00f5naks s\u00f5restikmudeli puhul on kiirus, neid kasutatakse uute ideedega eksperimenteerimiseks, testimiseks ja sobitamiseks aga mitte kujunduse detailseks kuvamiseks.<\/p>\n

                                    Kliendiga suhtlemisel lasevad s\u00f5restikmudelid kliendil keskenduda lehe \u00fclesehitusele (layout<\/em>) laskmata end disainielementidel (pildid, kirjastiilid jt) oluliselt k\u00f5rvale kallutada.<\/p>\n

                                    S\u00f5restikmudeli loomisel kasutatakse lihtsaid graafilisi kujundeid (mitte reaalseid pilte), lisatakse neile pealkiri. S\u00f5restikmudelil peavad n\u00e4htaval olema k\u00f5ik t\u00e4htsad veebilehe elemendid.<\/p>\n

                                    \"N\u00e4ide
                                    N\u00e4ide veebilehe s\u00f5restikmudelist<\/figcaption><\/figure>\n

                                    Stsenaarium<\/h3>\n

                                    Stsenaarium (scenario<\/em>) on verbaalne protot\u00fc\u00fcp, mis kirjeldab loodava veebilehe \u00fclesehitust. Siia alla kuuluvad ka kasutajalood (user story<\/em>) \u2013 tegevuste, valikute ja tulemuste verbaalsed kirjeldused.<\/p>\n

                                    Visuaalne disain<\/h2>\n

                                    P\u00e4rast veebilehestiku struktuuri ja \u00fcksikute lehtede \u00fclesehituse (komponentide paigutus) fikseerimist saab asuda visuaalse disaini juurde. Valitakse kirjastiil pealkirjadele ja tekstile, kasutatava graafika stiil ja v\u00e4rviskeem. L\u00e4htepunktiks on veebilehe s\u00f5restikmudel (wireframe<\/em>).<\/p>\n

                                    Protot\u00fc\u00fcpidena kasutatakse siinkohal joonistusi (lihtsatest visanditest detailsete v\u00e4rvipiltideni) ja ekraanipilte. Visandid on sageli k\u00e4sitsi tehtud, v\u00e4rvipiltide loomisel kasutatakse kujundusprogramme.<\/p>\n

                                    Ka visuaalsest disainist luuakse mitmeid erinevaid versioone, millede seast koos kliendiga sobivaim v\u00e4lja valitakse.<\/p>\n

                                    Detailne protot\u00fc\u00fcp<\/h2>\n

                                    P\u00e4rast seda, kui k\u00f5ik osapooled on disainiprotsessis osalenud, valmib veebilehestiku detailne protot\u00fc\u00fcp, s\u00fc\u017eeetahvlile (storyboard<\/em>) ja s\u00f5restikmudelile on lisandunud hulk detaile, valminud on visuaalne kujundus.<\/p>\n

                                    Kokku on pandud kogu materjal, millest l\u00e4htudes saavad arendajad soovitud veebilehe luua. Protot\u00fc\u00fcpi hinnatakse koos kliendiga ja selle heakskiitmisel algab arendusprotsess.<\/p>\n

                                    Arendus<\/h1>\n

                                    Arendusfaasis toimub koostatud spetsifikatsioonile vastava veebilehe loomine: programmeerimine, andmebaaside loomine, rakenduse sidumine visuaalse kujundusega, animatsioonide, graafika, heli- ja videoklippide loomine jms. \u00dcks olulisemaid asju on kogu arendusprotsessi jooksul keskenduda kliendi ja kasutaja vajadustel!<\/p>\n

                                    Disain pole kunagi ideaalne, veatu. Arendusprotsess peab olema iteratiivne \u2013 korduv loomine, \u00fclevaatamine ja muutmine kuni tulemus vastab kliendi ja kasutaja soovidele. \u00dcldiselt on soovitatav ka arendusfaasis kliendiga v\u00f5imalikult tihedat koost\u00f6\u00f6d teha. Klienti ei huvita iga koodirida v\u00f5i loodud pilt kuid mingit funktsionaalsust pakkuvate komponentide valmimisel on m\u00f5istlik neid kohe kliendile n\u00e4idata.<\/p>\n

                                    Iteratiivse arendusega v\u00f5ib ka juba olemasolevaid veebilehti edasi arendada tehes regulaarselt v\u00e4ikseid muudatusi. Muudatusi tuleb teha ts\u00fcklitena j\u00e4ttes alati alles osad, mis “t\u00f6\u00f6tavad” ning asendades sobimatuid.<\/p>\n

                                    Rakendamine<\/h1>\n

                                    \u00dcleminek arendusfaasist rakendamisfaasi pole v\u00e4ga selgelt m\u00e4\u00e4ratletav. Rakendusfaasis toimub testimine ja vigade leidmisel nende parandamine (mis on sisuliselt arendamine). P\u00e4rast arendusprotsessi algab testimine ja t\u00e4iustamine (refinement<\/em>), mis on samuti iteratiivne protsess. Selle k\u00e4igus otsitakse ja parandatakse tehnilisi vigu, kasutusk\u00f5lbulikkuse (usability<\/em>) vigu, vaadeldakse lehe avanemiseks kuluvat aega ja vajadusel optimeeritakse rakendust.<\/p>\n

                                    Testimisprotsess h\u00f5lmab mitmeid erinevaid hindamisi, n\u00e4iteks:<\/p>\n

                                      \n
                                    • Heuristiline l\u00e4bivaatus (heuristic evaluation<\/em>) \u2013 eksperdid vaatavad \u00fcle loodava veebilehe kasutajaliidese (user interface<\/em>) ning hindavad seda kasutusk\u00f5lbulikkuse (usability<\/em>) seisukohalt l\u00e4htudes \u00fcldtunnustatud kasutusk\u00f5lbulikkuse printsiipidest. Erinevad inimesed m\u00e4rkavad erinevaid vigu, seet\u00f5ttu on \u00fchel inimesel \u00fcksinda heuristilist l\u00e4bivaatust teha, tavaliselt soovitatakse kasutada kolme kuni viit eksperti. Leitud vead tuleb loomulikult k\u00f5rvaldada.<\/li>\n
                                    • Korrektuur (proofread<\/em>) \u2013 testitakse k\u00f5iki rakenduse interaktiivseid elemente (ekraanivormid, dialoogiboksid jms). Vajadusel \u00f5petatakse klienti k\u00f5iki rakenduse osi kasutama. Vaadatakse \u00fcle \u00f5igekiri ja grammatika. Kontrollitakse kas k\u00f5ik lingid avanevad ja viitavad \u00f5igetele lehtedele.<\/li>\n
                                    • Mitteformaalne testimine, valjusti m\u00f5tlemine (think aloud<\/em>) \u2013 veebirakendust kasutavad kaks inimest koos, \u00fcks tegutseb ja arutleb valjusti oma tegevuste \u00fcle (avaldab m\u00f5tteid, tekkivaid k\u00fcsimusi jne), teine teeb m\u00e4rkmeid. Sellisel moel tulevad probleemid kiiresti ilmsiks sest protsess h\u00f5lmab reaalset t\u00f6\u00f6d rakendusega. Testkasutajaks peab olema inimene, kes pole seda rakendust enne n\u00e4inud ega tea selle eesm\u00e4rki, otstarvet. Testkasutajale tuleks aega anda 30 minutit, kui ta vajab rohkem aega, siis vajab rakendus \u00fcmbertegemist!<\/li>\n<\/ul>\n

                                      Testimisprotsessi j\u00e4rel tuleks veebirakendus publitseerida testserverile, mis pole k\u00f5igile avalikult k\u00e4ttesaadav, et ka klient saaks tulemust testida.<\/p>\n

                                      Rakendusfaasi k\u00e4igus koostatakse ka rakenduse dokumentatsioon (juhendmaterjalid jms), vajadusel koolitatakse kasutajaid (kliendi esindajad, tulevased veebilehe administraatorid jne).<\/p>\n

                                      Vajadusel tuleb teha veel t\u00e4iendavaid muudatusi ning alles seej\u00e4rel kui ka klient on tulemuse heaks kiitnud publitseeritakse veebirakendus avalikuks kasutamiseks avalikku serverisse.<\/p>\n

                                      Veebileht on valmis. Siinkohal sageli eluts\u00fckkel katkestatakse!<\/p>\n

                                      Hindamine<\/h1>\n

                                      Hindamisfaas on see, mis toimub p\u00e4rast veebilehe valmimist ja publitseerimist. Selle k\u00e4igus toimub formaalne kasutusk\u00f5lbulikkuse hindamine (formal usability studies<\/em>) \u2013 protsess, mille k\u00e4igus anal\u00fc\u00fcsitakse reaalseid kasutusandmeid inimese ja s\u00fcsteemi koost\u00f6\u00f6 kohta. K\u00f5ige tavap\u00e4rasemateks andmeallikateks on veebiserveri logid, veebikasutuse anal\u00fcsaatorid (n\u00e4iteks Google Analytics). Sellist hindamist saabki l\u00e4bi viia alles p\u00e4rast veebilehe publitseerimist (aga n\u00e4iteks ka testkasutamise ajal testserveril) ning v\u00f5ib olla v\u00e4gagi kallis. Hea on see, et
                                      \npole vaja otsida testkasutajaid v\u00f5i eksperte, kasutada on andmed reaalsete igap\u00e4evaste kasutajate k\u00e4itumise kohta veebilehel.<\/p>\n

                                      Hindamisfaasis tuntakse huvi kasutajate tagasiside vastu, uuritakse, kuidas ollakse veebilehega rahul.<\/p>\n

                                      Hindamisfaas j\u00e4\u00e4b sageli v\u00e4ga l\u00fchikeseks v\u00f5i seda ei toimugi. Tavaliselt ilmneb hulk v\u00f5imalikke probleeme alles pikema aja jooksul reaalse kasutamise k\u00e4igus ning ka siis oleks tarvis parandusi teha, seda aga tihtipeale arendaja ja kliendi vahel kokku ei lepita.<\/p>\n

                                      M\u00f5istlik oleks juba esimeste kokkulepete s\u00f5lmimisel kliendiga juhtida t\u00e4helepanu ka v\u00f5imalikule vajadusele hiljem t\u00e4iendusi ja parandusi teha ning selle tegevuse tingimustes kokku leppida. Samas on selline hilisem arendust\u00f6\u00f6 arendajale t\u00fclikas sest projektiga seotud meeskond on juba h\u00f5ivatud teiste projektidega v\u00f5i lausa laiali l\u00e4inud.<\/p>\n","protected":false},"author":1,"menu_order":4,"template":"","meta":{"_mi_skip_tracking":false,"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"part":3,"_links":{"self":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapters\/506"}],"collection":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":3,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapters\/506\/revisions"}],"predecessor-version":[{"id":513,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapters\/506\/revisions\/513"}],"part":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapters\/506\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/wp\/v2\/media?parent=506"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/pressbooks\/v2\/chapter-type?post=506"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/wp\/v2\/contributor?post=506"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ramk.ee\/opikud\/veebidisain\/wp-json\/wp\/v2\/license?post=506"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}