Use cases vs. user experience - virheitä metsästämässä

Kuten jossain vaiheessa mainitsin kehitin järjestelmää tietynlaisella sovelletulla ad-hoc xp mallilla. Ensin ideoin, sitten koodasin toiminnon. Sen jälkeen testasin sitä niin paljon kun viitsin, pystyin ja jaksoin. Ja sitten vain koodi käyttöön.

Mikä tässä tavassa on hyvää:

1. Toimivaa koodia valmistuu koko ajan. Tämä mahdollistaa sen, että sovellusta voi kehittää omassa tahdissa. Tunti silloin tällöin toi aina uusia toiminnallisuuksia.
2. Perus "use case" tuli testattua aika hyvin. Eli toiminnallisuus teki juuri sen mitä sen oli tarkoituskin.
3. Motivaatio pysyi korkealla, kun näki käden jäljen koko ajan.
   

Kehitysmetodologiaa valittaessa arvioi omat mahdollisuutesi reagoida virheisiin ja syntyvän riskin tasosta. Jos teet sovellusta itsellesi, voit varmasti ottaa riskejäkin vapaammin.

Mikäs sitten oli huonoa:

1. Testaus oli/on ehdottoman vajavaista [tästä lisää myöhemmin]. Kuten sanottu, suurin osa testauksesta kohdistui juuri tuohon perus toimintaan. Mutta raja-arvoja ja virhetilanteita ei juurikaan tullut testattua. Tämä sopi hyvin tähän vaiheeseen ohjelmointia, missä prioriteetti oli saada toimivaa softaa ulos mahdollisimman pian.
2. Virheitä alkoi löytymään. Tämä on tietenkin seurausta vajavaisesta suunnittelusta ja puutteellisesta testaamisesta.
   

Se onko tämä ongelma riippuu sinusta, ja palvelun suosiosta. Jos pystyt reagoimaan virheisiin nopeasti, ei todellisia ongelmia pääse syntymään. Ja jos palvelu on vielä alkutaipaleella, ei imagollisia tappioitakaan juuri tule. Tämä on haastajan / pienen palvelun etuoikeus.

www.mutteri.com:in tapauksessa olin varautunut siihen, että lopullinen käyttötestaus tapahtuu vasta oikeilla käyttäjillä. Minä en ollut perehtynyt varsinaisesti testaamiseen, testausmetodologioihin tai testaustyökaluihin. Luotin siihen, että pieni tuntematon palvelu, jolla ei vielä ole hävittävää, saa paljon anteeksi.

Ensimmäiset parannukset: title-tag

Käyttötilastoja selatessani huomasin, että tilastoissa välkkyvät kryptiset URL:it eivät ole kovin helposti luettavia. Mistä ihmeestä minä muistaisin mikä "nimike" on label_id=22. Tämä on tärkeä huomio jos haluat että hakukoneet löytävät sivusi ja tulkitsevat ne oikein. Ei se ole hakukoneenkan helppoa tulkita ja pisteyttää sivuasi jos sieltä ei löydy kuvaavia tietoja.

Analytics työkalussa oli raportteja jotka olisivat pystyneet näyttää sivuvierailuja käyttäen html:n "title" -tagiä. Ensimmäisen vaiheen versiossa kaikilla sivuilla oli sama "title" tagi, joten tämä raportti oli käyttökelvoton.

HTML:n "title" -tag on erinomaisen tärkeä hakukoneille. Sivuotsikon tulee kuvata sivua mahdollisimman hyvin ja rehellisesti.

Ensimmäisenä muutoksena kävin muuttamassa palvelua niin, että tuo "title" -tagi kertoisi jotain olennaista (ja yksilöllistä) näytettävästä sivusta. Myöhemmin olen myös oppinut, että hakukoneoptimoinnin kannalta tämä "title" -tagi on erinomaisen tärkeä. Joten sattumalta lähdin oikeaan suuntaan.

Opetus 6: Webmetriikka

Valitetettavasti hommat ei lopu siihen, että palvelu on julkaistu. Normaalisti tässä kohtaa on valmiina vain pieni osa suunnitelluista/ajatelluista toiminnallisuuksista. Näin oli tietenkin mutteri.com:inkin kanssa. Tekemistä olisi ollut vielä vaikka kuinka.

Mutta tässä kohtaa kannattaa pitää pieni tauko omien ajatusten ja suunnitelmien toteuttamisessa. On aika varmistaa, että palvelua aletaan käyttää. Pitää seurata miten palvelua käytetään. On täysin mahdollista, että kuvittelemasi "maailman loogisin" toiminnallisuus ei olekaan niin itsestään selvä muille. Seurantaa voi tehdä usealla eri tavalla. Voit rakentaa oman loggerin, joka tallentaa kaiken mitä järjestelmässä tapahtuu [minä tein mm. tämän]. Voit seurata web-serverin logeja. Mutta viisas ottaa käyttöön valmiit työkalut. Itse otin googlen Analytics palvelun käyttöön. Se oli ilmainen (muitakin ilmaisia on, mutta niistä suurin osa pitää asentaa omalle palvelimelle). Googlen analytics tarjosi perusraportit juuri sillä tasolla mitä tässä vaiheessa tarvitsin.

Seuraa palvelun käyttöä heti alusta webmetriikka työkalujen avulla. Ole valmis hylkäämään omia hienoja ajatuksia, jos ne eivät toimi.

Tässä vaiheessa suosittelen sitä, että seuraat järjestelmän käyttöä ja muutat sovellusta sitä mukaan kun opit käyttötilastoista jotain. Eli vanha kunnon: yritys ja erehdys -strategia. Koska kävijämäärät ovat mahdolliseti alhaisia, ei muutosten seuraukset ole aina niin ilmeisiä, mutta ainakin sinun pitää pystyä havaitsemaan ongelmat käyttötilastoista.

Ensimmäinen versio valmis

Joskus heinäkuun lopussa sain ensimmäisen version valmiiksi ja tuotantokäyttöön. Ensimmäisenä tietenkin pistin omat romuni myyntiin.

Oli tietenkin selvää, että mitään ryntäystä saitille ei tullut. Eihän kukaan tiennyt mikä ihme se www.mutteri.com oikein on. Muutaman päivän seurailin liikennettä, mutta ei...

Muista ilmoittaa sivustosi hakukoneille. Hakukoneiden kautta tulee suurin osa uusista kävijöistä.

Googlailin lämpimäkseni eri hakusanoilla millä kuvittelin vierailijoiden saapuvan. Mutta Top 10:iin on vaikea murtautua. Esimerkiksi Kirpputori -hakusanalla www.mutteri.com oli jossain sijalla 200+. Eipä sinne saakka hakutuloksia kovin moni jaksa selata.

Positiivisena pilkahduksena voi todeta sen, että hakusana "kirpputori +tuote" yhdistelmällä alkoi tulla parempia sijoituksia googlessa.

Koska minulla oli tarve myydä tuotteet, pistin myynti-ilmoituksia myös ns. "kilpailijoiden" kanaviin, kuten uutisryhmiin jne. Jokaiseen ilmoitukseen tietenkin linkki mutteri.com:iin.

Tällä "kikalla" alkoi tulla satunnaisesti hieman enemmän kävijöitä. Mutta niitä kaikkia vaivasi sama "vika": Ne tulivat, lukivat sen ilmoituksen mitä etsivät ja poistuivat. Tämä ei tietenkään ollut mikään veret seisauttava yllätys, mutta kuvittelin että ns. "sticky" kävijöitä tulisi edes vähän paremmalla prosentilla.

Vääränlainen markkinointi tuo vääränlaisia vierailijoita.

Joskus elokuussa tuli ensimmäinen ihan rehellinen ostajakin - joku tiedusteli minulla myynnissä ollutta sohvaa. Viestissä oli viite juuri www. mutteri.com:iin.

Ensimmäisen viikon vierailijasaldo oli jossain 10:n erillisen kävijän tasolla (siis viikossa, ei päivässä).

Huomio ohjelmakoodista: Tässä vaiheessa ohjelmointi prioriteettini oli selkeä: saada jotain toimivaa käyttöön. Ohjelmakoodi oli hirveää (tietokanta oli ok).

Opetus 5: Tietokantasuunnittelu

Koska mutteri.com oli tarkoitus olla dynaaminen ja sisällöntuottajia olivat käyttäjät tuntui luonnolliselta tietovarastolta relaatiotietokanta. Vaatimus edullisuudesta ohjasi ilmaisen MySQL:n luokse. Tämä oli yksi palveluntarjoajan valintakriteereistä.

Suunnittele tietokantasi huolella

Minun ohjelmoinnin suunnittelu on aina ollut vajavaista. On niin paljon hauskempaa koodata kuin suunnitella. Tässä kohtaa poikkeuksen tekee tietokannat. Aikaisemman kokemuksen perusteella (www.mutteri.com ei ollut ensimmäinen sovellus mitä minä kehitin) oli jotain oppia mennyt kovanpuoleiseen päähän. Ja se oppi koski tietokannan suunnittelua. Koodia on erittäin helppo kirjoittaa uudestaan ja uudestaan. Ja vaikka tietokannan uudelleen suunnittelu on myös helppoa, tulee tietokantojen mukana epämiellyttävä ongelma: mitä tehdä olemassaolevalla datalle? Jos tietokantaa pitää uudelleen organisoida jatkuvasti, menee tarpeettoman paljon aikaa myös tiedon migrointiin (eli siirtämiseen vanhasta rakenteesta uuteen). Ja tämä on virhealtista hommaa.

Toinen tietokantasuunnittelun puolestapuhuva seikka on se, että hyvin suuunniteltu tietokanta sallii helpon laajennettavuuden. Voit siis pienellä vaivalla luoda uutta toiminnallisuutta ja hyödyntää jo tallennettua tietoa.

Onneksi olen aina ollut kiinnostunut relaatiotietokannoista ja niiden tarjoamista mahdollisuuksista (ja onpa sitä joskus yliopistolla tullut opiskeltuakin).

Tietokannat väitän suunnitelleeni hyvin.

Design haasteita horisontissa

Kuten ideointivaiheessa tuli esille, minä en ole graafinen suunnittelija. Itse kukin haluaisi olla visuaalisesti erinomaisen taitava - moni saattaa jopa luulla olevansa. Tässä suhteessa olen ollut suhteellisen realistinen ja tunnistin sekä tunnustin omat rajoitukseni.

Yksi minulle suuria ongelmia aiheuttava alue on värimaailma. Minulla ongelma on suurempi kuin monilla muilla, sillä olen värisokea. Punaiset, vihreät, ruskeat ja oranssit menevät turhan helposti sekaisin. Koska minulla on ollut tällä saralla hieman haasteita, en ole siihen juurikaan perehtynyt edes niissä puitteissa mihin minulla olisi ollut mahdollisuuksia. Siispä en rehellisesti sanottuna osaa sanoa mitkä värit sopivat yhteen ja mitkä eivät.

Tikkurilan värilastuilla saitille toimiva väritys.

Mutta kun into on kovaa, niin hätä kyllä keinot keksii (vai mitenkäs se nyt menikään). Minä keksin Tikkurilan värilastut. Tikkurilalla on asiantuntijoita jotka kuluttavat aikaansa pohtimalla trendivärejä ja väriyhdistelmiä - miksi siis yrittää keksiä pyörää uudestaan. Hain Tikkurilan web-sivuilta värikartan ja siitä valitsin www.mutteri.com:in värimaailman.

Tuumasta toimeen

Nyt oli asiaa märehditty riittävästi. Suunnitelmat www.mutteri.com:ista olivat suunnilleen valmiit ja kaikki kritiikki oli sujuvasti unohdettu tai painettu villaisella. Päätös palvelun perustamisesta oli valmis. Sitten ei muuta kuin kehitysympäristö pystyyn Linux:iin, muutama rivi html:ää, php:ta ja tietokanta pystyyn. Eihän siinä sen kummempaa. Kaksi viikkoa (iltaisin) ja homma valmis... Tai sitten ei.

Arvioin kehittämisen vaatiman ajan todella pahasti väärin. Pyrin koodaamaan jonkinlaisessaa sovelletussa XP eli extreme programming moodissa, missä aina tehtiin yksi toiminnallisuus valmiiksi, niin sitä pientä tekemistä vain riitti ja riitti ja riitti (ja riittää yhä). Jossain kohtaa kirjoittelen lisää kehitysmetodeista(ni) ja kaikesta mitä siinä olen oppinut.

Tässä kohtaa elettiin muistaakseni kesä-heinäkuuta 2006.

Kehitysympäristö
Kehitysympäristönä käytän Linux Fedora Core versiota 6. Apachesta taitaa olla versio 2.x, phpsta 5.x ja taitaa MYSQL:kin olla viitos versiota.
Työkaluina käytän:
- tekstieditori (jep, kaikki on käsin koodattu) Quanta+ [aivan loistava editori KDE ympäristössä]
- selaimena Firefox, Moxilla, Konqueror ja Opera. Koska teen kehitystä Linux:illa, saattaa tulos IE:llä olla sillointällöin ei niin kaunista. Mutta pyrin tarkistamaan sillointällöin jollain windows koneella miltä näyttää - ja korjata kun ongelmia löyty.
- FTP sovelluksena ja tiedostonhallintaan soveltuu erinomaisesti tuo Konqueror (siinä on myös selain samassa mikä on välillä ihan kätevä ominaisuus).
- versionhallinta: ei mitään koska teen järjestelmää yksin, ja jokaisen session jälkeen käteen jää toimiva / julkaisukelpoinen järjestelmä.
- backupit: ei oikeastaan mitään - jokaisen session jälkeen koodi heitetään tuotantojärjestelmään joten siellä on backup, jos kotikone hajoaa.