Kymmenen vuotta webiä tekemässä – mikä on muuttunut ja mikä ei?

Aika tarkalleen 10 vuotta sitten tänään aloitin ensimmäisessä alan työssäni. Päädyin sattumalta kesätöihin ja jäin sille tielleni. Vielä suurempi sattuma oli, että pääsin heti paikkaan ja seuraan, joka pystyi opettamaan paljon enemmän ja nopeammin kuin mikään koulu ainakaan tuohon aikaan. Se olikin hyvä, koska hädin tuskin osasin ohjelmoida jotain yksinkertaista Visual Basicilla ja HTML:ää osasin juuri ja juuri sen verran että olin saanut aikaan kehyksiä käyttävät kotskasivut.

Edelleenkään ei osata

Paljon on alalla muuttunut sitten. Tuolloin yksinkertaisiakin verkkopalveluprojekteja johdettiin kuin mittavia ja kankeita IT-projekteja oli totuttu vetämään. Tai sitten ei paljon ohjailtu, tehtiin vain mikä hyvältä tuntui, mikä saattoi joskus olla ihan järkevääkin. Rahaa kuitenkin poltettiin uskomattoman tyhmiin asioihin, näin jälkikäteen viisastellen.

Itse tekemisenkin osaaminen oli mitä oli. Valitettavasti osaaminen on edelleen mitä on, mutta on onneksi monelta osin silti kehittynyt. Edelleen ehkä isoin este hyvien verkkopalveluiden tekemisessä on se, että (visuaaliset) suunnittelijat eivät keskimäärin ymmärrä koodia ja ohjelmoijat ymmärtävät hyvin harvoin mitään verkkopalveluista. Pahimmillaan koko paketin vielä konseptoi totaalisen verkkoummikko mainosmies. Tämä lokeroituminen ei ole muuttunut juuri mihinkään ja on ehkä jopa pahentunut, osittain varmaan asioiden monimutkaistumisen takia. Ne, ketkä menevät tai ovat menneet tässä vastavirtaan, ovat tai tulevat olemaan voittajia.

Julkaisujärjestelmät kehittyneet yllättävän vähän

(Liian) monta julkaisujärjestelmää rakentaneena ihmetyttää, miten vähän nekin ovat tässä ajassa kehittyneet. Kankeita ja vaikeakäyttöisiä monstereita oli jo tuolloin ja niitä on edelleen, entistä pahempia suorastaan. Naapurin pojan heppoisia viritelmiä on nyt lukumääräisesti enemmän, mutta onneksi sentään ne ovat viime aikoina alkaneet karsiutua.

Uskon, että Ruby on Railsin kehittänyt David Heinemeier Hansson oli vuonna 2005 oikeassa, väittäessään että yleiskäyttöinen julkaisujärjestelmä on mahdoton unelma ja Railsin ja Djangon kaltaiset työkalut ovat ratkaisu. Yleiskäyttöisen julkaisujärjestelmän kuolemaa en silti ennusta. Vanhaan kirjoitukseen “The general-purpose CMS (pipe dreams, part II)” ei valitettavasti voi syvälinkittää ja sen olennainen linkkikin on rikki, joten vaikka nyt mennään vähän aiheesta ohi, niin tässä se kokonaisuudessaan. (Alkuperäinen juttu löytyy arkistosta etsimällä vaikka sanalla “CMS”.)

The general-purpose CMS (pipe dreams, part II)

As t approaches zero, people will realize that many types of software are non-sensical in their generalized form. I believe the time has come to mark a date in the not too distant future for celebrating the death of the general-purpose content management system.

In many ways, I believe it was always a pipe dream. Sort of like the high-level components that the industry has always sought. Or model-driven architecture/CASE tools. I believe all these fantasies can be summarized in a correlation of price and delusion:

The more expensive it is to create fresh software, the more appealing the mirage of generalization will appear.

And I think we’ve already seen the rise of its replacements for smaller segments of generalities. The blog is a much more specialized, much better alternative for a large group of problems that where previously considered content management. The same for the wiki.

We need even more narrow tools. While it’ll never reach zero, t is aiming enough in that direction to expose the fraud of ultimate generalization. So don’t accept the label of content. Nobody produces content. People write reviews, people write news, people write articles, people exhibits photos.

Try to realize, there is no content.

Toisaalta, ensimmäinen julkaisujärjestelmäni jostain vuodelta 2001 olisi edelleen ominaisuuksiensa puolesta ihan riittävä erittäin monelle saitille, jos vain syötteitä osaisi julkaista, eikä takuuvarmasti olisi vaikea käyttää. Paljon omia vanhoja visioitani on toteutumassa WordPressin seuraavassa 3.0-versiossa, joten ehkä toivoa myös ihmisille sopivilla, valmiiksi paketoiduilla julkaisujärjestelmillä on.

Tänään pilvipalveluilla kelvollisen verkkopalvelun tai -kaupan pieniin tarpeisiin ottaa käyttöön jopa ilman asiantuntijoitakin ja hassua kyllä lopputulos on usein monella tapaa paljon parempi kuin jos saman projektin menee tilaamaan isosta IT-talosta räätälityönä. 10 vuotta sitten lopputulos oli melkein poikkeuksetta susi ja GeoCitiesiä kummempia hostattuja palveluita ei tainnut juuri olla.

Liiketoiminta, jatkuva kehittäminen, optimointi ja analytiikka

Uusi liiketoiminta verkossa on kuin mikä tahansa muu uusi liiketoiminta: on erittäin vaikea nähdä ennalta, mikä toimii ja mikä ei. Siksi on kummallista katsella, kuinka lyhytnäköisesti verkkoliiketoimintaa usein kehitetään.

Alustaa valittaessa aliarvioidaan usein räätälöitävyyden merkitys. Kun tehdään oikeaa verkkoliiketoimintaa, on jokaisen pienenkin asian ketterällä säätämismahdollisuudella saavutettavissa todellista kilpailuetua. Homma ei ratkea niin, että kahden–kolmen vuoden päästä ostetaan toinen järjestelmä. Oikeasti räätälöitävät, mutta silti huimaa tuottavuutta tarjoavat sovellusalustat, kuten Django, Rails tai niiden lukemattomat jäljitelmät ovat tässäkin mielessä paljon nykyistä useammin oikea vastaus kuin monet julkaisujärjestelmät.

10 vuotta sitten täysin räätälöityjä saitteja tehtiin paljon nykyistä enemmän. Silloin yleisin virhe oli se, että kaikki tehtiin alusta asti itse, ja vieläpä moneen kertaan. Nyt yleisin virhe on se, että valmiiden tuotteiden liian pitkälle rajatut toimintatavat eivät jousta tarpeeksi, jotta pikkumuutokset olisivat tarvittavan kustannustehokkaita. Käyttäjät siis pannaan edelleen kärsimään, mutta eri syistä. 10 vuotta sitten tosin nuo ongelmat oli edes mahdollista korjata, mikäli asia tarpeeksi harmitti.

Optimointi alana on luonnollisesti sitten vuoden 2000 ottanut valtavia harppauksia, mutta outoa kyllä varsin harvassa ovat ne tahot, joilla optimointi tai analytiikan aito hyödyntäminen on oleellinen osa liiketoimintaa. Jopa ne tahot, jotka tekevät isoa liiketoimintaa verkossa Suomessa, tyytyvät seuraamaan lähinnä kokonaiskävijämääriä ja ovat vähän säätäneet etusivun titleään. Pitkälle ei valitettavasti ole päästy vuosituhannen alun GIF-hittimittareista ja avainsanaspämmistä.

Konseptit ja design

Verkkopalvelut ovat sisällöllisesti parhaimmillaan jotain ihan muuta kuin kymmenen vuoden takaiset meilläkin on verkkolehti -konseptit, mutta edelleenkin keskimäärin varsin ylhäältä alas tyhmälle kansalle -henkisiä. Sosiaalisesta tai yhteisöllisestä puolesta kyllä ollaan kiinnostuneita, mutta uskon, että lopullinen muutoksen aalto on vasta tulossa.

10 vuotta sitten muuta verkkoläsnäoloa ei ollut olemassakaan kuin oma saitti. Korkeintaan bannereita osattiin käyttää liikenteen ohjaamiseen. Tarve verkkopalvelulle tulee jatkossakin olemaan, mutta läsnäolo verkossa ei ole enää siitä kiinni ja on levittäytynyt paljon entistä laajemmalle.

Paljon on muuttunut myös web design. CSS:n yleistyminen on muuttanut niin sivujen koostoa kuin itse ulkoasujakin kahdeksan pikselin huonokontrastisesta fontista ja laatikkoleiskoista vapaampiin ja ilmavampiin tyylikkyyksiin.

Sivuja luettiin keskimäärin alitehoisilla koneilla, 800×600-resoluutiolla ja hitaalla modeemiyhteydellä. Kaikkialla läsnä olevasta Internetistä ei ollut tietoakaan, vaan sinne meneminen oli kokonaan oma rituaalinsa. Nämä tosiseikat oli liiankin helppo unohtaa, kun webiä tekevät eivät juuri kärsineet näistä rajoitteista ja tämä johti usein keskimääräiselle kävijälle lähes käyttökelvottomiin sivustoihin. Edelleen keskimääräinen yhteysnopeus unohdetaan, mutta ongelma on huomattavasti vähemmän dramaattinen.

Mennyttä

Noilta kymmenen vuoden takaisilta ajoilta kaipaan eniten sitä iloa, intoa ja ylpeyttä, mitä ala tuolloin itsestään löysi. Nyt tekeminen ei keskimäärin tunnu olevan enää niin hauskaa vaan paljon kaavamaisempaa ja virastomaisempaa. Rohkeaa yrittämistäkin onneksi on, mutta ryppyotsaisuutta on silti aivan liikaa.

Mutta mennyt aika ei palaa. On tämä intternet edelleen hienointa, mitä voisin kuvitella työkseni tekeväni.

Tekstinkäsittelyn dinosaurukset

Olen ihmetellyt todella pitkään, miksi yhä työstämme dokumentteja ohjelmilla, jotka on suunniteltu pari vuosikymmentä sitten A4-sivuille tulostettavien dokumenttien tekemiseen ja sitten lähettelemme niitä toisillemme sähköpostitse ja kuitenkin luemme ruudulta.

Tuntuu ihan naurettavalta taistella virtuaalisten sivurajojen kanssa ruudulla, kun niillä ei oikeasti digitaalisessa maailmassa ole mitään merkitystä.

Web on keksitty ja yleistynyt jo aika kauan sitten ja olemme kaikki tottuneet lukemaan vaikka blogeja ja wikejä – ihan tavallisten verkkosivujen lisäksi. Miksi niitä ei siis yritysmaailmassa edelleenkään osata hyödyntää kunnolla?

Miksi se yhden A4:n tarjouspyyntö tai lehdistötiedote ei ollut HTML-muotoisessa sähköpostissa itsessään, linkkinä verkkosivulle tai vaikka HTML/MHTML-liitteenä, jos erillinen tiedosto käy enemmän järkeen? Miksi “tekstinkäsittelyohjelmat” eivät ole kehittyneet HTML-dokumenttien editoreiksi? Enkä nyt tarkoita mitään design-työkalua, vaan ihan perusleipätekstiä väliotsikoilla, kuvilla ja taulukoilla. HTML ja CSS kun riittävät tavallisen yksinkertaisen toimistodokumentin merkkaamiseen ja esittämiseen enemmän kuin hyvin.

Tähän ongelmaan verrattuna ei ole kovin suuri edistysaskel saada dokumentteja sähköpostista vaikka SharePointiin.

Firefox 3.1 – tosi-web-nörtin surffauslauta

Pian valmistuvan Firefox 3.1:n lähdekoodinäkymä tarjoaa jännän vaihtoehdon tylsään tyyliteltyjen linkkien klikkailuun:

Lähdekoodissa kaikki suhteellisetkin URI:t ovat toimiviksi linkeiksi tulkittuja ja klikattavissa. Klikattaessa näkyviin tulee linkin kohteen lähdekoodi.

Voiko HTML-lähdekoodi olla niin siistiä, että surffaus onnistuu vaivatta ilman HTML:n tulkintaa?

Mistä tulikin vielä sairaampi ajatus: Olisi melkoisen hieno sellainen WordPress-teema, joka näyttäisi erehdyttävästi lähdekoodinäkymältä.

Vaikeat verkkosovellukset

Verkkosovellukset ovat monella tapaa haastava juttu. En koskaan lakkaa hämmästelemästä sitä välinpitämättömyyden määrää, mitä joka päivä joudun webissä kohtaamaan. Tarkastelen tässä tavallisia verkkosovellusten sudenkuoppia. Ai mikä on verkkosovellus? Se on verkkosivusto, joka hyödyntää palvelinpään ohjelmointia. Luokittelisin siis kaikki ei-staattiset sivustot sovelluksiksi.

Verkkosovellukset ova haastavia siksi, että ne ovat syntyneet melkein suunnittelematta, webin suosion luontevana jatkona. Niitä on opittu rakentamaan aikana, jolloin web muuttui lähes joka päivä. Tilanne on nyt radikaalisti toinen, kehitys on lähes pysähtynyt. Nyt on jo korkea aika unohtaa jollekin tietylle selaimelle ohjelmointi ja keskittyä standardien noudattamiseen.

JavaScript ja JavaScript tappelivat, kumpi voitti? Kaikki hävisivät

WWW toimii mainiosti, kun dokumenttimuotoista tietoa (hypertekstiä) selataan. Yksinkertaiset haku- ja palautelomakkeet mahtuvat mukaan melko luontevasti, mutta ongelmia tulee niissäkin jo tavanomaisessa pakollisten kenttien tarkistuksessa. Tämä johtuu tietysti JavaScriptista, joka toimii vähänkin vanhemmilla selaimilla kovin epäyhtenäisellä tavalla, jos lainkaan. JavaScriptiin varaan siis ei voi laskea yhtään mitään olennaista, jos haluaa, että sovelluksesta tulee mahdollisimman saavutettava. Ja miksei haluaisi?

Tämä ei tietenkään tarkoita sitä, että JavaScriptiä ei voisi käyttää, sitä on vain käytettävä toisarvoisiin toimiin, joita ilman verkkosivut ovat täysin käyttökelpoiset. Google ei ole samaa mieltä, vaan on rakentanut Gmail-sovelluksen, joka hyödyntää mm. JavaScriptiin (ECMAScript) kuulumatonta IE:n XMLHttpRequest ActiveX -objektia tai Mozillan XMLHttpRequest-objektia. Tällä saavutetaan sovelluksessa varsin vähän, lähinnä joka toinen sivulataus ei tavallisen puolen sekunnin sijaan vie lainkaan aikaa. Ottaen huomioon, että tätä varten sisään kirjauduttessa odotellaan useamman sekunnin ajan JavaScript-kikkareiden latautumista, saavutettu hyöty on jossain minimaalisen ja negatiivisen välillä. Tämän takia kaikista maailman selaimista vain kolme (Win-IE:t, Mozilla-pohjaiset ja Safari) kelpaa Googlelle.

Googlen valintaa perustellaan sillä, että Gmail ei ole perinteinen verkkosivu vaan sovellus, joka nyt vain sattuu toimimaan selaimissa. Perustelu olisi jotenkin hyväksyttävissä, jos Gmail saavuttaisi jotain poikkeuksellista hyötyä selainkohtaisten toimintojen hyödyntämisellään. Koska se ei sitä tee, menettää argumentti merkityksensä.

On ironista, että itse Googlen päätuote, hakukone, olisi Gmailin sivuilla täysin hukassa. Mikä onni, että palvelu vaatii sisäänkirjautumisen! Kummallista on myös, että Googlen Blogger-porukka on saanut kasaan erittäin kelvon verkkosovelluksen, joka hyvin pienillä korjauksilla toimisi vaikka vanhoilla Netspaceilla. Tuota ammattitaitoa ei selvästi ole osattu jakaa.

Suurin syy vältellä JavaScriptin käyttöä ei edes ole sen vaihteleva selaintuki. Aikana, jolloin tietoturva-aukkoja etsitään ja hyödynnetään kiihtyvällä tahdilla on jatkuvasti hetkiä, jolloin aukko on löytynyt muttei vielä paikattu. Usein aukkojen hyödyntämistä ei voi estää kuin kytkemällä kaiken aktiivisen sisällön JavaScripteineen pois päältä. On siinä selittelemistä, kun toimenpiteen jälkeen verkkokaupasta ei voikaan enää ostaa mitään.

Hooämteeäl vai mikälie

JavaScript ei ole ainoa ongelma. Jo niinkin perusasia kuin HTML tuottaa monille sovellusten rakentajille vaikeuksia. Ylimääräisen javascriptauksen pois jättäessään Google ottaisi menettävänsä nopeushyödyn helposti takaisin siistimällä HTML:äänsä. Se sisältää nyt antiikkista font-size-table-kakka-HTML:ää, sivuun sisällytettyä CSS:ää ja JavaScriptiä ja muuta massiivisin turhaa tavaraa, jota liikutellaan putkea pitkin ilman mitään järkevää syytä. Googlen tavaramerkkiulkoasu on niin askeettinen, ettei sen kuvaaminen puhtaalla CSS:llä tuottaisi edes amatöörille vaikeuksia.

Jäljestä päätellen tyypillinen Visual Studion designeriä käyttävä ASP.NET-koodaaja ei edes katso kehittimen tuottamaa HTML:ää. Yllättävän monet ohjelmoijat pitävät HTML:ää merkityksettömänä yksityiskohtana, suorastaan häpeällisenä pakkopullana, jota ei kehtaa opetella ainakaan alkeita enenpää. Mahtaako se johtua siitä, että HTML:ää vääntävät eivät ole uusmediakuplan pamahdettua kovassa huudossa, en osaa sanoa.

HTML kuitenkin on tärkeä. Siihen vähän huomiota kiinnittämällä tehdään sovelluksesta kuin sovelluksesta melkein millä tahansa selaimella käytettävä ja sutjakkaasti latautuva. Jokaisen web-ohjelmoijan tulisi osata vähän enemmän kuin perusasiat HTML:stä. CSS:n vääntämisen voi jättää visuaalisesti lahjakkaammille, ja keskittyä dokumentin rakenteen kuvaamiseen. Sen ohjelmoija osaa, jos kuka.

Näinhän se tehdään, eikö?

Kolmas tyypillinen ongelma on, että web toimii niin kovin eri tavalla kuin käyttöjärjestelmän työpöytä. Se mitä käyttäjä näkee ei olekaan koko ajan ohjelmoijan hallittavissa. Työpöytäsovelluksia tehneen on vaikea hyväksyä sitä, että kun sivu on latautunut selaimelle se pysyy siellä kunnes käyttäjä tekee jotain. ASP.NET:in kiero Web Forms -malli koettaa piilottaa webin todellisen olemuksen käväisemällä palvelimella joka välissä. Ajatus on nokkela, mutta tuloksena on ongelmia, joita olen monta kertaa jo käsitellyt. Riittänee, että sanon, ettei ymmärtämättä syvällisesti webin toimintatapaa voi ASP.NET:in kanssa tehdä hyväksyttävää jälkeä.

Yksi työpöytäajattelun muoto ovat popupit ja varsinkin niiden ajattelematon käyttö. Popup-blokkereiden räjähdysmäinen kasvu Windows XP SP2:n myötä onneksi pakottaa edes osittain luopumaan moisista käytönvaikeuttajista. Silti vielä monet merkittävät suomalaiset sivustot hämmentävät käyttäjää rikkinäisellä toiminnallisuudellaan.

Webin toimintatapaa ei kannata ajatella esteenä. Sen kiertämiseen ei kannata käyttää kauheasti energiaa, koska samalla helposti rikkoo toiminnallisuuden joillakin selaimilla. On osattava tunnustaa, että joidenkin asioiden tekeminen verkossa ei välttämättä onnistu mitenkään järkevästi. Kenties sovelluksen tekeminen verkkoon ei silloin ole hyvä ajatus ollenkaan. Toisaalta myös hankalaa tapausta kannattaa miettiä toisenkin kerran, josko webille luonnollisempi toteutustapa tulisi mieleen vasta toisella yrittämällä.

Kaikki verkkoon materiaalia tuottavat sisällöntuottajasta ohjelmoijaan ovat vastuussa siitä, että tuotos toimii parhaalla mahdollisella tavalla verkossa. Aivan kuten verkkokirjoittamisessa on otettava huomioon verkko mediana on web-ohjelmoijankin mietittävä tarkkaan mitä käsistänsä päästää. Webissäkin pitäisi ottaa käyttöön lehdistä tutut apinalaatikot, jotta vastuullisia olisi helpompi hauk… öö.. valistaa.

Mikä ASP.Netissä on vikana

Tällaiset ongelmat (toimimaton linkki poistettu 9.7.2009) ja niiden ratkaisut saavat minut välillä repimään hiuksiani. Selvästi sekä kysyjä että vastaaja ovat ymmärtäneet väärin koko webin toiminnan. Tilattoman webin pakonomainen muokkaaminen toimimaan kuin VB:n lomakkeet johtaa vain lukukelvottomaan, tehottomaan ja typerään koodiin. Kyseisessä tilanteessa voisi kenties harkita vaikkapa sellaista uutta keksintöä kuin <input type=”reset”/>.

Netti on pullollaan ohjelmointivinkkejä, ja .NET tuntuu keränneen valtavan määrän eritasoisia ohjelmoijia teksturin ääreen. Intialasen Saravana Kumarin artikkeli Redirecting User to Login Page After Session Timeouts on yksi huonoimmista koskaan lukemistani. Kirjoittajan eduksi sanottakoon, että asia on esitetty ihan selkeästi. Missään vaiheessa hän ei kuitenkaan ole ilmeisesti tullut ajatelleeksi, että artikkelissa ei ole mitään järkeä. Mies on toisaalla sivuilla esitellyn mukaan kerännyt kasan Microsoftin sertifikaatteja. Katosi moisten arvostus minulta ennätysajassa.

Ai mitäkö artikkelissa on vikana? Muun muassa se, että käyttäjältä kysymättä sivun uudelleen lataaminen on hyvin todennäköisesti erittäin ärsyttävää. Toisekseen se, että joku yksittäinen sivu on ollut selaimessa auki session keston ajan ei vielä tarkoita, ettäkö sessio olisi todella päättynyt. Käyttäjällä kun voi olla auki vaikka kuinka monta ikkunaa. Jos yksi niistä jää vähän pienemmälle huomiolle joksikin ajaksi ja sitten sen pariin palataan, ei väärä ilmoitus katkenneesta sessiosta ole järkevä. Jälleen kerran webin todellinen luonne on täysin hukassa VB-ohjelmoijalta.

Tätä webin luonnon vastaista, huonoa HTML:ää tuottavaa, potentiaalisten tietoturva-aukkojen täyttämää ohjelmoitimallia ei Whidbeykään tule korjaamaan. Sitä odotellessa käytän vain ja ainoastaan ASP:Repeateria ja hyvin säästeliäästi mitään "palvelinpäässä ajettavia" kontrolleja. Niinkin käytettynä ASP.Net hakkaa vanhan ASP-mallin mennen tullen.