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.

Gmail-kutsuja

Sain viimein erän Gmail-kutsuja jaettavaksi. Jaan kutsut palkintoina niille, jotka parhaiten perustelevat joko puolesta tai vastaan aiheesta Gmailin kaltaiset, vaikeasti saavutettavat, voimakkaasti skriptatut, selainriippuvaiset ja standardien vastaiset verkkosovellukset. Palkitsen parhaat x vastausta, jossa x voi olla myös nolla, jos kunnollisia vastauksia ei tule yhtään.

Lähetä oma vastauksesi kommenttina tähän kirjoitukseen tai sitten palautelomakkeella, jos et tahdo sähköpostiosoitettasi tai mielipidettäsi julkisuuteen.

Lisäys: Okei, kaikilla näemmä on jo Gmail-tili, mutta jos ei ole, niin pelkästään pyytämällä saa.

Suutarin lasten kengät

Jos yhtään seuraa mistä webissä web-kehittäjien ja designereiden parissa puhutaan, niin osaa varmasti mainita esimerkiksi standardien, semanttisesti oikean markupin tai CSS:n käytön puolesta taistelun. Helposti siis luulisi, että ajatusmaailma olisi laajasti omaksuttu. Seuraavassa tuloksia ehdottoman epätieteellisestä tutkimuksesta suomalaisten uusmediayritysten web-sivujen teknisestä laadusta.

Kävin läpi kaikki Rekaksoispisteen Yritysoppaassa listatut yritykset, jotka selkesti mainostavat omilla sivuillaan toteuttavansa web-sivuja. Jätin siis tutkimatta mainos- ja markkinointitoimistot sekä mobiilifirmat ja sensellaiset.

Jokaisen yrityksen kotisivulla tarkastelin seuraavia asioita: mitä Content-Typeä käyttäen sivu selaimelle välitettin, mitä Doctypeä käytettiin jos käytettiin, oliko käytetty XML-julistusta ja kuinka monta virhettä W3C:n validaattori sivulta löysi. Mikäli validaattori valitteli että käytettyä merkistöä ei löytynyt, merkitsin tämän tiedon ylös ja vihjasin sille oikean merkistön tarvittaessa. Mikäli sivusto oli toteutettu kokonaan tai osittain Flashilla, kirjasin sen ylös ja havainnot saitin käyttökelpoisuudesta ilman Flash-pluginia.

Tutkittavia sivuja oli yhteensä 41 kappaletta. Ainoastaan viisi sivua validoitui. Kymmenen sivua ei edes käyttänyt doctypeä, 22 käytti joko HTML 4.01 tai 4.0 Transitionalia, viisi XHTML 1.0 Transitionalia ja yksi XHTML 1.0 Strictiä. Kukaan ei käyttänyt HTML 4.01 Strictiä, mikä saattaisi olla paras kompromissi tällä hetkellä. Kaikki sivut tulivat XHTML:stä huolimatta palvelimelta text/html -MIME-typellä varustettuna, mikä on ymmärrettävää kun valtaselain ei muuta tue.

Yhdeksän sivua käytti joko kokonaan tai osittain Flashiä, mutta vain kolme näistä tarjosi lisäpalikattomille tekstiversiota. Yksi näistä kolmesta oli tiedoiltaan selvästi vanhentunut. Ne kuusi, jotka eivät Flashittömiä huomioineet eivät tarjonneet edes yhteystietoja, vastassa oli pelkkää tyhjyyttä. Aika tylyä.

Tässä valossa täytyy sanoa, vaikka työnantaja ei varsinaisesti uusmediayritys olekaan, että olemme sentään Kynämiehen sivuilla saavuttaneet jotain poikkeuksellista. Tehkää perässä, pyydän.

Lisäys 9.7.2009: Kun tämä kirjoitus julkaistiin, joku tulistui siitä niin paljon, että perusti oikein kokonaisen, anonyymin blogin Bloggeriin, jossa haukkui minut maanrakoon. Blogia ei ole enää olemassa, enkä muista sen sisällöstä juuri mitään. Pelastin alla olevan kommentin, josta käy jotain ilmi.

Code inline vai code behind?

Richard Tallent linkkasi (9.7.2009: toimimaton linkki poistettu) jo vähän aikaa sitten lyhyeen keskusteluun code inlinen ja code behindin välisestä paremmuudesta, jossa oli itse antanut ainoan viisaan kommentin. Muut eivät taida lainkaan välittää siitä millä ennestään pahasti rikkonaista webiä rikkovat.

ASP.NET:in code behind -mallia perustellaan useimmiten sillä, että se mahdollistaa koodin eriyttämisen esityskerroksesta. Tilanne saattoi vielä muutama vuosi sitten taulukko- ja pikselitaiton kulta-aikana ollakin näin. Alati kasvava CSS:n hyödyntäminen on johtanut siihen, että HTML tekee yhä useammin sitä mitä sen suunniteltiinkin tekevän: kuvaa dokumentin rakennetta. Esityskerroksen visuaalinen osa, eli CSS, on jo luonteeltaan erotettu selkeästi sisällöstä, joten ASP.NET:in mallille on käyttöä enää vain pikselitaittoa suosivien ajastaan jälkeen jääneiden kehittäjien käsissä. Kaikki ulkoasumuutokset tehdään CSS-tiedostoon, ja jos HTML:ää on tarve muokata ollaan muokkamassa dokumentin rakennetta. Rakennetta muokattessa myös esityslogiikka on vaarassa muuttua, mikä tekee näistä kahdesta käytännössä erottamattomat.

Toinen Code Behind -mallin käytön perustelu on tuottavuuden lisääntyminen. Se saavutetaan muka sillä, että web designer ja ohjelmoija voivat työskennellä saman sivun parissa toisiaan häiritsemättä. Saavutettava hyöty on todellisuudessa minimaalinen, sillä käytännössä vain kaikkein tarpeellinen esitysrakenteeseen liittyvä koodi jää “kehittymättömimmissäkin” tekniikoissa sivun yhteyteen. Kaikki muu koodi sijoitetaan sivun ulkopuolelle yksinkertaisimmillaan SSI:n avulla, jos suunnittelussa on käytetään edes vähän järkeä.

Visual Studio 2005 tulee ymmärtääkseni tarjoamaan Code In Page -mallia oletusarvoisena, mikä on loistava juttu. Kunhan vain kehittäjäyhteisön enemmistö tajuaisi tämän.

Firefox 1.0:n uudet ominaisuudet

Tapansa mukaan Neil Turner esittelee havainnollisesti Firefox 1.0:n uudet ominaisuudet. Muutoksia on yllättävän paljon, ottaen huomioon, että 1.0:n oli tarkoitus olla pelkkä bugeja liiskaava versio. Ei ihme, että julkaisun ajoitus on siirtynyt vähitellen kesäkuulta elokuulle. Hyvää kannattaa odottaa.

RSS-feedit mukaan ottava lisäys on mielenkiintoinen, mutta kuten Neil toteaa: “It’s quite a basic but potentially useful function”. Safariahan tässä matkitaan, mikä on vain hyvä asia. Toivottavasti vievät ominaisuutta jatkossa pidemmälle.