…meie igapäevast IT’d anna meile igapäev…

2010-07-02

12 soovitust Eesti riigi andmeregistrite loomisel

Filed under: Eesti,Infotehnoloogia,Terve mõistus — Sander @ 11:50:27

Olen siin blogis päris paljudel kordadel kurtnud Eesti riigi infosüsteemide ja registrite üle. Rõhuv enamus neist on kahjuks masendavalt halvasti teostatud – odavpakkumiste loomulik tulemus. Kuid et kriitika ei jääks ainult virisemiseks, siis kirjutan siia tosinkond soovitust, mida võiks silmas pidada Eesti andmeregistrite loomisel. Paljud nõuanded on lihtsad, terve mõistuse vili (või noh, nii terve kui minu parandamatult haige ja paheline mõistus saab olla), mõned neist eksisteerivad vastavates juhtnöörides, kuid neid ei täideta järjekindlalt.

Ma ei saa kuidagi jätta mainimata, et Eestil peaks olema sarnane andmete allalaadimise leht nagu on http://data.gov ja http://data.gov.uk. http://data.eesti.ee, kus sa oled?

Alguses on lihtsalt soovituste nimekiri ning allpool on need detailsemalt lahti kirjutatud. Kui saad, siis edasta see postitus vastavatele IT-arhitektidele, analüütikutele ja muudele asjameestele – ning kohe kindlasti tellijapoolele – riigiametnikele, nõustajatele ja spetsialistidele.

Soovitused

  1. Lähtuda tuleb põhimõttest, et kõik mis ei ole salastatud on avalik info ja peab olema kättesaadav registri kasutajale.
  2. Kõik lehed peavad olema üheselt identifitseeritud ja taaskülastatavad brauseri aadressiribal kuvatava URL kaudu.
  3. Avaliku info päringuid peab olema võimalik teha ka standardeid (SOAP, REST, OData vms) järgivate veebiteenuste abil. Veebiteenuste ebastandardsed laiendused ei ole lubatud.
  4. Otsingute ja detailinfo päringute tulemusi peab olema võimalik eksportida standardformaadis failina (CSV, XML). Eksportimisel lähtutakse ideest “pigem rohkem infot, kui vähem”.
  5. Otsinguid peab olema võimalik sooritada ka HTML GET abil, välja arvatud juhtudel kus see on võimatu otsingu ülisuure mahukuse või keerukuse tõttu
  6. Otsingutel peab olema võimalus kõigi leitud vastete korraga näitamiseks.
  7. Registritel peab olema detailne abileht, mis kirjeldab muuhulgas ka veebiteenuste kasutamist.
  8. Mitte midagi ei tohi avaneda brauseri poolt potentsiaalselt blokeeritavates hüpikakendes.
  9. Register peab olema kasutatav kõigis levinumates moodsates brauserites. Aluseks võetakse viimased registri loomise alguses väljas olnud versioonid, v.a. Internet Explorer, mida toetatakse alates versioonist 7.
  10. Register peab olema tavakoormuse juures kasutatava kiirusega. Kui välja arvata andmebaasist päringute sooritamise aeg, siis peab veebiserver saatma vastuse vähem kui sekundi jooksul, hoolimata sellest kas antud kasutaja sessioon on olemas või ei.
  11. Kõik lehed peavad valideeruma W3C HTML-validaatoris ilma vigadeta. CSS’i valideerimisel on lubatud brauserispetsiifikast tulenevad vead.
  12. AJAX’it kasutatakse ainult leheosa, mitte aga kogu lehe laadimiseks. Võimaluse korral kajastatakse JS poolt tehtud muudatused lehe aadressi ankruosas – ning leides lehe laadimisel aadressi ankruosas väärtusi, taastatakse lehel vastav seis.

Seletused

1. Lähtuda tuleb põhimõttest, et kõik mis ei ole salastatud on avalik info ja peab olema kättesaadav registri kasutajale

Eesti riigiametnikke tabab regulaarselt salastusmaania. Tullakse välja lausidiootsete põhjendustega info kättesaamise piiramiseks – kui vaevutakse üldse põhjendust leiutama. Registrite kaudu peaks olema kättesaadav kogu info, mis ei ole salastatud või muudel põhjustel piiratud (isikuandmed jms). Info ei ole ametniku või ametkonna isiklik omandus, see on ühisvara.

2. Kõik lehed peavad olema üheselt identifitseeritud ja taaskülastatavad brauseri aadressiribal kuvatava aadressi kaudu

See on kivi eelkõige Webmedia ja nende Aranea frameworki kapsaaeda. Selle asemel, et lehekülg oleks alati kättesaadav antud hetkel brauseri aadressiribal oleva aadressi kaudu, on seal “…/main#HTTPebJlCv0dIkT5WnItLXGItaOHaF9hsI” ja kusagil lehe allservas “Objekti link:”, mis pahatihti ei tööta.

URL on interneti alus – see identifitseerib üheselt külastatava lehe. Kui ma võtan brauseri aadressiribalt URL’i ja saadan selle sõbrale, siis võin ma üldjuhul olla kindel, et ta näeb sellel klikkides sama lehte, millelt ma selle aadressi võtsin. Hoides mingil arusaamatul põhjusel reaalset kasutaja asukohta sessioonis on registri käitumine vastupidine enamiku kasutajate veebikogemustele – ning seda tuleks kindlasti vältida.

Samuti võiks aadressid olla REST-stiilis, inimloetavad ja otsimootorisõbralikud. Mitte http://register.keskkonnainfo.ee/envreg/main?reg_kood=KLO1000300&mount=view vaid http://register.keskkonnainfo.ee/envreg/details/klo1000300/matsalu-rahvuspark. Mõlemal juhul on identifitseerivaks osaks KLO1000300 ehk kood, kuid teine aadress on inimesele arusaadav, näiteks lingina e-kirjas, chatis või mujal. Lisaks meeldivad sellised lingid väga-väga Googlele.

3. Avaliku info päringuid peab olema võimalik teha ka standardeid (SOAP, REST, OData vms) järgivate veebiteenuste abil. Veebiteenuste ebastandardsed laiendused ei ole lubatud

Tehes võimalikuks veebiteenuste kasutamine infopäringuteks, võimaldab register teistel saitidel ja programmidel pärida infot otse registrist, ilma kasutaja jaoks lehte avamata. Seeläbi saab võimalikuks mugavalt toimivate teenuste ja veebisaitide loomine – näiteks Eesti loodust tutvustav veebileht saaks jooksvalt küsida Keskkonnaregistrist kaitstavate loodusobjektide infot, seda töödelda ning oma kasutajatele kuvada uusimat infot. Registri eesmärk on info jagamine, mitte selle varjamine.

Võimalikud on ka mitmetest registritest ristpäringute tegemised jne. Kindlasti peaksid avalikku infot tagastavad veebiteenused toimima ilma täiendava registreerimise-identifitseerimiseta, olles kõikidele kasutamiseks.

Praegu kehtiva negatiivse näitena võib tuua Eesti Posti (mis küll ei ole register), kes pole postiindeksi otsingut suutnud juba aastaid veebiteenusesse panna. Seetõttu on internetipoed sunnitud lisama nupukese “Otsi indeksit Eesti Posti kodulehel”, kasutaja peab avama Eesti Posti lehe, seal otsima jne – selle asemel, et otsing toimiks otse internetipoest. Eriti hea oleks veel ka vastupidine otsing, so postiindeksi järgi aadressivaliku kuvamine.

Olen mõelnud postiindeksi veebiteenuse loomisele – so. pisike avalik SOAP-teenus, mis võtab vastu otsinguparameetrid, teeb POST-päringu EP kodulehele, parsib saadud HTML’i ja tagastab tulemuse.

Kindlasti ei tohi veebiteenustel olla proprietaarseid laiendusi või kodukootud häkke (märksõna: RELIKA), need peavad vastama täies ulatuses standarditele ja läbima vastavate validaatorite kontrollid veavabalt.

4. Otsingute ja detailinfo päringute tulemusi peab olema võimalik eksportida standardformaadis failina (CSV, XML). Eksportimisel lähtutakse ideest “pigem rohkem infot, kui vähem”

Andmete eksport lihtsustab olukordi, kus vaja on töötlemiseks mitmete registriobjektide andmeid. Näiteks kõigi Eesti looduskaitsealade koordinaadid ja pindalad, mida hiljuti ise vajasin.

Mõnedes registrites on andmete eksportimine osaliselt olemas – kuid üldjuhul on olemas vaid otsingu tulemuste väljavõtt ning sealgi pole kogu infot mis võiks olla. Alati peaks ekspordil näitama kogu avalikku infot, mis on registris objekti kohta. Kui andmeformaadiks on valitud XML, siis on võimalik ka üks-mitmele seotusega tabelites oleva info näitamine.

Eksportil tuleks eelistada XML formaati, kasutades CSV’d vaid ülilihtsatel juhtudel. Suletud ja üleliigselt keerukaid failiformaate, nagu XLS (MS Excel) kasutada ei tohi, eriti kuna Excel suudab suurepäraselt importida andmeid nii CSV kui ka XML-andmeformaatidest. Keerukamate XML’ide korral võiks olla võimalus XSD nägemiseks, kuid eriti oluline see ei ole.

Ideaalis võiks olla võimalik teha eksportpäringut vaid lisades parameetri “&format=xml” lehe aadressile. Vaata näiteks MediaWiki API funktsionaalsust siit. Samas, veebiteenuste olemasolu korral see ilmselt eriti vajalik ei ole.

5. Otsinguid peab olema võimalik sooritada ka HTML GET abil, välja arvatud juhtudel kus see on võimatu otsingu ülisuure mahukuse või keerukuse tõttu

Sarnaselt teisele punktile võimaldab GET-otsing üheselt jagatavat otsingu aadressi. Lisaks teeb see lihtsamaks otsinguid läbiviivate brauserite pluginate loomist (või ka märksõnaga otsingute lisamist nagu Google Chromes jm). Otseselt kriitiliselt oluline see soovitus ei ole, kuid kasutajasõbralikkuse huvides võiks see pisiasi tehtud olla, enamik moodsatest veebi framedest võimaldab seda lihtsalt.

Loomulikult, ülimahukate või –keerukate otsingute GET-peale tegemine ei ole ei vajalik ega ka mõttekas.

6. Otsingutel peab olema võimalus kõigi leitud vastete korraga näitamiseks

Iseenesest arusaadav, eriti lisaks andmete ekspordi võimalust arvestades.

7. Registritel peab olema detailne abileht, mis kirjeldab muuhulgas ka veebiteenuste kasutamist

Enamuse praeguste registrite abilehtede kohta saab vaid hale öelda. Puudub info funktsionaalsuse, info uuenemise, info korrektsuse eest vastutava ameti/isiku kohta jpm.

Kui registril on veebiteenuste võimalus, siis peab olema ka nende asukohad ja lühikirjeldused. Peab olema ka piisavalt tehnilisemat infot, näiteks võimalikud parameetrid ja formaadid andmete ekspordil jms.

Kindlasti peaks abilehel olema ka registri mitteavaliku funktsionaalsuse kirjeldus. Infosüsteemide korral on security through obscurity eranditult alati halb idee.

8. Mitte midagi ei tohi avaneda brauseri poolt potentsiaalselt blokeeritavates hüpikakendes

Paljudes Eesti riigi infosüsteemides ei toimu kliki peale mitte midagi, heal juhul tekib kuhugi kirjake “Lehe mitteavanemisel lubage brauseris hüpikaknad!”. See on lihtsalt halb disain/arhitektuur, muud ei midagi. Ammu on olemas piisavalt võimalusi info teises aknas avamiseks ilma probleemideta, alustades target=”_blank” lisamisest lingile ja lõpetades korrektselt tehtud JavaScripti poolt avatavate akendega.

Rääkimata sellest, et pahatihti pole vajadust avada infot teises aknas, samas aknas uuele lehele navigeerimisest piisab. Kui kasutaja soovib avada infot uues tabis, siis teeb ta ise lingil kliki keskmise hiirenupuga.

9. Register peab olema kasutatav kõikides levinumates moodsates brauserites. Aluseks võetakse viimased registri loomise alguses väljas olnud versioonid, v.a. Internet Explorer, mida toetatakse alates versioonist 7

On registreid mis ei tööta muu brauseriga peale IE. Olukorras, kus rohkem kui pool Eesti internetikasutajatest ei kasuta Internet Explorerit, on see olukord absurdne. Kõik riigilehed peavad töötama hoolimata brauserite spetsiifikast. Lehe loomisel tuleb aluseks võtta loomise alguses väljas olnud versioonid levinumatest brauseritest (hetkel Firefox, Chrome, Safari, Opera), välja arvatud Internet Explorer, mida peab kahjuks toetama alates versioonist 7. IE6 tugi vajalik ei ole, mitte kusagil ja mitte kunagi.

10. Register peab olema tavakoormuse juures kasutatava kiirusega. Kui välja arvata andmebaasist päringute sooritamise aeg, siis peab veebiserver saatma vastuse vähem kui sekundi jooksul, hoolimata sellest kas antud kasutaja sessioon on olemas või ei

Register peab olema tavakasutajale normaalse veebilehe kiirusega.

Kui öösel avanevad Keskkonnaregistri detailinfo lehed kolmkümmend sekundit, siis on midagi radikaalselt valesti tehtud. Ega otsingu puhul ei ootagi registrist Google kiirust, kuid kui ühe andmebaasipäringu (detailinfo reeglina seda on) tegemise ja kasutajale tagastamise peale kulub alati kolmkümmend sekundit või enam, siis kusagil on midagi mäda.

Asja trivialiseerides – kui ma oma shared hostingus olevas inglise-eesti sõnastikus suudan teha wildcard-otsingu ~190 000 sissekandest 0.1 sekundiga, siis eraldi andmebaasi- ja veebiserveriga register peaks olema võimeline tegema paari sekundi jooksul otsingu veidi keerukamas andmebaasis, milles on sageli kordades vähem sissekandeid.

11. Kõik lehed peavad valideeruma W3C HTML-validaatoris ilma vigadeta. CSS’i valideerimisel on lubatud brauserispetsiifikast tulenevad vead

Samuti iseenesest mõistetav. Pole vist ühtegi registrit, mis saaks vähem kui viiskümmend viga W3C validaatoris, osad neist küll triviaalsed, kuid osad on olulised, renderdusvigu põhjustavad probleemid. Halvematel juhtudel on vigasid sadades.

Ideaalis ei tohiks registri ükski lehetüüp saada muid vigu peale “there is no attribute” vigade, mida Web 2.0 ja frameworkid põhjustavad oma navigeerimis- ja muude atribuutidega.

CSS’i valideerimise puhul on lubatud brauserispetsiifikast tulenevad vead, nagu IE häkid ja filtrid, –moz ning –webkit laiendused jms. Head need ei ole, kuid ilma kahjuks ei saa.

12. AJAX’it kasutatakse ainult leheosa, mitte aga kogu lehe laadimiseks. Võimaluse korral kajastatakse JS poolt tehtud muudatused lehe aadressi ankruosas – ning leides lehe laadimisel aadressi ankruosas väärtusi, taastatakse lehel vastav seis

Mingi hobi on lükata ette poolläbipaistev layer kirjaga “Oota lehe laadumist” ning samal ajal tehes taustal kogu lehe laadimise. See on rumalus kuubis, sellisel käitumisel puudub erinevus plain old Web 1.0-navigatsiooniga. AJAX on leheosa kiireks laadimiseks, nii tehniliselt kui ka kasutajale on mugavam kogu lehe laadimisel tavaline HTTP GET-navigatsioon.

5 kommentaari »

  1. Olen suuresti nõus: nende reeglite vastu eksitakse arvestataval määral. Hüppavad lisa-aknad ja aadressi mittetoimimine on asjad, mille eest võiks programmeerijat/tellijat/disainerit oodata eraldi põrgu.

    kommentaar kirjutas Irve — 2010-07-02 @ 13:18:35 | Vasta

  2. Kohustuslik lugemine kõigile riigiregistrite tegemisega kokkupuutujatele!

    kommentaar kirjutas Marika — 2010-07-02 @ 13:59:19 | Vasta

  3. Ma lisaks veel nõude, et natukenegi turvakriitilisi asju ei lastaks tegema ühtegi algajat. 10a tööjõuturul olnud inimese kohta on juba teada kas ta on täielik imbetsill või oskab midagi teha ka.

    kommentaar kirjutas Tõnu Samuel — 2010-07-03 @ 23:21:44 | Vasta

  4. Eesti riigil on olemas IT koosvõime raamistik – http://www.riso.ee/et/koosvoime/raamistik2_0.pdf Ma ei tea, millal seda dokumenti viimati uuendati. Sedalaadi nõuded tuleks koosvõime raamistikku lisada ja kõikidel riigihangetel raamistikule viidata. Hea oleks, kui veebi tarbeks oleks näitena üks vabavaralisi komponente kasutav lahendus tehtud, mis kõikide nõuetega arvestab.

    kommentaar kirjutas Artur Novek — 2010-07-30 @ 11:19:01 | Vasta

  5. […] postiindeksi veebiteenus, sihtnumber, sihtnumbri otsing, sihtnumbri veebiteenus, SOAP Hiljutises postituses riigiregistrite kohta tõin negatiivse näitena Eesti Posti (mis küll ei ole riigiregister), kes pole suutnud aastaid […]

    Pingback-viide kirjutas Veebiteenus postiindeksite otsimiseks « …meie igapäevast IT’d anna meile igapäev… — 2010-08-17 @ 13:00:06 | Vasta


RSS feed for comments on this post. TrackBack URI

Lisa kommentaar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Muuda )

Twitter picture

You are commenting using your Twitter account. Log Out / Muuda )

Facebook photo

You are commenting using your Facebook account. Log Out / Muuda )

Google+ photo

You are commenting using your Google+ account. Log Out / Muuda )

Connecting to %s

Blog at WordPress.com.