Spesialistikoodarin tehokkain ase tuottavia alustoja vastaan on sana arkkitehtuuri. Esimerkiksi: “Tuottavan alustan arkkitehtuuri on täysin paska. Tietoturvassa on aukkoja ja koodi on rumaa.” Hän unohtaa sujuvasti, että kaikessa koodissa on aukkoja ja että rumuus on subjektiivista. Arkkitehtuuri ei sitä paitsi tässä yhteydessä oikeastaan tarkoita mitään muuta kuin että koodarin kapeasta näkökulmasta asiat on tehty väärin.

Arkkitehtuuriargumentti toimii, koska se on niin epämääräinen. Ja kuka muka voi tietää asiat paremmin kuin asiantuntija?

Tuottavien alustojen sijaan spesialisti suosii alustoja, jossa riittää nysvättävää ja samoja asioita voi koodata yhä uudestaan yhä jännittävimmillä ja vaikeammilla tavoilla. On aivan sama, ratkooko hän oikeita ongelmia.

Spesialistikoodari osaa ja tietää paljon yhä vähemmästä. Hän pureutuu syvemmälle esimerkiksi skaalautumisen ja tietoturvan problematiikkaan, vaikka nämä ovat jo ajat sitten lakanneet olemasta useimmille asiakkaille relevantteja ongelmia.

Hän koodaa itseään, ei muita varten.

Yllä oleva video havainnollistaa, kuinka ostoprosessissa edestakaisin liikkuessa valinta ei pysy, vaan tilalle ilmeisen sattumanvaraisesti arvotaan joku muu lähtö.

Kyseessä ei ole edes mikään uusi löytö. Ongelma on raportoitu jo kohua herättäneessä User Pointin käytettävyysarviossa (sivun 40 lopussa).

Panee miettimään, että miksi ensimmäisellä sivulla mitään valintaa edes on, jos sitä ei lainkaan kunnioiteta.

Panee myös miettimään, kuinka moni on mennyt samaan ansaan. Ainakin minun kahteen kertaan maksetulla matkallani käytävän toisella puolella istui matkustaja, joka oli tehnyt saman virheen.

No, jotenkin ne uudistukseen hukatut rahat on saatava takaisin.

Eat.fi:n mobiilisovellukset suosittuja, verkkosivujen käyttö mobiililaitteilla olematonta

Eat.fi-palvelua on voinut käyttää mobiililaitteilla, esimerkiksi mobiilioptimoidun verkkosivun kautta osoitteessa m.eat.fi jo vuodesta 2009. Tämän lisäksi palvelua on voinut käyttää myös erillisillä mobiililaitesovelluksilla. Sovellukset ovat tarjolla Applen iPhonelle, Android-puhelimille ja Nokian puhelimille. Tällä hetkellä palvelun mobiililaitteille optimoidun verkkosivun käyttö on erittäin vähäistä.

“Mobiilisovellukset ovat nopeasti kasvattaneet suosiotaan. Tällä hetkellä Eat.fi:n mobiililaitteille optimoitujen verkkosivujen käyttö on vähentynyt käytännössä olemattomaksi”, kertoo Tina Aspiala Eat.fi-palvelusta.

Tiedote ei pureudu tämän syvemmälle olemattomuuden syihin. Mutta vierailemalla Eat.fi:ssä mobiililaitteella selviää yksi todennäköinen syy välittömästi. Mitään uudelleenohjausta m.eat.fi:hin ei tapahdu. Edes selkeää linkkiä mobiiliversioon ei ole tarjolla.

Satunnaiset käyttäjät – he, jotka eivät (ainakaan vielä) ole nähneet tarpeelliseksi asentaa palvelun sovellusta puhelimeensa – hyötyisivät mobiiliversion löydettävyydestä merkittävästi.

Sovelluksia ihastellessa unohtuu usein, että niiden asentaminen on monille edelleen sen verran iso kynnys, että mikäli ei ole täysin sitoutunut käyttäjä, jää se helposti tekemättä. Sitä paitsi sovelluskauppojen selaaminen ei varmasti ole koko kansan iltahuvia. Eat.fi:llä epäilemättä on iso uskollinen käyttäjäkunta, joka sovelluksen on jo asentanut. En silti usko, että kaikkia potentiaalisia käyttäjiä on vielä saatu asentamaan sovellusta.

Mobiiliversion välittömän käyttäjäpotentiaalin voi tarkistaa varsin helposti Google Analyticsista mobiililaiteraporteista. Mikäli se on Eat.fi:n mainitseman 40 000 viikkotason eri kävijän massasta yhtään merkittävä osuus, kannattaisi asialle tehdä jotain. Tyypillisesti mobiiliprosentti huitelee jossain viiden prosentin tienoilla ja on kovassa kasvussa.

Miten sitten Eat.fi voisi toimia parantaakseen tilannetta? Yksinkertaista:

1. Toteutetaan Eat.fi:hin yksinkertainen laitetunnistus, joka uudelleenohjaa merkittävimmät mobiililaittet automaattisesti m.eat.fi:hin.
2. Lisätään Eat.fi:hin selkeä linkki mobiiliversioon, aivan sivun alkuun. Näin tunnistamatta jääneiltäkin laitteilta on mahdollista löytää mobiiliversio.
3. Lisätään m.eat.fi:hin selkeä linkki takaisin täysversioon. Koska mobiiliversio on toiminnoiltaan typistetty ja poikkeava, on tarjottava myös täysversiota sitä haluaville.
4. Lisätään m.eat.fi:hin tietoa sovellusten latausmahdollisuuksista (kohdennettuna käyttäjän laitteen mukaan, jos se tunnistetaan).

Uudelleenohjauksissa ja linkityksissä on huomioitava, että viittaukset tehdään suoraan vastaavaan sisältöön toisessa versiossa eikä vain kylmästi etusivulle. Ja kun kyseessä on teknisesti kaksi eri versiota, on myös pidettävä huolta, että karsittukin versio todella osaa näyttää sisällön. Ainakin Hs.fi:llä oli tällaisia ongelmia.

(Tätä ongelmaa ei tule mukautuvassa verkkosuunnittelussa, mutta se ei sovellusmaiseen Eat.fi:hin välttämättä ole sovellettavissa eikä varsinkaan ratkaise tätä sinänsä pientä ongelmaa kustannustehokkaasti.)

Näillä pienillä toimilla saataisiin mobiiliversiolle isompi käyttäaste, palveltaisiin satunnaisia käyttäjiä paremmin ja ohjattaisiin satunnaisia käyttäjiä säännöllisemmiksi sovellusten käyttäjiksi.

Mobiilisaitin käyttöaste saattaa muutosten jälkeenkin säilyä olemattomana, mutta ainakaan se ei ole enää löydettävyydestä kiinni.

Kirjassa on viisi lukua: ensimmäisessä perustellaan responsiivisen suunnittelun ajatusta. Seuraavat kolme lukua käsittelevät kukin yhden kolmesta perusrakennuspalikasta: joustavat gridit, joustavat kuvat ja media queryt. Keskimmäisen luvun ydinosat ovat luettavissa A List Apartin artikkelista. Viimeinen luku käsittelee joitain yksityiskohtia ja työprosessien muutoksia. Yllättävää kyllä mobile first -ajattelu tuodaan mukaan vasta tässä vaiheessa.

Kun lähtee tekemään responsiivista suunnittelua, huomaa nopeasti, että tarvitaan myös responsiivinen julkaisujärjestelmä ja responsiivista sisältöäkin. Nämä alueet on pientä mainintaa lukuun ottamatta jätetty kirjan ulkopuolelle, mikä on osaltaan harmi, mutta toisaalta riippuvat hyvin paljon taustateknologista, itse sivustosta ja sen sisällöstä. Ehkä näistä aiheista onkin sitten kirjoitettava teknologiakohtaiset opukset.

Noin 150 sivua sisältävä kirja ei ole ainakaan liian raskas paketti, vaan sen kahlaa läpi muutamassa tunnissa. Yhdeksän dollarin hintaan ei kannata jäädä pohtimaan sijoittaako moista summaa sähköiseen versioon. Kirja on teknisestä fokuksestaan huolimatta pakollista luettavaa kaikille verkkopalveluiden suunnittelijoille ja kehittäjille.

Tämän hullun applikaatiohypen aikana maailma tarvitsee yksinäisiä sankareita, jotka pelastavat meidät kaikki pahoilta megakorporaatioilta.

Vielä muutama vuosi sitten tuntui mahdottomalta ajatukselta, että pärjäisi ilman Messegeriä tai että Jabber voisi mitenkään yleistyä. Niin on kuitenkin nyt tavallaan käynyt.

Facebook Chat lienee suurin syypää tuon käyrän laskuun. Riittävän monella lienee myös Gmail käytössä, että Google Talk -pikaviestimen käyttö syö Messengerin eväitä. Trendiä varmasti on voimistanut surkea Messengerin asiakasohjelma, joka häiritsee mainoksilla ja ties millä roskalla.

Sosiaalisen verkon arvo kasvaa sitä voimakkaammin mitä enemmän sillä on jäseniä. Valitettavasti myös käänteinen on totta. Messengerin täydellinen romahdus on erittäin todennäköinen.

Mielenkiintoista tässä trendissä on se, että tilalle ei ole tullut toista asennettavaa sovellusta (paitsi ehkä Skype jonkin verran), vaan ihmiset vaihtavat web-pohjaiseen ratkaisuun sen asennuskynnyksen olemattomuuden takia. Kun muistelee, miltä web-pohjaiset chatit näyttivät vielä muutama vuosi sitten (Messengeristä oli todella kömpelö popup- ja iframe-viritelmä), on niistä ajoista tultu todella pitkälle.

Itsekin hiljalleen suljen vähäisellä käytöllä olevan Messenger-tilini. Roikun Adiumin kautta Facebook Chatissa, Google Talkissa minut löytää osoitteella aki@h1.fi ja Skype-nimi on akibjork. Jos on asiaa, niin antaa kuulua!

Ei luonnollisestikaan ole optimaalista käyttää kahta eri nappia, mutta tämä nyt on vasta idea. Like-nappulalla on kuitenkin sellainen etu, että se on jo melkein kaikilla verkkosivuilla. Minkään mikromaksamisen yleistyminen tyssää aina siihen, että ei ole tarpeeksi käyttäjiä, kun ei ole tarpeeksi mahdollisuuksia maksaa, kun ei ole tarpeeksi käyttäjiä…

Käyttäjien ei välttämättä edes tarvitsisi panna rahaa Facebookiin, jos Facebook panisi kunkin käyttäjän “kukkaroon” osan mainosklikkauksista saamistaaan rahoista. Silloin pelkkä liketys voisi riittää toimintona. Potin ei tarvitsisi olla välttämättä käyttäjäkohtainen. Mutta miksi Facebook tekisi niin? Sehän vain jakaisi itselleen muuten jääviä rahojaan pois.

Eli ehkä sitä rahaa pitäisi latoa tiskiin. Mikä sitten siihen ihmiset ajaisi? Mahdollisuus voittaa satunnaisesti jotain? Pro-käyttäjän leima ja badget joita voi ansaita tykkäämällä? Lailla määrätty internet-maksu? Onhan meillä tv-maksukin. Hankalaa, kun kyseessä on globaali ongelma.

Ei se nyt niin helppoa ollutkaan.

Logon suunnitteli ja kuvan otti Jaana Björklund.

Teknisesti sivu on luonnollisesti HTML5-muotoa, mutta toimii myös antiikkisessa IE:ssä. Sivun koodi on pyritty minimoimaan, gzip on käytössä ja kaikki muut hyvät käytännöt huomioitu. Logo on tehty manuaalisesti SVG:llä. Ainakin minulle yllätyksenä tuli, että jostain syystä selaimet lataavat tarpeettomasti object:lla upotetun SVG-logon varmistuksena olevan img:n viittaaman kuvan. Se ei ole tässä tapauksessa mikään ongelma, mutta mielenkiintoinen juttu sinänsä.

H1 on toistaiseksi yhtä kuin minä, joten sivutkin saavat heijastella sitä. Mitä sitä piilottelemaan, että yritys on pieni. Jos asiakas pelkää ostaa pieneltä toimijalta, ei se ainakaan teeskentelemällä ratkea.

Yrityksen tavoitteena ei varsinaisesti ole kasvaa, vaan ensisijaisesti tuottaa onnellisuutta – niin työntekijöilleen kuin asiakkailleen. Kasvua saa toki tapahtua. Niin käy luonnollisesti, jos löydän ympärilleni lisää samoja arvoja jakavia ihmisiä, sekä asiakkaita, jotka haluavat ostaa meiltä työtä. Tähän mennessä olen ainakin itseni työllistänyt enemmän kuin hyvin, joten jonkinlainen kasvu on todennäköistä.

Ensimmäiset reilu pari kuukautta H1 on toiminut kannattavasti ja tavoitteidensa mukaisesti. Omia, erillisiä toimitiloja sillä ei ole, koska työ tehdään joko asiakkaan tiloissa tai kotitoimistossa. Kotitoimisto on kylläkin toistaiseksi sohvan nurkka; kunnollinen työpiste on vasta suunnitelmissa. Kaikki aikanaan: menestyvä yritys keskittyy tuottavan työn tekemiseen eikä tuollaisiin epäolennaisuuksiin.

Ensimmäiset työtehtävät ovat olleet kaikkea maan ja taivaan välillä. Joitain töitä mainitsekin uusilla sivuilla. Mutta kerrottakoon, etten ainakaan kyllästymään ole päässyt.

Vähitellen on myös alkanut muodostua käsitys siitä, minkälaista työtä haluan yrityksen tekevän. Ideaali asiakas tuntuisi olevan keskisuuri yritys, jolle verkko on tärkeä tai erittäin tärkeä osa liiketoimintaa ja joka haluaa maksimoida verkkopalvelunsa tuoton. Muunkinlaiset asiakkaat toki kelpaavat, erityisesti konsultointityyppisiin asiakassuhteisiin.

Oikeastaan ei kannata rajata mitään vielä tässä vaiheessa. Kaikki on mahdollista.

TNS Metrixin julkiset viikkoluvut muuttivat uuden mittaustavan myötä jonkin aika sitten uuteen osoitteeseen. Valitettavasti vanhoja, suoraan vertailukelvottomia lukuja ei tuotu uusille sivuille. Ja aivan vastikään TNS alkoi uudelleenohjata vanhasta osoitteesta uuteen, joten vanhoihin lukuihin ei enää ole suoraa pääsyä. Mikä neuvoksi?

Vaikka viikkotason lista onkin nyt kadotettu ja kävijälukuja ei voi verrata suoraan, sivustokohtaiset trendit ovat edelleen kiinnostavia. Niihin pääsee onneksi ainakin vielä suorilla linkeillä. Kaivoin Googlen välimuistista linkit talteen. Alla 30 ensimmäistä saittia, mutta koko sivukin on tallessa.

Aikaisempien vuosien lukuja pääsee kömpelöhkösti katselemaan muokkaamalla www-osoiteesta vuosi- ja viikko-parametreja.

Huomaa, että Googlen välimuistissa oli viikon vanha (32) sivu, eli viimeisen viikon (33) luvut näkee vain muokkaamalla saittikohtaisen sivun osoitetta. Tämä ongelma ei koske alla olevaa listaa.

Lähetin tästä ongelmasta palautetta TNS:lle. Jään odottelemaan, mitä he vastaavat. Toivotaan, että TNS:llä on mielenkiintoa palauttaa luvut jotenkin fiksummin selattaviksi. Tai ainakin hienovaraisuutta olla tuhomatta niitä kokonaan.

Kesäkuisessa omaa historiaani alalla luotaavassa kirjoituksessani totesin:

Edelleen ehkä isoin este hyvien verkkopalveluiden tekemisessä on se, että designerit eivät keskimäärin “ymmärrä tekniikkaa” ja koodarit ymmärtävät hyvin harvoin mitään verkkopalveluista. Tämä lokeroituminen ei ole muuttunut mihinkään, pikemminkin pahentunut, osittain varmaan asioiden monimutkaistumisen takia.

Kärjistetäänpä vähän: Designerit tapaavat keskittyä nätteihin taustoihin tai logon viilaamiseen, ja vaikka se rekisteröitymislomakekin ehkä hätäisesti piirretään, ei interaktiota suunnitella läheskään virheilmoituksiin asti. Kun ei se määrittelydokkari tai konseptisuunnitelmakaan näihin asioihin ottanut kantaa, niin miksi vaivautua.

Jatketaan kärjistäen: Käytännössä siis käyttöliittymiä suunnittelevat – tai siis eivät suunnittele vaan vain pakon alla tekevät – ohjelmoijat, joiden osaamiseen tai kiinnostuksen kohteisiin käyttöliittymäsuunnittelu ei kuulu. Ohjelmoija tyypillisesti vähät välittää, jos puhelinnumero on syötettävä juuri hänen haluamassaan formaatissa tai että tietoa kysytään paljon enemmän kun oikeasti tarvitaan.

Tarpeeksi hiomalla tietysti saadaan silti hommat kuntoon, mutta se tulee kalliiksi ja jää käytännössä siksi tekemättä loppuun asti. Tämä on siis tehokkuusongelma, jos käyttöliittymän detaljitason suunnitteluun tarvitaan joko erillinen ammattilainen tai pallottelua kompetenssilta toiselle.

Eikä toisaalta asiakas tai työnantaja useinkaan edes osaa vaatia tällaista laatua. Sitä vartenhan hän sitä työtä ammattilaisilta ostaa.

Näkisin mielelläni lisää käyttöliittymäohjelmoinnin ammattilaisia. Se ei ole välttämättä puhtaan ohjelmointiteknisesti kaikkein haastavin alue (joskaan ei triviaaleinkaan), mutta laaja-alaista osaamista se vaatii sitäkin enemmän. Käyttöliittymäohjelmoija on se henkilö, joka tekee lopullisen interaktiosuunnittelun ja voi tehdä fiksua iteraatiota itsenäisesti eli kustannustehokkaasti.

Web-käyttöliittymäohjelmointi voi olla äärimmäisen haastavaa ja palkitsevaa työtä. Itse olen kokenut juuri tämän osan työstäni ehkä kaikkein mielenkiintoisimpana alueena sen monipuolisuuden takia. Olen kuitenkin kokenut itseni samalla tässä tehtävässä kovin yksinäiseksi. Melkein kaikki tuntemani ammattilaiset ovat joko design-suuntautuneita ja osaavat korkeintaan vähän netistä kopioida ja kevyesti muokata JavaScriptiä tai sitten puhtaita ohjelmoijia, joita käyttöliittymä ei kiinnosta haasteena tai jopa pelottaa.

Viime vuosina käyttöliittymäohjelmointi on tarkoittanut yhä enemmän JavaScriptiä. Lisäksi syvällinen osaaminen CSS:stä, HTTP:stä, selaimen toiminnasta ja palvelinohjelmoinnista sekä käytettävästä ohjelmointikehyksestä ja mahdollisesta julkaisujärjestelmästä ovat välttämättömiä. Näiden teknisten kykyjen rinnalle tarvitaan humanistisempia tieteitä: käyttöliittymien suunnittelu, verkkokirjoittaminen, hakukoneiden hyödyntäminen, informaatioarkkitehtuuri, saavutettavuus…

Aikana, jolloin kaikki tuntuvat haluavan vain suunnitella eivätkä tehdä itse mitään, miten saisimme ihmiset innostumaan itse käyttöliittymän tekemisestä?

Alan tapaaminen: Frontend Finland

Ikään kuin vastauksena kysymykseeni Suomessa päätettiin vastikään perustaa Frontend Finland -niminen organisaatio, joka pyrkii kokoamaan yhteen suomalaisia alan osaajia. Perustajien mukaan Suomessa on paljon alan osaamista, joka ei kuitenkaan täällä saa ansaitsemaansa huomiota. Olen siitä samaa mieltä, että huomio puuttuu, mutta oma syymme: emme ole pitäneet tarpeeksi meteliä.

Frontend Finlandin ensimmäinen tapaaminen järjestetään 15. syyskuuta. Aiheet vaikuttavat kiinnostavilta. Odotan innolla, että saan tavata ison nipun samanhenkisiä kollegoita! Tapaamisesta luvassa raporttia Vierityspalkin puolella.