Suunnilleen hyvää web-sivuston toteutusta

Ostin itselleni kesällä Packard Bell laptopin. Moni saattaa mielessään kysyä: miksi ihmeessä? Packard Belliltä löytyi 12 tuuman kannettava, missä ominaisuudet ja hinta tuntui järkevältä. Kilpailevat tuotteet olivat poikkeuksetta noin 200 euroa kalliimpia, eikä ominaisuudet kuitenkaan olleet merkittävästi parempia.

Uuden tuotteen ostajalle on tietenkin tuttua se, että tuote pitää, tai sen voi, rekisteröidä valmistajan järjestelmiin. Tämän pitäisi parantaa mm. takuukäsittelyä, jne. Enpä ole vielä koskaan mitään rekisteröinyt valmistajalle, joten nyt ajattelin kokeilla. Päädyin Packard Bell:in sivustolle mikä oli melkein suomenkielinen.

Itse rekisteröintisivu oli noin päällisin puolin ihan siisti ja järkevä, mutta kun sivua alkoi tarkastella hieman, huomasin kuinka puolittainen toteutus itseasiassa olikaan. Harvemmin kaupallisiin tarkoituksiin tehdyllä sivulla on näin paljoa virheitä. Katso kuva alla:

1. sivun vasen navigointipalkki on enkoodattu eri merkistöllä kuin muu sivusto. Tästä johtuen navigointilinkeissä menee skandinaaviset merkit sekaisin.
2. kielivalinnassa on sana "Finnish" kirjoitettu väärin (Finish = loppu, maali, lopeta).
3. Etuliitevaihtoehdot ovat Herra ja Fru
4. Täytettävien kenttien joukossa on mystiset: Sähköposti, vahvista ja sähköpostiosoite. hmm... Pitääköhän tuohon täyttää sähköpostiosoite kolme kertaa?
5. Maavalikossa maat ovat listattuina englanninkielisinä (tämä tosin on aika tyypillinen virhe). Suomi ei ole suomenkielellä: Finland.
6. Lomakkeen päätteeksi käyttäjää kehoitetaan sujuvalla hollanninkiellellä(?): Klik op de knop Verzenden hieronder om door te gaan naar de downloadpagina voor leuke snufjes.

huh - domainin siirto takana

Kuten jokunen viikko takaperin tuli mainittua, olin päättänyt siirtää mutteri.com:in toiselle palveluntarjoajalle. Siirtoon liittyy aina vain valitettavasti riskejä ja huolia:

• kuinka pitkäään järjestelmä on poissa käytöstä?
• miten varmistetaan, että siirron yhteydessä viimeisimmät muutokset saadaan siirrettyä uudelle palveluntarjoajalle?
• miten siirtää tietokannan sisältö?
• entäs erilaiset merkistöt (utf8, latin, ...)?
• tarjoaako uuden palveluntarjoajan järjestelmä tuen samalle php konfiguraatiolle?
• hidastuuko järjestelmä siirron jälkeen tai sen seurauksena?
• katoaako osa käyttäjistä siirron jälkeen tai yhteydessä?

Mutta nämä huolet ovat valitettavasti sellaisia, että varmuudella vastauksen saa vasta kun homma on hoidettu. Varsinkin näiden "halpojen" palveluntarjoajien kanssa palvelutasossa voi olla toivomisen varaa. Mutta kuinka ollakaan tämä(kin) siirto tapauhtui verrattain kivuttomasti. Daous / int2000.net (edellinen palveluntarjoaja) hoiti tällä kertaa siirtoon liittyvät muutokset erinomaisella tavalla. Heidän puoleltaan ei tullut mitään hikkoja tai muita ongelmia. Vastaavasti uusi palveluntarjoaja hoiti hommansa mallikkaasti - tosin godaddy:llä kaikki on automatisoitua, joten sitä kautta palvelu sujui kivuttomasti ja vailla viiveitä.

Siirron yhteydessä palvelu oli poissa käytöstä noin tunnin ajan. Olin etukäteen laittanut etusivulle ilmoituksen tulevasta muutoksesta. Tietojen siirtokin sujui mallikkaasti: yhtään rekisteröitymistä tai uutta ilmoitusta ei menetetty ja käyttöhistoriaakin katosi vain joitain minuutteja. Tietokannan kanssa oli suurimmat ongelmat - osa tauluista on kymmenien megatavujen kokoisia, joten niiden lataaminen uuteen järjestlemään oli ongelmallista. Valitettavasti osa datasta piti jättää lataamasta. Tämä ei kuitenkaan ollut mitään järjestelmän kannalta kriittistä dataa. Ja sekin data on tallessa. Merkistöjen kanssa on aina ongelmia, mutta nyt sekin sujui varsin kivuttomasti, sillä testailin niitä uudella palveluntarjoajalla jo etukäteen. Myös php konfiguraatiot tuli testattua siinä määrin, että olin vakuuttunut jo etukäteen, että siirron yhteydessä ei menetetä toiminnallisuuksia. Hidastumiseen vastaus saataneen muutaman ensimmäisen käyttökuukauden aikana, mutta toistaiseksi näyttää hyvältä. Käyttäjäkatokin selviää lähiviikkoina - tosin joulukuu on muutenkin ollut erinomaisen hiljaista aikaa. Ihmiset selvästi viettävät enemmän aikaa kaupoissa joulun valmistelu mielessä. Toivotaan, että käytetyn tavaran myyminen vilkastuu taas tammikuussa.

Muuton yhteydessä päätin olla julkaisematta uutta toiminnallisuutta. Mahdollisen jälkikorjailun kannalta on viisaampaa rajoittaa muutosten määrää. Parempi tehdä yksi suurempi muutos kerralla - näin voidaan rajata ongelman syntysyitä mikäli ongelmia muodostuu.

Sivun ulkoasun suunnittelu

Sivun ulkoasun suunnittelu on luonnollisesti yksi sivuston luomisen mielenkiintoisimmista vaiheista. Asettelu on teknisesti yksinkertaista (wysiwyg, html, jne) koska html kuvauskielenä helpohkosti opittavissa. Ulkoasu on yksinkertaisuudestaan huolimatta yksi tärkeimmistä tekijöistä millä sinä voit erottua muista sivustoista. Uskaltaisin melkein väittää, että sivuston ulkoasu on heti toiseksi tärkein seikka millä voit vakuuttaa käyttäjäsi palvelusi tuomasta lisäarvosta. Kaikkein tärkein on laadukas ja originaali sisältö. Jacob Nielsen [yksi web käytettävyyden pioneereista] on usein sanonutkin "Content rules" eli sisältö hallitsee.

Kun opettelet HTMLn saloja, tutustut CSS:ään, huomaat pian, että sivuston ulkoasun suunnittelussa vain taivas on rajana. HTML sallii sinun taittaa sivusi villeimpien haaveidesi ja visioidesi mukaisesti. Tätä nykyä on mahdollista sijoittaa sivulle melkein mitä tahansa mediaa (kuvia, musiikkia, videoita, sovelluksia [kutenMarcromedian flash]). Mutta varoituksen sana:

Se että jotain voi tehdä, ei tarkoita että sitä pitää tehdä, tai että sitä edes kannattaa tehdä.

Sivustoa suunnitellessa kannattaa tutustua käytettävyyteen ja tiettyihin internetin lainalaisuuksiin. Käytettävyydestä löytyy varmasti paljon materiaalia googlaamalla, mutta jos mitään muuta et jaksa / halua lukea, niin käy katsomassa Jacob Nielsenin ajatuksia useit.com:issa.

Jacob on käytettävyyden pioneeri ja hänen kirjoituksensa jopa 90 -luvun alusta ovat yllättäen yhä pääosin ajankohtaisia ja valideja.

Kehittelen siis www.mutteri.com:ia Linuxissa pyörivässä kehitysympäristössä. Laitteistoni ei ole viimeistä huutoa, joten käytän normaalisti resoluutiota 1280x1024. Mielestäni tämä on verrattain matala resoluutio, joten oletin että suurin osa käyttää ainakin tätä resoluutiota, ellei peräti 1600x1280. Olen kehittämisessä noudattanut Nielsenin oppeja mm. siinä, että sivuston taulukot on tehty skaalautiviksi (ei siis kiinteän levyisiksi, vaan leveydet on määritelty suhdelukuna selaimen leveyteen). Tällä saavutetaan normaalisti hyvä yleiskäytettävyys erilaisilla resoluutioilla. Mutta se mitä en kehittäessäni ottanut huomioon on, että googlen mainosten aseettelu vaikuttaa merkittävästi siihen miten sivustoa voi skaalata. Koska en tietenkään näytä kehitysympäristössäni googlen mainoksia (itselleni), en nähnyt tuota vaikutusta ennenkuin sain aiheesta palautetta loppukäyttäjiltä. Sain kuulla, että sivu ei mahdu kokonaisuudessaan näytölle jos käyttäjällä on resoluutio 1024x768 (tai alhaisempi). Ensimmäinen ajatukseni oli: "no kyse on marginaaliryhmästä". Mutta varmistin asian käyttötilastoista, jotka kertoivatkin karua kieltä: 50% käyttäjistä käyttää 1024x768 resoluutiot.

Älä siis oleta, että tavallisten käyttäjien laitteisto vastaa omaa laitteistoasi.

Itse asiassa, suunnittele sivustosi kaikkein heikoimmalle kokoonpanolle - siten palvelet niin vanhoilla laitteilla selaavia kuin uusimpien laitteiden käyttäjiä.

Opetus 9: Kerralla tuskin tulee valmista

Ainakin minulle tämä oli itsestäänselvyys, mutta se kuinka monta kertaa olen käynyt ja kahlannut koodin läpi on ollut taas yllätys. Mikäli päätät ohjelmoida samassa moodissa mitä minä olen tehnyt, kannattaa varautua siihen, että kirjoitat saman koodin monta kertaa.

Valmistaudu koodaamaan samat toiminnallisuudet useampaan kertaan.

Välillä on koodia siirretty pääohjelmasta funktiohin, ja sitten taas takaisin. Tämän voi mahdollisesti välttääkin, mutta väitän, että se onnistuu vain joko

• Huolellisella ja perinpohjaisella suunnittelulla


• Pitkällä kokemuksella


• tai näiden yhdistelmällä

Uudelleen koodaamisessa ei ole mitään vikaa - joka iteraatiolla koodin laatu luultavasti paranee ja luotettavuus kasvaa. Mutta tähän kuluu aikaa yllättävän paljon. Aina kun koodiin kosketaan, kannattaa se testata jollain tasolla. Jos et testaa, voi tulla odottamattomia yllätyksiä.

Kuinka ollakkaan, olin edellisellä kerralla koodia siivotessani onnistunut rikkomaan kuvan lisäys ominaisuuden.

Itselle kävi mm. siten, että ihmettelin miksei rekisteröityneet käyttäjät lisänneet kuvia. (no ihmettelen sitä välillä vieläkin, mutta se on hieman off-topic). Jonkin aikaa ihmeteltyäni, päätin varmistaa, että toiminnallisuus yhä toimii. Kuinka ollakkaan, olin edellisellä kerralla koodia "siivotessani" onnistunut rikkomaan kuvan lisäys ominaisuuden. Ei ihme, ettei kuvia tullut.

Opetus on siis se, että varaudu siihen, että samaa ohjelmakoodia pitää kirjoittaa useampaan kertaan.

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.