Veebirakenduste kasutusmugavus

Kuna ise olen väga tihedalt seotud just kaartide, kaardirakenduste ja nendes kuvatava infoga, siis oskan selles valdkonnas kõige paremini rakenduste kasutatavust hinnata. 

Positiivse näitena tooksin välja kõigile tuntud Google Mapsi. Kuna mina kasutan seda peamiselt just teekonna planeerimise puhul, siis võtan siia võrdluseks kõrvale Tallinna sõiduplaanide Reisiplaneerija (http://soiduplaan.tallinn.ee ). Google Maps on selles kontekstis tükk maad kiirem, kasutajasõbralikum, ülevaatlikum ja mugavam lahendus, kui näiteks Reisplaneerija rakendus, kus pead sama tulemuse saavutamiseks rohkem samme tegema. Kasutusmugavuse kontekstis ei anna neid rakendusi isegi võrrelda. 

Ühe suure miinusena Reisiplaneerija puhul toon välja selle, et saan teekonna koostamiseks algus- ja lõpp-punktist valida ainult ühistranspordi peatuste nimesid. Kui sa asud kusagil võõras keskkonnas (nt mittetuttavas linnaosas), siis sul pole õrna aimugi seal asuvatest bussipeatuste nimedest. Sa tahaksid lihtsalt oma hetkeasukohast saada mingisse teise konkreetsesse punkti (tavaliselt mingile teisele aadressile, mitte peatusesse!). Seda võimaldab Google Maps - sa saad sisestada algus ja lõpppunkti aadressi, mitte ühistranspordi peatuse nime. Samuti on Google Mapsi puhul väga üheselt lahtrite sisse abistava teksti näol kirja pandud nii tegevus kui ka see, mida konkreetsesse lahtrisse valima/sisestama peab (joonis 1). See teeb isegi esmakasutajale puust ja punaseks selgeks, mida ta tegema peab.

Joonis 1. Teekonna otspunktide määramine Google Mapsis

Eriti just teekondade planeerimise juures on väga oluline see, et valitud teekond ja selle alternatiivid oleksid visualiseeritud. Visualiseeritud info annab teatavasti parema ülevaate. Panen võrdluseks mõlema rakenduse teekonna visualiseeringud (Joonis 2 ja 3) ning jätan siinkohal karmi kriitika kõrvale ja toon välja üldisemad puudused.

Joonis 2. Marsruudi kuvamine Reisiplaneerijas

Palju infot ei ole alati parim lahendus - Reisiplaneerija kaardil kuvatakse lisaks marsruudile ka erinevatesse peatustesse saabumise ajad ja kõikide peatuste asukohad (hallid mummud kaardil), seejuures jääb marsruudi info kohati isegi varju.  Sama suurendusastme juures on näiteks Google Mapsi kaardil ilusti näha marsruut, sellele kuluv aeg ning isegi alternatiivsed marsruudid. Tegelikult on ka Reisiplaneerija kaardil olemas alternatiivsete marsruutide kuvamise võimalus aga kuna kaardi algkuval on nii palju infot, siis on see võimalus "peidetud" rippmenüü sisse (nupp "Valik1"). 

Siinkohal olen ma enam kui kindel, et esmakasutaja seda sealt alt kindlasti valida ei oska ning nimetus

Joonis 3. Marsruudi kuvamine Google Mapsis

"Valik1" on samuti üsna ebamäärane, et sealt alt marsruuti ostida oskaks.

Google Mapsi puhul on väga mugav võimalus see, et ta säilitab viimati trükitud aadressid ning saad tihedamini külastatavaid kohti ka sildistada (nt kodu, töö jne). Selline väike nüanss säästab kõvasti trükkimisvaeva ja tõstab kasutusmugavust.

Ka visualiseeringu esteetilisuse koha pealt on kahel rakendusel suur vahe sees. Peaks isegi ütlema, et esimeses on kaart täiesti loetamatu.

Eks muidugi peab endale aru andma, et ühe rakenduse taga on suurkorporatsioon, kellel on nii ressurssi kui ka ka teadmust kasutajate kogemuste testimisel ja selle arvestamisel rakenduste arendustes. Teine rakendus on Eestis valmis tehtud ja ma olen enam kui kindel, et sellele mingit kasutatavuse testimist tehtud pole.

Kui vaadelda põhjuseid, miks Google Maps on parem kui Reisiplaneerija, siis mina järeldaksin nendest küll seda, et Reisiplaneerija puhul pole suudetud selgeks teha, mida täpselt kuvada tahetakse ja kellele see suunatud on - Reisiplaneerija, mis ei lase sul tegelikult mingit reisi ega teekonda planeerida, vaid kuvab kaardil bussi marsruute?! Või kelle või mille jaoks on vaja kaardil kuvada viimset kui ühte bussipeatuse asukohta või konkreetsesse peatusesse jõudmise aega? Tavakasutaja jaoks piisab juba sellest, kui on kuvatud kas sõidu kestvus või siis äärmisel juhul algpunktist väljumise kellaaeg ja lõpp-punkti saabumise kellaaeg. Ehk siis kui pole määratud konkreetset sihtgruppi/kasutajat, siis ei olegi võimalik arendada sellist rakendust, mis oleks kasutajasõbralik. Ükski rakendus ei saa olla multifunktsionaalne ja sealjuures iga võimaliku sihtgrupi jaoks ülimalt kasutajasõbralik. 

Arendus- ja ärimudelid

Antud nädala teemaks oli analüüsida konkreetsete projektide näitel ühte arendus- ning ühte ärimudelit.

QGIS on vabavaraline GIS (Geographic Information System) tarkvara, mis toimib GNU GPL litsentsipõhimõtete alusel. QGIS on OSGeo (Open Source Geospatial Foundation) ametlik projekt ning selle plussiks omandvaralise ESRI ArcGISi ees on just see, et see on kasutatav ka Mac OSX, Linuxi ja Unixiga operatsioonisüsteemidega. 
QGISi ärimudel põhineb annetustepõhisel skeemil - valmis on arendatud hästi toimiv vägagi funktsionaalne süsteem, mis pakub tõsist konkurentsi omandvaralisele ArcGIS-ile. Kuid selleks, et parandada rakenduse kvaliteeti, on võimalik teha annetusi. QGIS on oma veebilehel toonud välja, et saadud annetused võimaldavad neil:

• motiveerida arendajaid, et nad töötaksid spetsiifilisemate teemadega ning arendaksid uusi funkstionaalsusi; 
• rahastada arendajate kokkusaamisi - eesmärgiks oleks kaks arendajate koosolekut aastas;
• toetada täiendavat vigade testimist enne uute versioonide väljatulekut.

Arendusmudelite juures olen ise kõige enam kokku puutunud kosemudeliga ja saanud tunda/näinud selle mudeli ühte peamist puudust - jäikust. Tradistiooniline kosemudel käib siis järgmise skeemi järgi: Analüüs -> Disain -> Arendus -> Testimine -> Hooldus. Suurte avaliku sektori projektide puhul on selline mudel väga tavaline ja eks see ole ka üks põhjuseid, miks arendatavad rakendused on vigasid täis ja ei täida ettenähtud funktsionaalsusi. Siin mängib kindlasti rolli ka analüüsi jaoks sisendit andvate ja seda läbiviivate inimeste kompetentsus - kui klient ei tea täpselt, mida ta soovib või ei oska kõiki oma soove ette näha, siis ei ole selline arendusmudel soovitatav (pigem võiks valida midagi iteratiivset).

Üks konkreetne näide - umbes kolm aastat tagasi lasime arendada Statistikaameti kaardirakenduse (http://kaart.stat.ee ). Võrreldes teiste arendusprojektidega, mis meil majas tol ajal töös olid, oli kaardirakenduse ärianalüüsi pool üsna põhjalik.  Seega ei põdenud me väga seda, et peame projekti valdavalt kosemudeli põhimõttel läbima - teadsime ju täpselt, mida me saada tahame :) . Praeguseks oleme igapäevase töö käigus avastanud kõiksuguseid väikseid nüansse, mida rakendus ei tohiks üldse teha - näiteks on võimalik mingeid liugureid nihutada seal, kus neid ei tohiks saada nihutada ning neid lausa üksteise peale tõsta. Need on küll väiksed vead, mis üldist funktsionaalsust ei sega aga igapäevase kasutamise korral hakkavad ikka häirima. Aga kust oleksid pidanud mitte IT taustaga spetsialistid oskama sellist asja ette näha? Ja justnimelt siinkohal tahangi välja tuua kosemudeli jäikuse tagamaad - kasutajad saavad funktsioneeriva rakenduse kätte alles lõppfaasis, kus tavaliselt riigihangete puhul ei ole enam aega mitmekuulist testimist teha (rääkimata veel kasutatavuse testimisest!). Ja isegi kui siis selguvad mingid vead, siis olenevalt vea kriitilisusest, käkerdatakse mingi ajutine "lip-lipi ja lap-lapi peal" lahendus kokku, mis üldiselt mingi aja pärast hakkab hoopis kolmandat viga põhjustama. Ehk siis loo moraal - kasutajate kasutusharjumuste monitoorimine ja testimine on samuti väga oluline osa tarkvaraarendusest ning aitab oluliselt vähendada just selliste vigade arvu, mida rakenduste kasutajad ei oska projekti alguses uneski näha. Paraku ei mahu sellised täiendavad testimised kosemudeli alusel läbiviidava tarkvara arenduse ajakavasse.

Allikad:
http://qgis.org/en/site/

Kuidas saada häkkeriks?

Sellenädalases postituses analüüsin Eric S. Raymondi teksti "Kuidas saada häkkeriks?" Mulle on alati tundunud (ilmselt võib siin filmide mõjuvõimu süüdistada), et häkkerid on mingit sorti geeniused ja nendeks sünnitakse. Antud kirjutist lugedes jõudsin päris mitmes kohas arusaamisele, et häkkeriks on võimalik ka kujuneda. Selge on see, et mingid eeldused peavad sul ikka olema - eelkõige mõtlemisvõime, eraldi mainimist väärib ka teadlik sihikindlus ja keskendumisvõime.

Lahates loetelu, mis antud kirjutises määrab häkkerliku suhtumise, siis võib minu arust päris mitme punkti juures üldistada sellist suhtumist ka laiema grupi inimeste peale. Kas mitte kõik meist ei lahenda igapäevaselt nii tööl kui ka eraelus mingisuguseid probleeme? Need probleemid ei pruugi olla otseselt programmeerimise või IT-ga seotud aga see ei tähenda, et need on seetõttu vähemtähtsad! Kellele meist meeldiks igavaid ja tüütuid ülesandeid lahendada? Ma arvan, et see suhtumine ei ole samuti ainuomane häkkeritele. Tänapäevases üha efektiivsemas töökorralduses ei ole mõistlik ühte probleemi kaks korda lahendada. Kui keegi on antud probleemile juba lahenduse leidnud, jagatakse seda ka ju kolleegiga. Ja seda ikka seepärast, et töö saaks kiiremini ja efektiivsemalt tehtud. Ja kas mitte igas valdkonnas ei ole nii, et kompetensed, pühendunud ja rasket tööd mittepõlgavad inimesed, on väga hinnatud? Ometigi ei saa ju tõmmata võrdusmärki iga valdkonna kompetentse inimese ja häkkeri vahele! Selles järelduvalt võiks öelda, et häkkerlik suhtumine ei ole ainuomane ainult häkkeritele, vaid igale enda valdkonnas edasipüüdlevale inimesele.  

Teisest küljest seavad kirjutises välja toodud häkkerite põhiomadused ja oskused häkkeriks saamisele üsna kõrged nõuded - pead oskama vähemalt viit programmeerimiskeelt; tunned ennast, kui kala vees Unixi peal; lisaks tegeled võistluskunstiga; harrastad zeni jne jne. Neid kirjeldusi lugedes, sai üsna kiiresti selgeks, et häkkerite spetsiifiliste huvide ja laiahaardelise kompetentsi tõttu, erinevad nad tavainimesest ikka päris palju. Eks seetõttu on neil tekkinud ka enda väljakujunenud seltskond, kuhu pürgimiseks peab kõvasti vaeva nägema.

Kas mina mina tahaksin kunagi häkkeriks saada? Kindlasti tahaksin ma kunagi saavutada sellist kompetentsuse taset ning suuta lahendada probleeme mängeldes. Kes meist ei tahaks? Paraku tundub antud kirjutise põhjal mulle häkkerlus natuke liiga äärmuslikuna - peetakse igavesti püha sõda Microsofti vastu ja kohati peegeldub ka kerget üleolekut. Mitte, et ma tulihingeline Microsofti fänn oleksin, pigem kohandun vastavalt oludele ja vajadustele. Seega arvan, et minu ei oleks piisavalt äärmuslikust, et kunagi häkkeriks saada.

IT juht

Esimesena tooksin välja Karoli Hindriksi. Ta on oma ettevõtlikuse ja uute ideedega silma paistnud juba lapsepõlves, kui leiutas pehme helkuri ning hakkas ka oma õpilasfirma kaudu seda müüma. Suurema tuntuse kogus ta kindlasti MTV Eesti tegevjuhina ja sellega, et viis Eesti teismeliste bändi Bedwetters European Music Awards võiduni. Tema praeguseks tegevuseks on idufirma Jobbatical juhtimine. Jobbatical on firma, mis vahendab IT tööjõudu - ehk aitab firmadel üle maailma saada endale väljastpoolt enda riiki heade oskustega töötajaid ning ringirändamise sooviga tööotsijatel leida endale maailma eri paigust tööd. Laias laastus aitab ühildada uute kohtade avastamist ja tööelu. Kui nüüd analüüsida Karolit läbi selle, millist tüüpi juht ta võiks olla, siis meediakajastuste ja erineva info põhjal tundub, et ta täidab koguni mitu rolli - esiteks juht kui arengumootor (uutest innovaatilistest ideedest tal puudust ei ole), juht kui leader (tal on kindlasti selge pilt/visoon iga oma ettevõtmise juures, muidu ta nii kaugele poleks jõudnud) ning juht kui suhtleja (kogu tema taust ja erinevad ettevõtmised viitavad sellele). 

Teise juhi näite tooksin välismaalt ja selleks on Elon Musk. Talle on omistatud palju säravaid tiitleid - ärimagnaat, insener, leiutaja. Ta on Space X-i asutaja, tegevjuht ja tehnoloogiajuht; Tesla Motorsi kaasasutaja, tegevjuht ja tootearhitekt; SolarCity esimees ning olnud ettevõtete Zip2 ja PayPal kaasasutajaks. Musk on väga hea näide sellest, kuidas saab ärindus koostöös inseneriteadusega luua väga innovaatilisi lahendusi. Ühtlasi on ta oma kahes peamises ettevõttes lisaks tegevjuhile ka tehnoloogiajuht - ma ütleks, et see on juba juhtimise tase, olla samal ajal kursis kõikide tehnoloogiliste eripäradega ja teiselt poolt juhtida väga edukalt mõlemat firmat. Lisaks Karoli puhul välja toodud juhitüüpidele on Musk kindlasti ka tugevalt mentori tüüpi juht - väga head erialased teadmised  ja  oskus panna inimesi endaga kohati utoopilisi ettevõtmisi kaasa tegema. Väga hästi näitlikustab tema mentorlust ühe tema endise SpaceXi töötaja kirjeldus sellest, kui Falcon 1 raketi väljalend ebaõnnestus :

" .....Then he said, with as much fortitude and ferocity as he could muster after having been awake for like 20+ hours by this point that, "For my part, I will never give up and I mean never," and that if we stick with him, we will win.

I think most of us would have followed him into the gates of hell carrying suntan oil after that. It was the most impressive display of leadership that I have ever witnessed. Within moments the energy of the building went from despair and defeat to a massive buzz of determination as people began to focus on moving forward instead of looking back. " 

Kasutatud allikad:

https://et.wikipedia.org/wiki/Karoli_Hindriks

https://jobbatical.com

http://www.hdfmagazine.com/karoli-hindriks-jobbatical/

https://et.wikipedia.org/wiki/Elon_Musk

http://www.businessinsider.com/what-its-like-to-work-for-elon-musk-2014-6