E-teenuste disaini käsiraamat
-
TiinaR 10 a
Peatselt valmiv „Kasutajasõbralike e-teenuste disainimise käsiraamat avalikule sektorile" ootab asjatundjatelt arvamusi ja ettepanekuid. Rohkem infot ja käsiraamatu tekst on kättesaadaval: https://www.ria.ee/ootame-arvamusi-e-teenuste-kasiraamatu-kohta/
15. jaanuar 2014 - 09:24:09 · Otselink
-
tajo 10 a
Ainult üks küsimus — miks ei võiks e-teenuste käsiraamat olla kergesti otsitav, lingitav ja uuendatav veebileht?
15. jaanuar 2014 - 09:43:48 · Otselink
-
TiinaR 10 a
Hetkel on see käsiraamat ka siin üleval: https://docs.google.com/file/d/0BxdzgbZVu-v7TGlramlieVdHdWs/edit
15. jaanuar 2014 - 09:53:29 · Otselink
-
vaalaskala 10 a
Võtkem kohe mõistete leht :) silm läks särama lugedes mõistet "Agiilne arendusmeetod" , kahjuks on mõistete leht ainus koht mis seda arendusmeetodit seal mainib, ülejäänud sisu tundub pigem waterfalli järgi paika pandud. Täna käib tarkvaraarendus ikkagi rohkem agiilset rada, kui midagi muud. Ja sellesuhtes läheb see kõik kokku järgmise lõiguga:
Kasutajasõbralikkuse tagamiseks peaks avalik sektor siiski vältima uusimaid
veebilahendusi, vaid kasutama neid, mis on juba mõned aastad kasutusel olnud ning
üldsusele tuttavad.Selles lõigus on konkreetselt segamini aetud mõisted veebilahendus ja tehnoloogia.
Loen hiljem põhjalikumalt, aga hetkel tundub, et see on natuke kaldu ühe kindla protsessi ja mudeli kajastamisele ja üsna pealiskaudne. Välja on jäänud kõige olulisem asi e-lahenduste puhul: testimise mõiste , tagasisde mõiste mis on seal kummaliselt paigutatud ärianalüütiku ja disaineri pädevusse jne.
Parima tulemuse saavutamiseks on oluline pidada iganädalaseid kohtumisi, kus
kogutakse tagasisidet valminud lahendusele.See ilmestab ilusti avaliku ja erasektori suunitlust kus kõik on tagurpidi. Minu arvates on see just põhjus miks riik on rahvast kaugel :) Oluline oleks aru saada, et neid e-lahendusi ei tehta ametnike ja disainerite jaoks vaid ikkagi rahva või ärisektori teenindamise jaoks ja tagasiside peaks tulema just sealt kus seda kõige rohkem kasutatakse. Selle juhendi järgi juhtub konkreetselt nii, et: planeerime, teeme, las rahvas kasutab ja pärast teeme koosoleku, et mida rahva jaoks muuta kuna "valmis" faasis saabuv tagasisde lõppkasutajalt ei ole alati kõige lillelisem ja reaalne realiseerida.
pixli seltskond võiks siinkohal välja tuua linke raamatutele mis on täna maailma arendusprotsesse defineerimas. Juhend on hea, aga sellisel kallutatud kujul on ta liiga "sööme sülti ka jaanipäeval" tüüpi ja võiks olla pigem erinevaid metoodikaid ja standardeid tutvustav mitte ühte võimalikk meetodit tutvustav. Poleks paha kulutada raha just valdkonna kirkamate teoste tõlkimisele või vähemalt nendele viitamisele.
15. jaanuar 2014 - 10:17:48 · Otselink
-
Lars 10 a
Väga nõus, et kuiva lugemise asemel oleks oluline ja vajalik luua pidevalt arenev "knowledge base", kus teemaga igapäevaselt tegelevad inimesed saaks anda pidevalt kvaliteetset sisendit.
Mis puudutab sisu, siis kohati jääb mulje, et tegemist on meelega võimalikult pikaks kirjutatud Maanteaameti projekti(de) case study'ga - dokument võiks olla käsitleda Maanteeameti septsiifilisi ärireegleeid ja nende täpset juurutamist oluliselt väiksemas detailsuses ja teha pigem üldistavaid järeldusi. Ja neid järeldusi-näiteid võiks sekka ka mujalt koguda.
Võimalik, et kirjatöö pikkuse tõttu lk 136'ni, kus jälle põnevaks läheb, paljud oma lugemisega ei jõuagi.
Eessõnas viidatakse korduvalt autoritele ja autori kogemusele, aga silma jääb, et teksti on loonud keegi OÜ Ziraff. Tore oleks ka autori nime kaanel lugeda, kuigi seda googledades muidugi raske leida ei ole.
Aga kokkuvõttes on enamus teksti asjatundlik, keeleliselt tasemel, ilusti vormistatud ja asjas vähem sees olijatele kindlasti hariv lugemune. Edu!
15. jaanuar 2014 - 11:46:27 · Otselink
-
Scooter 10 a
15. jaanuar 2014 - 22:41:35 · Otselink
-
kaups 10 a
Wiki soft + kena theme peale?
16. jaanuar 2014 - 10:51:03 · Otselink
-
Silverionu 10 a
Arvestades kui kiiresti e-teenuste maailm muutub, ei julgeks ma sisse kirjutada sellist suhteliselt jäika terminit nagu "mõned aastad kasutuses olnud".
CSS mõiste selgitus on puudulik, CSS abil määratakse tänapäeval ka lehekülje väljatrüki stillid, mitte ainult kuvaril näitamise stiilid. Kui eriti nokkida, siis kas tõepoolest on ühe CSS failiga võimalik määrata stiilid vaid sadadele lehtedele? Pigem ikka piiramatule arvule :)
"Kvalitatiivse kasutajauuringu" selgitus on juba klass kõrgem koomika. Milleks nii täpne meetodikirjeldus, mis on ühtlasi ka väär ja kitsendab mõistet oluliselt? Müstika.
16. jaanuar 2014 - 11:09:40 · Otselink
-
lemps 10 a
Väga tänuväärt tegevus. Aga esimene mõte mis kargas pähe kui seda dokumenti sirvisin, on selle reaalne rakendamine. Kipun arvama, et kasutaja kes seda dokuenti loeb, kaotab päris kiirelt järje kui ta üritab rakendada protsessi mingis projektis.
Oleks abiks, kui teha visuaalne protsessikirjeldus koos olulisemate punktidega. Nagu ka dokumendis sees kohati näha on aga ülevaatlikum, mis võtaks teema kokku ning annaks kätte pidepunktid, et siis vajaldusel mingi osa kohta edasi uurida.
16. jaanuar 2014 - 11:25:03 · Otselink
-
tajo 10 a
Muide, kui keegi otsib väga huvitavat eeskuju mujalt maailmast, siis Ühendkuningriikides tehakse juba jupp aega väga põnevat tööd: https://www.gov.uk/government/publications/government-digital-strategy ja https://gds.blog.gov.uk/
16. jaanuar 2014 - 16:46:35 · Otselink
-
Margus Simson 10 a
Tere
Märkasin, et siia on hakanud kogunema kommentaare käsiraamatu kohta ja käsiraamatu ühe peamise autori ja Ziraffi eestvedajana hea meelega vastan neile :) Igasugune tagasiside tervikuna on oodatud. Päriselt ka :)
Kõigepealt - käsiraamatut lugedes palun arvestage, et tegemist on avalikule sektorile suunatud käsiraamatuga. Erasektoris käib rida asju teistmoodi, seda nii rõhuasetuse, töökorralduse kui põhimõtete osas. Nt viidatud waterfall vs agiilne - enamuse projektidest oma elus olen teinud agiilselt, kuid avaliku sektori hangete süsteem ning juba ette väga täpne tehtavate tööde fikseerimine ei võimalda sarnast meetodit lõpuni avalikus sektoris kasutada. Riigihangete seadusega vastuollu ei saa ega taha keegi minna. Proovisime ka sellesse skeemi paindlikkust rohkem sisse kirjutada, aga praeguses seisus on see piir :)
Teine suur erinevus mitmete erasektori projektidega võrreldes on otsustusskeem. Avalikus sektoris on tunduvalt rohkem osapooli, kellega tuleb muudatused läbi arutada ning kooskõlastada. See omakorda tähendab veel vähem agiilset arendust – kogu projekt kulgeks hoopis teistmoodi, kui oleks võimalik väikese agiilse grupiga süstemaatiliselt ja kiirelt otsuseid tehes edasi liikuda. Mida rohkem kooskõlastajaid, seda aeglasem süsteem.
Kolmas suurem erinevus ei ole niivõrd avalik vs erasektor, vaid väike vs keskmine vs suurorganisatsioon. Suurem osa riigiameteid on majasiseste protsesside poolest suurorganisatsioonid. Omades 15 aastat kogemust suurtes organisatsioonides internetikeskkondade arendamisel, siis ma ei tekitanud ka käsiraamatus illusiooni, et tööd võiksid liikuda väikese organisatsiooni mudeli järgi. Suur organisatsioon tähendab: teadmised on väga paljude inimeste peades laiali ja inimesi tuleb palju kaasata; kohtumised on tavalised suured, tüüpiliselt 8-12 osapoolega; osapoolte suur arv väljendub arvamuste paljususes; lisaks arvamuste paljususele keskenduvad kõik osapooled vaid enda valdkonna huvidele, inimesi, kes hoiaksid pildis kogu organisatsiooni huve, sisuliselt ei ole; struktuuris asetsevad inimesed nii, et ühelgi koosolekul ei ole tüüpiliselt eriarvamuste korral kellelgi veto- ega otsustusõigust; inimeste kalendrid on väga tihedalt täis ning 8-12 inimese kokkusaamine on juba omaette peavalu.
Nende nüanssidega järgi on see käsiraamat üles ehitatud ning nendega palun lugedes ka arvestada.
17. jaanuar 2014 - 13:32:21 · Otselink
-
Margus Simson 10 a
Kommentaaril kommentaari kirjutamise lahter on siin väga nappide tähemärkide arvuga, seega jätkan siinsamas.
tajo: käsiraamat on dokument seepärast, et vastav riigihange eeldas vähemalt dokumendi sündi. Mis puudutab mitmes kommentaaris käsitletud eraldiseisva keskkonna teket, siis Ziraff tegelikult on täna oma kodulehe valmimise raames üles ehitamas eraldiseisvat kompetentsikeskust, kuhu kogume kogu UX loomise teadmise kokku (mitte ainult avalik sektor, vaid peamiselt erasektor, sest seal on meie teadmised ka tugevaimad). Keskkond tuleb küll ainult inglisekeelne, sest meie fookus on peamiselt eksportturg, aga loodan, et Eesti kasutajad saavad inglise keelega hästi hakkama. Kompetentsikeskus saab olema sisuliselt struktureeritud blogikannete/artiklite kogu.
Sellesse keskkonda koostame praegu ise materjale, kuid pärast lansseerimist on kindlasti ka kaastöö igati oodatud. Kui juba täna keegi tunneb, et soovib meiega kaasa lüüa keskkonna loomisel, siis andke palun mulle märku.17. jaanuar 2014 - 13:43:14 · Otselink
-
Margus Simson 10 a
Vaalaskala ja silverionu: Käsiraamat ei ole tegelikult mitte veebidisaini käsiraamat, vaid teenuse disaini käsiraamat. Teenuse disainist moodustab väga suure osa pigem organisatsiooni äriprotsesside ümberkujundamine, ettevõtte või asutuse tegevusstrateegia täiendamine, äritehnoloogiline ülesehitus jms. Sinna kulus meie disainiprotsessist umbes 75% ja veebi enda peale 25% ajast. See on täiesti tavapärane ja loomulik - näiteks on meie kogemusepagasis ühe väga olulise teenuse protsessi ülesehitamine, kus disainitööd olid reaalselt mõned nädalad, kuid protsessi ja teenuse ülesehitamist/disainimist 6 kuud. Neid kahte protsessi on tegelikult raske eristada.
See ongi üks asi, mida käsiraamat tahab kindlasti rõhutada - hea e-teenuse loomine ei tähenda seda, et sa võtad koleda protsessi ja teed sellele ilusa katte. Hea user experience'iga e-teenus sünnib meie hinnangul vaid juhul, kui teenus selle veebisaidi all saab korda. Ja just see valdkond on väga suurel määral avalikus sektoris ja keskmisel määral erasektoris ignoreeritud, selle asemel tellitakse jätkuvalt lihtsalt ilusat pilti ning jäetakse täies mahus tegemata teenuse äritehnoloogiline ehk disainimise faas.
Silverionu kommentaari põhjal üritame seda testimisosa selgemaks kirjutada, sest tahtsime selles punktis just seda selgitada, et teenuste (mitte veebi-)disainiprotsessis on äärmiselt olulisel kohal just kvalitatiivuuringu käigus saadav tagasiside. See on meie 15 aasta praktikas ennast selgelt tõestanud meetod - kuigi ka veebidisainiliste detailide lihvimisele tuleb tähelepanu pöörata, on selle asemel äärmiselt tähtis just kasutaja poolt kogu teenuse kui terviku mõistmine. See on see, mida tuleb testida. Ja seda ilma süvaintervjuusid läbiviimata kahjuks läbi viia ei saa.
17. jaanuar 2014 - 14:03:55 · Otselink
-
Margus Simson 10 a
Mõistete osa - mõisted arvestavad sellega, et raamatu lugeja on kasutaja, kes ei ole veebitehnoloog. See tähendab, et kui täpne mõiste selgitus jääb lugejale tehniliselt arusaamatuks, siis oleme üritanud kirjutada seda lihtsamalt (ja seetõttu paratamatult ebatäpsemalt) lahti. Vaatame selle osa siiski kindlasti veel korra üle, et proovida leida veel paremat tasakaalu arusaadavuse ja täpsuse vahel.
17. jaanuar 2014 - 14:08:32 · Otselink
-
Margus Simson 10 a
Lars: käsiraamat ei ole meelega pikaks kirjutatud. Meie ettepanek oli kogu Maanteeameti osa jätta eraldi lisasse, kuid kokkuleppel tellijaga kirjutasime selle siiski põhiraamatusse sisse. Antud osa läks mahukaks eelkõige seepärast, et tehtud töö lihtsalt hõlmas palju enam erinevaid vaateid kui algselt plaanitud.
Ziraffi koduleht saab valmis lähikuudel, oleme eraldi ettevõttena toimetanud pigem veel vähem aega. Samas meie kogemused - ettevõtte võtmeisikud on strrateegiliselt, disainiliselt, infoarhitektuuri jms mõttes ehitanud üles kogu Eesti Energia ja Elektrilevi lahenduse, Swedbanki internetikanalite lahendusi, SEB e-kanaleid. Oleme koostanud Riigikogu varsti valmiva veebi strateegia ja infoarhitektuuri, Valitsusportaalis olnud strateegiline partner ja disainipartner, täna oleme Eesti Posti UX ja disainipartner, lisaks siis oleme üles ehitanud Maanteeameti uue iseteeninduse disaini ja valmivad e-teenused. Teatud osad on meie tehtud Amservi veebis, internetistrateegiaid oleme välja töötanud veel reas olulise mõjuga ettevõtetest.
Ziraff on ettevõte, kes eelkõige keskendub tervikliku kasutajakogemuse arendamisele, mis hõlmab endas nii internetistrateegia koostamist, protsesside ümberdisainimist, veebidisaini, infoarhitektuuri kui vajadusel kogu tervikprojekti elluviimist. Me oleme nn tellija e-kanalite osakonna tugevdamise ettevõte, kes tüüpiliselt on tellijaks veebidisaineritele, tarkvaraarendajatele jt.
17. jaanuar 2014 - 14:27:53 · Otselink
-
vaalaskala 10 a
Mõistete osa - mõisted arvestavad sellega, et raamatu lugeja on kasutaja, kes ei ole veebitehnoloog. See tähendab, et kui täpne mõiste selgitus jääb lugejale tehniliselt arusaamatuks, siis oleme üritanud kirjutada seda lihtsamalt (ja seetõttu paratamatult ebatäpsemalt) lahti.
Mõtlete uusi mõisteid välja ja seesama inimene kes ei ole veebitehnoloog peab ju teenuse paremaks tegemiseks paratamatult valdkonna mõistetega tutuvuma muidu ta lihtsalt ei saa aru mida ta arendab, ostab, ehitab või mille eest vastutab, ka suhtlus partneritega näeb naeruväärne välja. Kujuta nüüd ette, et seesama ametnik läheb kuskile konverentsile ja hakkab rääkima "internet first" , see on ju paras naerukoht.
Esiteks juba sellest, et internet iseenesest ei ole ju teenuse tehnilise toimimise osas kriitiline tegur vaid pigem ikka e-teenuse arhitektuur ja kogu teenuse mudel mis võimaldab teenust võrgu (ja võrk ei pruugi olla ju ainult intenret jne) kaudu edasta (ehk API mille kaudu teenust kasutada saab).
Kuna sul on tegu juhendiga, siis olgu era või avalik sektor, kasuta ikka valdkonna mõisteid . Viited wikipeediasse või materjalidele kus mõisted defineeritakse võiks olla elementaarsed., sest ka autori teadmised ei teki õhust (va väljamõeldud mõisted) . Ei saa eeldada, et juhendit lugev inimene oleks juhm ja viitamine lisamaterjalidele aitab sageli inimesel asju mõista nii nagu valdkonda edendav kogukond seda näeb.
Minu arvamus on , et see juhend võiks ikkagi anda ülevaate valdkonna mõistetest mitte uusi mõisteid looma ja alahindama (ei ole veebitehnoloog jne nagu ei suudakski millestki aru saada) inimesi kellele see juhend on suunatud. Lisaks veel domineeriv kasutuslugu ja ekraanilaksud mis ei iseloomusta protsessi vaid kirjeldab konkreetset lahendust ilma kasutajatestideta (et üldse väita, et oleks parem või hea peaks seda ju millegi suhtes mõdetavalt võrdlema, mõõtmistulemusi ei kirjeldata) ei peaks olma juhendi osa vaid lisamaterjal (sest neid kasutusanalüüse vms võib ju olla mitmeid või tekkida aja jooksul juurde jne) . See aitaks juhendi hoida juhendi mõõdus ja fookus ei kaoks ära.
Aga nagu valmis asjadega ikka :) ega sa ju midagi muutma selles juhendis enam ei hakka (waterfall) siis pole ju eriti mõtet ka edasi apelleerida või tagasisidet küsida :) ja tulemuseks see ongi see tagurpidi riik milles sa elad :)
17. jaanuar 2014 - 14:48:46 · Otselink
-
Margus Simson 10 a
Teatud hulk mõisteid on paratamatult uued, me liigume iseteeninduste/e-teenuste arendamisel radu pidi, mida maailmas on käsitlenud vähesed ettevõtted. Internet first kontseptist olen ise kõnelnud paljudel maailma konverentsidel ning siiani ei ole selle üle keegi naernud.
Pigem näen ma täna turu probleemina nii seda, et tellija ei oska sõnastada arendajatele, mida ta tahab, kuid samas väga paljud arendajad ei vaevu süüvima tellija tegelikesse ärilistesse vajadustesse. Nii istuvadki tellija ühel poolel ja täitja (disainiagentuur, tarkvaraarendaja) teisel pool ning kiruvad teineteist. Ühise keele puudumine on täna selgelt mõlema osapoole probleem. Ma olen olnud 14 aastat suurtellija Eesti turul ja sisuliselt on mul väga raske olnud leida partnereid, kes päriselt ka tahaks minuga lahenduste leidmisel kaasa mõelda. Pigem valdab suhtumine - anna mulle täpselt ette, mida ma tegema pean...
Jah, ma tean, et meie käsiraamat toob sisse traditsioonilisega võrreldes teistsugust lähenemist ning teistsuguseid termineid, aga e-teenuste kasutajakogemuse arendamise maailm ongi lihtsalt väga suures osas teistsugune maailm võrreldes kodulehtede ning väiksemate funktsionaalsuste arendamisega. Selles maailmas mängib üle kõige rolli äristrateegia mõistmine, internetistrateegia olemasolu, teenuste osutamise protsessi ümberkujundamine, keskkonna infoarhitektuur, kompromiss IT, äri ja disaini vahel. Kõik see, mis üht kodulehte ehitades ei ole nii mission-critical. Sait 1000 lehega vajab hoopis teistsugust lähenemist kui 20 lehega sait. Funktsionaalsusi ülesehitades on vaja kasutaja vajadus siduda infosüsteemi võimekusega, et korraga peale tulevad tuhanded kasutajad ei jookseks saiti pikali, aga samas saaksid kõik vajaliku kätte. Selliste teenuste arendus maksab sadu tuhandeid või miljoneid ning seda raha ei eraldata ühelgi muul juhul, kui vaid siis, kui see tabab äristrateegias kümnesse. Suurem osa ettevõtete teenustest on masendavalt keerulised ning inimesed majas seeski ei saa aru nende ülesehitusest, rääkimata kliendist. Kompromiss ja tasakaal IT, äri ja kasutaja vahel, see on e-teenuste arendamise olulisim tõde.
17. jaanuar 2014 - 18:14:22 · Otselink
-
vaalaskala 10 a
Jah, ma tean, et meie käsiraamat toob sisse traditsioonilisega võrreldes teistsugust lähenemist ning teistsuguseid termineid, aga e-teenuste kasutajakogemuse arendamise maailm ongi lihtsalt väga suures osas teistsugune maailm võrreldes kodulehtede ning väiksemate funktsionaalsuste arendamisega.
Ma ei näinud seal juhendis midagi sellist (just protsesse ja metoodikat puudutavat) mida ma ei ole näinud juba aastal 2000 va korra mainitud mõiste agiilne arendusmeetod. Sellesuhtes läheb see hästi kokku selle soovitusega kasutada järgiproovitud meetodeid ja mitte kõike uut ja uusimat. Ja ka probleem tellija ja arendaja mõttekaugusest ei ole ju uus ja ei ole ka ainult IT valdkonnale iseloomulik vaid nii on see pea igas valdkonnas ja erinevatel tasemetel.
Ma saan su entusiasmist väga hästi aru ega kritiseerigi seda vaid kommentaarid siin puudutavad otseselt juhendit (mitte autorit) mis on üsna pealiskaudne (või lihtsustatud nagu sa väidad) ja ei järgi traditsioonilist õppematerjal/juhend/publikatsioon ülesehitust ega vormi. Puuduvad viited ja asjad mida on mitmed märganud ja rõhutanud ülesehituse osas (case study maht vs juhendi sisu maht).
Keegi ju ei ootagi, et selles juhendis midagi muutuks, sest keegi ei ole motiveeritud seda juhendit tõsiselt võtma ja võibolla just tema lihtsustatud kuju pärast. Reaalset tagasisdet saad eelkõige inimestelt kellele see juhend on suunatud nö need kes ei ole veebitehnoloogid. Ühist keelt suudab leida ainult väga hea motivaator, see ongi raske ja jääbki alati raskeks olenemata "misiganes" first valdkonnast. Sama ka juhenditega, sisu peab köitma.
17. jaanuar 2014 - 23:39:03 · Otselink
-
Sven S 10 a
RIA küsis tagasisidet, saatsin neile sellise kirja:
"Kasutajasõbralike e-teenuste disainimise mudel. Käsiraamat avalikule sektorile.” Autor anonüümne.
On väga tore, et heade e-teenuste disainist raamat kirjutatakse ja tellijat harida püütakse. Tõesti vahva. Tark klient on iga projekti õnnestumises üks tähtsamaid komponente. Kuid käesolev raamatukavand on ükskõik kelle harimiseks kahjuks kõlbmatu.
Põhjuseid on kaks ja esimene neist on oskamatult kirjutatud sisu. Kui raamatu kirjutamise eesmärk on, et keegi teda päriselt loeks ka, tuleb kirjutada nii, et lugeja tahaks lugeda. Aga tekst on surmigav, täis neljarealisi lauseid ja tarbetuid võõrsõnu. Raamatuga on nagu e-teenusega. Kui e-teenuse omanik tahab, et keegi vabatahtlikult seda kasutaks, tuleb teenus teha kasutajasõbralik. Kui raamatu väljaandja tahab, et seda loetaks, tuleb raamat kirjutada lugejasõbralikult. E-teenuste disain on ju tegelikult väga põnev teema, miks peaks seda nii puiselt käsitlema?
Võib palju vaielda valitud case-studyde otstarbekuse üle (valiku peamine eesmärk tundub olevat pigem tegijaid reklaamida) ja selle üle, kas kirjeldatud valikuid piisavalt põhjendatakse (peaaegu üldse mitte), aga sellele pole mõtet sõnu kulutada. On esimestest lehekülgedest selge, et raamatu autorid pole kunagi kirjutanud midagi muud peale koodi või spetsifikatsioonide. Võlaõigusseadustik on ka huvitavam lugeda kui käesolev raamat.
Lisaks ebaõnnestunud sisule on raamatul teine suur puudus – ebaõnnestunud vorm. Miks kirjutada staatilist raamatut, kui üks selle peaeesmärkidest on kirjeldada head interaktsiooni? Olukorra absurdsust näitab eriti ilmekalt asjaolu, et illustreerivad screenshotid on raamatust vormist tulenevalt staatilised. Ning tihti vähem kui veerandi suuruses originaalist. Ehk siis täiesti arusaamatud.
See raamat, kui teda hästi teha, võiks teksti ja pildi sümbioosina ise demonstreerida interaktsioonidisaini parimaid praktikaid. Vähim, mida oodata, võiks olla võrreldav möödunud aastal ilmunud kogumikuga "Arengufondi mõtteraamat” (http://motteraamat.arengufond.ee) – hästi loetav, hästi kujundatud, responsive layoutiga “veebiraamat". Parimal juhul võiks ta olla ka veel pidevalt täienev andmevara, kus diskussioonis osalevad Eesti parimad spetsialistid.
Praegune kavand, kui see peaks trükitama, on määratud jääma riiulitagustesse tolmu koguma.
Sven Sapelson,
interaktsioonidisainer.24. jaanuar 2014 - 16:17:38 · Otselink
-
leedu 10 a
Sven! Retsept!
Selle raamatu põhiprobleem on see, ta on liiga pikk .. ta peaks kirjeldama põhimõtteid ja mitte lahendusi. Näited võiks olla lingitud juurde ja need võiks pidevalt täieneda (nii halbade kui heade näidete osas).
https://www.gov.uk/design-principles
ja noh .. jutt on e-teenustest, mis saavad olla ainult nii head, kui mitte-e-teenus nende taga .. seega tundub mulle, et suuremas pildis on vale ots, kust alustada .. aga see on juba minu zajoob.
28. jaanuar 2014 - 09:21:39 · Otselink
-
Taimar 10 a
Sveni tagasiside on omal kohal, kirjutaksin ka oma nime alla.
---
Janno, jätkan ja täiendan su mõtteid, kui lubad. :)
"peaks kirjeldama põhimõtteid ja mitte lahendusi"
Just nimelt. Ja pigem üldsõnaliselt, kui spetsiifiliselt. See on ühelt poolt loetavam, paremini omaks võetav ja sihile viiv, teisalt aga tulevikukindlam ega tekita väärarusaama, et on üks maagiline ja universaalne komplekt konkreetseid lahendusi (või koguni visuaalseid võtteid), mille poole püüelda.
Näited on ilmestamiseks vajalikud, aga nagu mitmed on siin teemas juba välja toonud, on neid mõistlik hoida põhiosast lahus, eraldi vaadeldavana ja kindlasti ajas uuendatavana.
"jutt on e-teenustest, mis saavad olla ainult nii head, kui mitte-e-teenus nende taga .. seega tundub mulle, et suuremas pildis on vale ots, kust alustada"
Nõus. Päeva lõpuks ei olegi mõtet kritiseerida kivisse raiutud staatilist raamatut, kuna selline kuju on *ise* probleem. Prognoosin, et jääb tolmu koguma olenemata sisu kvaliteedist. (Mitte et madal kvaliteet oleks vabandatav.)
Seega – ühinen arvamusega, et praegune ots on alustamiseks vale. Formaat on lukku löödud enne, kui on välja selgitatud, mis on probleemile kohane, optimaalne ja töötav lahendus. (Võib-olla su mõte seal taga oli midagi muud, Janno?) See on disainiprotsessi üks tüüpivigadest: kiputakse tormama tööriistade kallale ja lahenduste poole, mitte ei esitata küsimusi ega defineerita (tarbija, mitte tellija) vajadusi. Kahju, et olukorda parandada püüdva raamatuga neid vigu samuti tehakse. Siiski on mul siiralt hea meel, et avalikult tagasisidet küsiti.
GOV.UK digitaalne strateegia ja selle põhidokument, samuti disainiprintsiibid on kuld ning toetuvad design thinking põhimõtetele. Põhjusega auhinnatud ja vääriline eeskuju (nagu Tajo ja Janno eelnevalt mainisid).
28. jaanuar 2014 - 13:56:13 · Otselink
