Spesialistikoodari hätääntyy

Tuottava alusta on alusta, jolla saa entiseen verrattuna tehtyä asioita halvalla ja nopeasti, mutta kuitenkin riittävän laadukkaasti. Yhden teknologian spesialistikoodari hätääntyy, kun tuottava alusta kasvattaa suosiotaan. Hän haluaa todistaa tarpeellisuutensa.

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.

VR arpoo lähtöaikoja

Viime viikolla tein virheostoksen VR:n verkkokaupassa. Ensimmäisellä ruudulla kysytty junavalinta vaihtuikin kolmannella aikaisemmaksi, enkä ollut tarkkana maksamisvaiheessa. Vaadin palautetoiminnon kautta rahojani takaisin, mutta en saanut tähän päivään mennessä vastausta.

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.

Löydettävyyden vaikutus olemattomuuteen

Postilaatikkoon tipahti Eat.fi:n tiedote:

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.

Ravintolanäkymä m.eat.fi:ssä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.

Luettua: Responsive Web Design

Responsive Web Design on Ethan Marcotten tuore, lyhyt, mutta asiapitoinen kirja siitä, kuinka rakentaa verkkosivuja, jotka eivät ole sidottuja tiettyyn pikselileveyteen.

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.

Reusing the fastest TCP connections on Firefox 5 →

http://blog.httpwatch.com/2011/06/10/investigating-the-network-performance-of-firefox-5/

HttpWatch blog:

One of the major performance related changes in Firefox 5 is an improvement in the way that keep-alive HTTP connections are re-used. Previously, there was a simple FIFO queue. So if Firefox ever tried to reuse a TCP connection it would simply use the connection that had been idle for the longest period of time.

However, not all connections are equal. Connections that have transmitted the most data are likely to be faster than those that have only received a small amount of data. This effect is caused by the congestion window mechanism in TCP.