Huominen ei koskaan kuole – paitsi teksteissä

Olen osallistunut viime viikkoina Prisman Facebook-sivulla yläpeukkuarpojen raaputtamiseen. Tänään (2.9.) on viimeinen päivä osallistua, mutta silti epäonnista raaputtajaa kehotetaan yrittämään huomenna uudelleen. Myös K-Citymarket kirjoitti Facebook-sivuilleen: "Elokuun 31. eli huomenna on vissiin virallisesti syksyn ensimmäinen päivä. Vai onko? Mistä syksy sinun mielestäsi alkaa?" Tämä kyseinen Facebook-kysymys julkaistiin perjantaina, 31. elokuuta. Näistä esimerkeistä huomaa helpoista, kuinka ongelmallisia tietyt ajanmääreet ovat.

Vältä nopeasti vanhenevia ajanmääreitä

Helpointa on välttää kirjoituksissa termejä eilen, tänään, huomenna, ensi viikolla tai viime kesänä. Näiden sijaan voi kirjoittaa vaikkapa kesällä 2012 tai 1. syyskuuta (ja lisätä vielä vuosiluvun, jos haluaa olla oikein tarkka). Facebook-statuksissa tai tweeteissä voi käyttää vanhenevia ajanilmauksia, koska kyseisissä palveluissa on jokaisen kirjoituksen yhteydessä mainittu päivämäärä, jolloin kirjoitus on julkaistu. Citymarketin tapauksesta opimme kuitenkin, että tekstin ja julkaisupäivämäärän pitää vastata toisiaan myös sosiaalisessa mediassa. Myöskään, jos sivun tai osion nimi on ajankohtaista, uusin tiedote ei saa olla viime vuodelta, ainakaan syyskuussa.

Laita kalenteriin tärkeät päivämäärät

Jokainen www-sivulle (tai tiedotteeseen seinälle) kirjoitettu päivämäärä tulevaisuudesta vaatii suunnitelman tiedotteen päivämäärän jälkeisistä toimenpiteistä. Nämä toimenpiteet kannattaakin suunnitella saman tien. Piilotetaanko sivu/heitetäänkö tiedote roskiin vai muokataanko sivua/tehdäänkö uusi tiedote. Monissa julkaisujärjestelmissä toimintoja, esimerkiksi sivun piilottamisen, voi ajastaa etukäteen ja näitä ominaisuuksia kannattaakin hyödyntää. Automaattinen tai ajastettu toiminto poistaa muistin varassa toimimisen, eikä tällöin tarvitse olla esimerkiksi puolen yön aikaan tietokoneella poistamassa tiedotetta tai muokkaamassa vanhaa tekstiä. Paperijulkaisijat voivat tehdä myös uuden tiedotteen jo valmiiksi ja merkitä tiedotteeseen päivämäärä, jolloin uusi tiedote julkaistaan.

Virheelliset mainokset

Silloin tällöin törmään nettimainoksiin, jotka vievät aivan väärään paikkaan. Domain-nimi saattaa olla väärin tai sitten linkki vie vaikkapa virhesivulle. Mainos voi olla virheellinen muodosta riippumatta: olen törmännyt sekä virheellisiin bannereihin että virheellisiin Facebook-mainoksiin. Viimeisin kohtaamani virheellinen mainos oli McDonald'sin facebook-mainos:

Virheellinen mainos tai siis virheellinen linkki on kahdella tapaa huono asia. Ensinnäkin mainosbudjettia kuluu, mutta mainosta klikannut kävijä ei näe haluttua viestiä. Toinen negatiivinen vaikutus on kävijän kokema pettymys, kun hän ei näekään mainosta. Kävijä on kuitenkin ollut lähtökohtaisesti kiinnostunut mainoksen viestistä – ellei hän ole vahingossa klikannut mainosta.

Mainoskampanjan lanseerauksen yhteydessä tulisi mainos testata ainakin kerran. Testaaminen kannattaa tehdä jollain ihan toisella tietokoneella, esimerkiksi kotikoneella, jotta selaimen istunnot tai yrityksen sisäverkko eivät vääristäisi tuloksia. Lisäksi kannattaa tietenkin seurata esimerkiksi Googlen työkaluilla Sivua ei löytynyt -sivun kävijämääriä ja liikenteen lähteitä. (Eikä tietenkään haittaa, vaikka seuraisi kampanjan ns. landing page -sivun kävijämääriäkin.)

Asiakastyytyväisyyslomakkeista

Silloin tällöin minulle tarjotaan mahdollisuutta kehittää jonkin yrityksen toimintaa: minulle annetaan asiakastyytyväisyyskysely. "No, mikäs siinä, kiva auttaa muita", ajattelen kerta toisensa jälkeen.

Lomake alkaa yleensä viattomasti: ensimmäisellä sivulla lämmitellään kysymyksellä, joka voi olla esimerkiksi olenko mies vai nainen. "Tämähän on helppoa", ajattelen ja valitsen seuraava sivu. Monesti tässä vaiheessa latautuu ruutuun radiopainikkeiden armada. "Kuinka tärkeänä koen seuraavat asiat, 1=ei lainkaan tärkeä.." lukee yleensä sivun ylälaidassa. Hammasta purren saan eriteltyä mielessäni asiakaspalvelijan ystävällisyyden, asiantuntijuuden ja nopeuden tärkeyden mielessäni. Lopulta painan "seuraava sivu" -painiketta. Tämä on yleensä virhe. Seuraavalla sivulla on, jos mahdollista, vielä enemmän radiopainikkeita ja pyydetään arvioimaan kyseisen yrityksen onnistumista em. asioissa.

Olen sen verran lyhytjännitteinen, että tässä vaiheessa katson jostain sivun reunasta, että kyseessä on sivu 3/13 ja tässä vaiheessa lopetan vastaamisen. Jos kyseessä on paperilomake, heitän lonkalta vastaukset loppuihin kysymyksiin. Jos kyseessä on nettilomake, suljen selaimen.


Esitän tässä oman ehdotukseni asiakastyytyväisyyskyselyksi (tähän voi lisätä muutaman lisäkysymyksen), johon ihmiset jaksaisivat vastata ja joka antaisi totuudenmukaisia palautteita. Tämä voi tuntua liian suppealta, mutta monisivuiset kyselyt eivät välttämättä anna (ainakaan minun tapauksessani) oikeita tuloksia viimeisten kysymysten osalta. Myös ns. "haloefekti" (engl. "halo effect") pitänee huolen, että ihmiset eivät kuitenkaan osaa niin tarkasti eritellä asiakaspalvelun eri osa-alueita kuin monissa kyselyissä oletetaan.

VR:n uusi lippukauppa

VR avasi tänään uuden lippukauppansa. Lippukaupan avaus ei mennyt aivan putkeen ja verkkokauppa olikin tänään kaatuneena pitkin päivää. Varmasti ns. Backend-puolella on omat haasteensa, mutta tässä kirjoituksessa käyn läpi ns. frontend-puolen ongelmia VR:n lippukaupassa. Tiedot on haettu YSlow- ja Page Speed -selainlaajennoksilla.

jQuery
jQuery ladataan VR:n verkkokaupassa 2 kertaa. Toinen tiedosto eli jquery-1.4.2.js on täysin turha ja kuluttaa käyttäjän kaistaa turhaan 160 kB. jQuery-plugin-tiedostot kannattaisi myös minimoida jollakin minimointityökalulla.

Tiedostojen pakkaus
Käyttämällä gzip-pakkausta palvelimella sivun ja sivuun liittyvien muiden tiedostojen koko laskisi jopa 392 kB / käyttäjä (72%).

Selaimen välimuisti
Selaimen välimuistia voisi hyödyntää monen tiedoston kohdalla. Tuskin esimerkiksi jQueryn 1.4.2-tiedosto tulee enää koskaan muuttumaan (tai ainakin tiedostonimi vaihtuu).

Staattiset tiedostot
Tiedostoja, jotka eivät muutu koskaan, ei kannata jakaa dynaamisen JSP-palvelimen kautta. Ne kannattaisi jakaa staattisten tiedostojen jakamiseen tarkoitettujen palvelimien kautta. Lisäksi palvelimella on jokin yhtäaikaisten pyyntöjen maksimiraja ja staattiset tiedostot syövät tätä limiittiä. Staattiset tiedostot kannattaisi jakaa myös ihan toisesta domainista, jotta selaimet eivät lähettäisi evästeitä jokaikisen staattisen kuvan tai muun tiedoston kohdalla.

Staattisten tiedostojen yhdistäminen
Jos käyttäjän pitää joka kerta ladata samat JavaScript-tiedostot, miksi niitä ei yhdistettäisi yhdeksi tai maksimissaan pariksi JavaScript-tiedostoksi?

Ai niin, Page Speed antaa pistemääräksi 28 / 100 VR:n verkkokaupalle. Ja miksi huoltokatkosivu on kooltaan n. 256 kilotavua?