Toiminnallisia Web-sovellusten prototyyppejä Tiggr:llä

Sovelluskehitysprojektissa on toivottavaa, että sovellusta prototypoidaan hyvissä ajoin jo mielellään määrittelyvaiheessa, jolloin sen toiminnasta saadaan tekstiä parempi kuva ja täten nähdään vastaavatko suunnitelmat sitä, mitä ajateltiin. Prototyyppien tekemiseen on erilaisia menetelmiä ja apuvälineitä lähtien yksinkertaisesta ”kynä ja paperi”-menetelmästä, mutta usein on toivottavaa, että tehdyt mallit ovat sähköisiä. Yksi kätevä työväline Web-sovellusten prototyyppien tekemiseen on Exadelin kehittämä Tiggr.

Tiggr on Web-pohjainen nopeaan prototypointiin tarkoitettu sovellus, jonka avulla voidaan luoda, jakaa, tehdä yhdessä ja esitellä sekä Web- että mobiilikäyttöliittymien malleja. Ideana on tarjota työvälineet interaktiivisten mallien tekemiseen sovelluksesta, jotka näyttävät ja toimivat kuten lopullinen sovellus. Käytännössä tämä toteutuu siten, että Flex-pohjaisessa sovelluksessa vedetään käyttöliittymään eri komponentteja ja kokonaisuudesta tuotetaan HTML, JavaScript ja CSS -pohjainen klikkailtava malli. Tiggr on ilmainen ja suunnitteilla on lisäksi maksullinen versio.

Tiggr:n käyttöliittymä muistuttaa perinteistä sovellusta, jossa toisella laidalla on tarjolla olevat komponentit ja toisella niiden ominaisuudet. Komponenttien siirtely ja hienosäätö on helppoa, jota ei voi esimerkiksi kuvankäsittelyohjelmalla tai vastaavalla sovelluksella tehdyistä malleista sanoa. Käytettävissä olevat komponentit pohjaavat siihen, mitä JSF:ssä ja RichFacesissa, Exadelin työstämässä Java EE -komponenttikirjastossa, on tarjolla.

En ole vielä kovin kattavasti testannut Tiggr:n ominaisuuksia, mutta toiminta vaikuttaa erittäin kätevältä ja monipuoliselta, vaikka osiltaan tarjolla olevat ovat rajattuja. Tarvittaessa malliin voi ladata omia komponenttejaan kuvina, mutta tällöin menettää niiden osalta mallin toiminnallisuus-aspektin. Tiggr:n etuna on, jos lopullisessa sovelluksessa käytetään myös RichFaces-komponentteja, jotka löytyvät jo valmiiksi. Myös mahdollisuus jakaa prototyyppien tekoa ja tuotoksia helposti muiden kanssa on suuri etu, sillä se edesauttaa eri osapuolten kommunikointia ja täten suunnittelu- ja kehitysprosessia.

Tiggr:iä kehitetään aktiivisesti eteenpäin ja tulossa on muun muassa prototyyppien annotointi, eli mahdollisuus lisätä kuvaavia tekstejä, sivupohjat ja toiminnallisen HTML-prototyypin laajentaminen. Jo nyt sovellus on hyvin käyttökelpoinen vaihtoehto enemmän tai vähemmän toiminnallisten ja lopullista tuotosta mallintavien prototyyppien tekemiseen.

Pitäisikö Web-sovelluksilla olla yhtenäinen tyyli ja logiikka?

Nykyään suuri osa sovelluksista toimii Web-selaimissa ja sovellusten osalta on havaittavissa siirtymää työpöydältä Web-sovelluksiksi, jolloin aikaisemmin suhteellisen samanlailla toimivat ja näyttävät käyttöliittymät muuttuvat monimuotoisiksi. Web-maailmassa ei ole yhtenäistä tapaa toteuttaa asioita, vaan jokainen suunnittelija tekee kuten parhaimmakseen näkee ja sovellusten ulkoasut vaihtelevat suuresti. Perinteisten työpöytäsovellusten osalta eri sovellukset toimivat suurin piirtein samoilla periaatteilla ja toimintopainikkeet sekä näyttävät samoilta että löytyvät tutuista paikoista.

Usability Post kysyykin, pitäisikö Web-sovelluksilla olla yhtenäinen käyttöliittymä, eli ulkoasu näyttäisi ja toimisi visuaalisesti samoilla periaatteilla, kuten työpöytäsovelluksissakin eri käyttöjärjestelmissä sovellukset ovat usein yhtenäisiä keskenään. Tutut toiminnot näyttäisivät samoilta eri Web-sovellusten välillä, kun nyt painikkeiden ja komponenttien ulkoasut vaihtelevat enemmän tai vähemmän eri sovellusten välillä.

On totta, että sitä toivoisi sovellusten toimivan edes suurin piirtein samoilla periaatteilla, ettei aina tarvitsisi arpoa miten asiat nyt tässä toimivatkaan, mutta yleisesti ottaen on vaikea nähdä, että eri Web-sovellukset näyttäisivät peruspiirteiltään samanlaisilta, toimisivat samalla tavalla tai käyttäisivät samoja komponentteja. Web on visuaalisesti toinen maailma verrattuna työpöytäsovelluksiin, joka myös heijastuu sovellusten toimintoihin. Webin osalta ei oikeastaan odoteta, että eri sovellukset näyttäisivät yhtenäisiltä, vaan ollaan jo totuttu, että jokaisen sovelluksen kohdalla pitää aina oppia uudestaan perustoiminnot ja logiikka. Onneksi suunnittelijat tekevät sovellukset usein helposti opittaviksi ja joissa asiat toimivat kuten niiden olettaa toimivan. Tai ainakin näin haluaisi uskoa, sillä todellisuus on välillä aivan jotain muuta.

Kun asiaa ajatellaan pienemmällä skaalalla, olisi sovelluskehittäjällä hyvä olla karkealla tasolla välineet yhtenäisen käyttöliittymän toteuttamiseksi, ainakin saman asiakkaan sovellusten osalta. Toki usein saman kehittäjän sovelluksissa toistuvat samat ratkaisut ja uudestaan käytettävät palikat, joilla yhtenäisyyttä syntyy kuin itsestään. Miksi keksiä asioita uudestaan, kun ne ovat jo kerran toteutettu, ellei asiaa keksi ”paremmin”. Suunnittelun ja ratkaisujen avuksi löytyy myös apuvälineitä, joilla visuaalista ilmettä ja sovellusmaista toimintaa voidaan tukea.

Webissä ei ole yhtä ja oikeaa tapaa toteuttaa asioita, vaan monet ratkaisut ovat yhtä hyviä. Mallia voi ottaa esimerkiksi useilta suunnittelumalli-sivustoilta kuten UI Patterns, YPatterns ja UI Pattern Factory. Lisäksi erilaiset komponenttikehykset kuten JQuery UI ja Java EE -maailmassa RichFaces ja PrimeFaces tarjoavat omia ehdotuksiaan toiminnoille. Vaihtoehtoja on monia ja lopputulos on usein eri ratkaisujen yhdistelemistä, jolloin sovellus koostuu useista erilaisista käyttöliittymäratkaisuista. Harvoin eri valmiiden ratkaisujen mallit toimivat suoraan omiin tarpeisiin nähden ja niitä joudutaan vähintäänkin visuaalisen ilmeen osalta virittelemään.

Koska Web perustuu pohjimmiltaan HTML:ään ja CSS:ään, voidaan valmiita komponentteja yleensä muokata ulkoasultaan tarpeiden mukaan ja soveltaa toisaalla havaittuja hyviä asioita. Esimerkiksi Web-sovelluksen käyttöliittymää varten voidaan soveltaa Cappucino tai Sproutcore -kehysten Creative Commons Attribution Share-alike -lisenssin alaisuudessa olevia Ace- ja Aristo-teemoja, jotka näyttävät siisteiltä ja tarjoavat yhtenäisen ulkoasun eri komponenttien välille.

Molemmat teemat näyttävät nykyaikaisilta ja niillä on enemmän yhteistä kuin eroa, jonka voi todeta lyhyestä vertailusta. Enemmän teemojen toiminnasta saa selville, kun vierailee teemojen demosivuilla. Sproutcoren Ace-teemasta on havaittavissa yhtäläisyyksiä OS X:n Aqua-teemaan ja SproutCoren kehitys onkin Applen sponsoroimaa. Cappucinon Aristo-teema ei ole niin silmiinpistävä kuin Ace, keskittyy näyttämään hyvältä sekä Windowsissa että OS X:ssä ja sopii paremmin vakavampiin sovelluksiin.

Molempien teemojen soveltuvuus omaan käyttötarkoitukseen riippuu toteutettavasta sovelluksesta, mutta niistä voi ainakin ottaa hieman mallia, miltä peruskomponentit voisivat näyttää. Cappucinon Aristo-teema on hieman helpommin otettavissa testiin ja se on saatavissa PSD -kuvina ja kolmannen osapuolen CSS 3 toteutuksena. Sproutcoren Ace-teema löytyy vastaavasti vain sprite-kuvina, joten teemaus pitää hoitaa itse loppuun, mutta se tarjoaa kattavamman valikoiman eri komponentteja ja malleja.

Ikävä tosiasia valitettavasti on, että sovelluksen ulkoasun eteen joudutaan aina askartelemaan enemmän tai vähemmän. Esimerkiksi jos sovelluksessa otetaan käyttöön jokin valmis komponentti, pitää sen ulkoasua joko muokata vastaamaan muuta sovellusta, tai käyttää valittua kirjastoa kaikilta osin jokaisen komponentin kanssa, jolloin eroavaisuuksia on mahdollisimman vähän. Valituista ratkaisuista riippuen tämä on enemmän tai vähemmän helppoa. Esimerkiksi JQuery UI:n komponenteille voi määritellä haluamansa ulkoasun kätevästi Theme Rollerin avulla, mutta vastaavasti samanlainen teemanrakentaja tarvittaisiin myös RichFaces-komponenteille, joiden teemaus on suhteellisen työlästä ja osittain arpapeliä. Muutenkin aina tuntuu, että useat valmiit ratkaisut eivät toimi kuten niiden haluaisi toimivan, eikä niitä usein voi myöskään helposti muokata riittävällä tasolla.

Kaikenkaikkiaan Web-käyttöliittymä voi näyttää upealta, jos siihen viitsii panostaa, mutta Web-sovelluksilla ei mielestäni tarvitse olla yhtenäisiä periaatteita. Web on monimuotoinen ja asiat saavat toimia, kuten ne parhaimmikseen näkee, kunhan ne silti toimivat loogisesti ja ymmärrettävästi. Toki yhtenäiset ratkaisut helpottavat käyttäjän elämää. Toisaalta Webin käyttöliittymät eivät helposti vertaudu perinteisiin työpöytäsovelluksiin, ainakaan nykyisillä teknologioilla ennen HTML5:n ja CSS 3:n yleistymistä, joten sallittakoon niille myös omat tyylinsä, kunhan ne ovat hyvällä maulla toteutettuja.

Pitääkin tässä edistää työlistalle hautautunutta tehtävää jalostaa omaa visuaalisesti yksinkertaista komponettiteemaa eteenpäin ja rakentaa vastaava teemaus myös RichFaces-komponenteille, jolloin asiakkaan sovellus saisi vielä nykyistä yhtenäisemmän ulkoasun.

HTML-teknologian hyödyntäminen Web-sovelluksen prototypoinnissa

Alkutalvi ja kevät on ollut kiireistä aikaa, mutta viimeinkin pitkäjänteinen työ tuottaa tulosta ja sain viime viikolla valmiiksi diplomityöni. Jee. Kun diplomityön aihe on ”HTML-teknologian hyödyntäminen Web-sovelluksen prototypoinnissa” (työ Lutin julkaisujärjestelmässä), voi helposti aavistella mitä työ käsittelee, eikä varmasti kovin paljon harhaan mene. Tarkemmin ottaen työ sisältää asiaa prototypoinnista hieman laajemmin sovelluskehitysprojektin kokonaisuuden näkökulmasta.

Kokonaisuutena työ pohjaa viime syksynä tekemääni kandidaatin työhön, jossa käsittelin aihetta hieman laajemmin ja pintapuolisemmin. Tuolta perustalta oli helpohkoa jatkaa diplomityössä ja kohtalaisen nopeasti se työ lopulta valmistuikin, mutta vaati useita iltoja töiden jälkeen puurtamista ja useampia viikonloppuja aherrusta. Lisäksi viimeinen viikko, kun työ oli jo saanut painoluvan ja muutamia kommentteja ohjaajilta, meni aika lailla dippaa ajatellen ja viimeistellen. Tekstin hiomista, pilkkujen viilaamista ja kirjoitusvirheiden etsimistä. Tuntui, että viimeistely, byrokratian anomusten täyttäminen ja dipan sitomoon saattaminen oli paljon raskaampaa, kuin varsinaisen työn kirjoittaminen.

Tulostuksen, sidonnan ja yliopistolle toimittamisen osalta hoiti Lappeenrantalainen Saimaprint homman hyvin kokonaispakettina. Helpotti paljon aikataulutusta, kun työtä ei tarvinnut luottaa postin harteille tai lähteä itse sitä viemään. Hinnat olivat muistaakseni: mustavalkosivu 0,1e; värisivu 0,7e; sidonta 22,5e/kirja; toimitus yliopistolle 20e; käsittely- ja postikulut jotain. Eihän toi halpaa touhua ole, mutta enemmän sitä olisi palanut rahaa ja aikaa, jos olisi etsinyt halvimman vaihtoehdon ja ajellut yhtenä päivänä vajaat 600 km:iä.

Diplomityössäni käsittelin käyttöliittymän ja sen toiminnallisuuksien prototypointia projektin eri vaiheissa. Alkuosa oli teoriaa eri menetelmistä ja teknologioista, ja käytännön osuudessa käytin mallina viime vuonna ollutta projektia, jonka aikana sovelsin eri prototypointimenetelmiä sovelluksen määrittelyssä, suunnittelussa ja toteutuksessa. Eli alkuun piirtelin paperille hahmotelmia miltä sovellus voisi näyttää ja myöhemmin toteutin käyttöliittymästä mallin HTML:llä. Ihan opettavainen projekti kaikin puolin, jossa myös käytettiin itselleni uusia JSF-teknologioita.

Oikeastaan pitää kiittää tutkintorakenneuudistusta, joka tavallaan pakotti valmistumaan ”Wanha tutkinto valmiiksi” -aikataulussa, johon nähden sain kaiken valmiiksi hyvissä ajoin. Koska 31.7.2010 päivämäärän jälkeen voi valmistua vain uuden kaksiportaisen tutkintorakenteen mukaan ja mahdollisesti lisäkursseja suorittaen, on tänä keväänä ja kesänä erityisen paljon valmistuvia. Itsekin olen diplomityötä hautonut useamman vuoden, mutta se vain vaati kunnollisen määräajan, johon mennessä se oli saatava valmiiksi.

Hieman kiireinen aikataulu tosin vaikutti myös työn tieteelliseen laatuun, sillä näin jälkeenpäin kun työtä lueskelee ja katselee, huomaa miten aihetta olisi voinut paremmin ja kattavammin käsitellä. Etenkin käytännön osuuteen olisi voinut lisätä tarinaa prototypointiprosessista ja toteutetuista malleista. No, työ on nyt kuitenkin tehty ja vaikka kaikki tietous ei kansien väliin päätynytkään, on se korvien välissä tallessa. Lisäksi työ ei nyt mitään järisyttävän uutta asiaa tuo prototypoinnista esille, vaan karkeasti sanottuna on katsaus miksi ja miten asioita voi projektissa mallintaa. Kyllähän kaikki tietää, että kynällä ja paperilla on helppo piirrellä kuvia sovelluksesta ja HTML:llä saa paljon aikaan nopeasti verrattuna Java-toteutukseen.

Kandidaatintyöni tapaan kirjoitin myös diplomityön LaTeXilla ja kirjoitusprosessiin soveltuu samat sanat kuin kesälläkin:

Vaikka aivan mutkatonta ei työskentely ollutkaan, oli kirjoittaminen helppoa ja muotoiluihin ei tarvinnut erikseen panostaa. Etenkin viitteiden ja viittausten hallinta oli erittäin kätevää BibTeX:llä: valmiit viitetiedot sai suoraan liitettyä muun muassa ACM:stä ja IEEE Xploresta. Vastaavasti oikoluvun puute teetti hieman lisätyötä ja taulukoiden, sekä kuvien joustava sijainti tekstin seassa hieman ärsytti.

Oikeastaan oli kohtalaisen turhaa kirjoittaa työ LaTeXilla, kun työssä ei kaavoja ollut, mutta kun kerran alkuun oli päästy, niin pitäähän se loppuun asti vängätä. LaTeX-mallipohjaa piti vielä hieman jalostaa muun muassa viiteluettelon, tiivistelmän ja nimiölehden osalta ja pitää siitä julkaistava versio jossain vaiheessa muistaa kasata. Kaikkien kuvien sijoittelu, oikoluku ja työvaiheessa kommentointi ja merkintä olisivat olleet paljon helpompia esimerkiksi Wordilla. Tosin nyt LaTex mahdollisti versionhallinnan ja kirjoittamisen riippumatta käytettävästä koneesta.

Diplomityön valmistuminen päättää myös yhden aikakauden elämässäni. Opiskeluaika on ihmisen elämään suuresti vaikuttava ajanjakso ja ainakin itsellä se tarjosi mukavia hetkiä, uusia ystäviä ja tietenkin paljon uuden oppimista. Hieman ikävä totuus kuitenkin on, että kaikki loppuu aikanaan ja on aika suunnata kohti uusia haasteita. Eiköhän se yhdeksän vuotta opiskelijana ole riittävästi, josta tosin vuosi aikalailla tyhjäkäynnillä ja pari vuotta töissä. Melkein varmaa kuitenkin on, että opiskelut eivät tähän jää, sillä elämä on jatkuvaa uuden oppimista.

Vielä tosin on edessä kypsyysnäytteen kirjoittaminen ja diplomityöesitelmän pitäminen, mutta kunhan työ arvostellaan 5.5.2010 ja saan paperit kouraan 28.5.2010, ovat opiskelut tältä erää paketissa. Paljon se vaati, mutta paljon se antoikin.

Lisäys: 18.7.2010:
Loppujen lopuksi työni sisälsi 65 sivua, 15 kuvaa, 3 taulukkoa, 43 viitettä ja 0 liitettä. Eli kohtalaisen tiivis katsaus aiheeseen, mutta ilmeisen onnistunut, ainakin työn tarkastajien mielestä, sillä arvosanaksi muodostui kiitettävä (5). Työn lausunnossa kehuttiin sujuvaa näkökulman vaihtoa prototypoinnista web-sovelluksiin ja itse toteutettuun sovelluksen prototypointiin, työn tasapuolisuutta, johdonmukaisesti etenevää kokonaisuutta ja mallikasta lähdekirjallisuutta ja sen käyttöä. Arvostelun osa-alueet muodostuivat seuraavasti:

  • Työn tulokset: 5
  • Tekijän itsenäisyys, omintakeisuus ja aikataulun hallinta: 5
  • Esityksen johdonmukaisuus ja huolellisuus: 4
  • Kieliasu: 5
  • Kirjallisuuden valinta ja käyttö: 4

Autobarin juoma-automaatti ja mahdoton peruutus

Useissa yrityksissä on työntekijöiden päivittäinen kofeiiniannos ulkoistettu Autobarin kuumajuoma-automaateille, joista saa erilaisia juomia kahvikkeen lisäksi. Kahviahan ei kyseisestä laitteesta saa, sillä kahvikuppiin saatava juoma on yleensä maultaan aika kaukana kahvista. Juomien tilaus hoituu nestekidenäytöllä ja painikenapeilla varustetun käyttöliittymän kautta ihan näpsäkästi. Vaikka käyttöliittymän tekstejä on mahdollista muokata, olisi oletuksena olevia tekstejä voinut hieman miettiä.

En oikein ymmärrä, mitä varten kahvikkeen valmistumisen ja sen kuppiin lorauttamisen jälkeen, on vielä mahdollisuus peruuttaa toiminto. Ei kahvia enää kupista takaisin laitteeseen imetä, vaikka peruuta-nappia painaisikin. Peruuta-napista pääsee vain takaisin päävalikkoon ja kahvi on edelleen kupissa. Mielestäni kyseistä toimintonappia ei tarvittaisi ollenkaan, vaikka toiminto onkin ns. poistumistie.

Lisäksi automaatista saa kahvikupin vakiona vain puolilleen, eikä vastajauhetuista pavuista suodatettu kahvi ole sen parempaa.

Autobar

Kuvakkeiden vertauskuvat sovelluksissa: WordPress

WordPressin seuraavaa 2.7 versiota varten on käyttäjiltä pyydetty muutamaan otteeseen kommentteja ja arvioita, mihin suuntaa WordPressin hallintapaneelia pitäisi kehittää. Äskettäin kysyttiin mielipiteitä erilaisista kuvakkeista, joita tuleva versio mahdollisesti käyttäisi. Vertaillessa useita hieman erilaisia vaihtoehtoja samalle toiminnolle, huomasi helposti, miten eri kuvakkeet toimivat paremmin kuin toiset kuvaamaan tiettyä toimintoa.

Kojelauta (dashboard) -kuvaketta hahmoteltiin tutuilla ideoilla: talo, mittaristo, sivu. Itse pidin eniten ”talo”-metaforasta, joka siis viittaa kotiin. Kojelauta on WordPressin hallintapaneelissa saman arvoinen, kuin muun muassa web-selaimista löytyvän ”talo”-kuvakkeen idea.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Kirjoitukset (posts) -kuvake tarjosi aika tuttuja ideoita: taulunasta, muistilappu, kappalemerkki. ”Neliön sisällä oleva kappale-merkki” -kuvake lämmitti teknistä ajatusmaailmaani, mutta muistilaput ja taulunasta ovat kyllä selkeämpiä.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Mediaan (media) viitattiin perinteisellä kuvalla ja kameralla, mutta oivaltavin idea oli yhdistää kamera ja nuotti, joka kuvaa hyvin median monimuotoisuutta.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Linkkejä (links) kuvattiin totuttuun tyyliin ketjun linkeillä ja hieman harvemmin nähdyllä maapallolla. Sydämen muotoon yhdistetyt linkit olivat mainio idea ja viittaavat blogien keskinäiseen linkittämiseen (link love).

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Sivuja (pages) kuvaava idea ei tarjonnut juurikaan juhlimisen aihetta.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Kommentteja (comments) hahmoteltiin puhekuplien ympärille ja hyvä idea oli liittää puhekuplaan myös henkilö. Kommenttien määrän ahtaminen puhekuplan sisään ei oikein tunnu loppupeleissä hyvältä idealta.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Ulkoasu (appearance) -kuvake-ehdotelmat tarjosivat hyvin vaihtelevia ideoita. Mielestäni silmä ja pensseli olivat ovelia, mutta kameleontin ja pönttömacin ideat eivät oikein auenneet. Monitori ja kaksi ikkunaa tarjosivat tuttua ja turvallista.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Lisäosat (plugins) -kuvakkeessa näkyy hyvin englannin vaikutus ja englanninkielisenä ideana töpseli toimii hyvin. Idealtaan legopalikka toimii hieman paremmin myös muilla kielillä, mutta olettaa kaikkien tietävän, mikä legopalikka on. Kuvalistan viimeinen kuvake viitannee hieman palapeliin, jota on käytetty esimerkiksi Firefoxin laajennukset-kuvakkeena. Akkupariston ajatus jäi hieman arvoitukseksi.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Käyttäjä-tietoja (users) kuvattiin perinteisesti henkilö-kuvilla ja ilmeisesti osoitekirjan sivuna.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Työkalut (tools) viittasivat loogisesti työkaluihin. Tarjolla oli jakoavainta, työkalulaatikkoa ja jakoavainta ruuvimeisselin kanssa.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Asetukset (settings) -kuvakkeet ehdottivat erilaisia säätövipuja ja ratasta, jotka ovatkin yleisesti käytettyjä, mutta ilmeisesti tarkistuslistaa kuvaava idea jäi aika heikoksi.

wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons wordpress icons

Oivaltavia kuvakkeita WordPressin kuvakeideointiin suunnittelivat Ben Dunkle, Verena Segert, Guillaume Berry, Open Source Design class at Parson’s in New york City ja Luke Smith. Sekä yllä olevat kuvakkeet että tekijät ovat järjestetty kuvake-kokonaisuuden äänten mukaan. Dunklen ideoimat kuvakkeet saivat 35% prosenttia äänistä ja Segertin kuvakkeet saavuttivat 29% prosenttia äänistä.

Kyselyn vastaukset julkistettiin eilen ja tulokset nojaavat myös omiin mieltymyksiini. Lisäksi voittaneita ja toiseksi tulleita kuvakkeita vielä tarkennetaan kyselyn mukaisilla tuloksilla muutamien kuvakkeiden kuten ”kojelauta” ja ”työkalut” -osilta. Eri kuvakekokonaisuudet ja WordPress-tiimin kommentit löytyvät kyselyn tuloksista, joka kannattaa vilkaista.

Pienillä eroilla esimerkiksi sovelluksen kuvakkeiden valinnassa on suuri ero käyttäjien kokemassa sovelluksen selkeydessä ja käyttäjäystävällisyydessä. Valitettavan usein ne pienet mutta merkittävät asiat ovat juuri niitä asioita, joita ei aina ehditä miettiä ja suunnitella kunnolla. Tietenkin, hyvä suunnittelija tekee samalla työmäärällä hieman paremman ja tähän pitäisikin pyrkiä. Jotta hyvän lopputuloksen suunnittelu ei olisi liian helppoa, eivät asiat koskaan ole yksiselitteisiä ja ongelmaan on harvoin vain yksi oikea ratkaisu.