Posted on

Aina kannattaa yrittää

Janne Jääskeläisen purkaus lienee jo kaikille tuttu. Voi olla masentavaa työskennellä paikassa, jossa oma työsuoritus on vain pieni osanen liukuhihnalla. Ihan sama tekeekö työnsä poikkeuksellisen hyvin vai vain tyydyttävästi, kun hihnalla seuraavat keskinkertaisuudet — ihmiset tai ohjelmat — tuhrivat sen kuitenkin.

Tuudittautuminen fatalismiin ei ainakaan paranna tilannetta. Yhden, vaikkakin todennäköisesti pienemmän, organisaation toimintamalliin voimakkaasti vaikuttaneena tiedän, että tie on kivinen mutta äärimmäisen palkitseva. Oma innostus ei riitä, vaan muutkin on saatava mukaan.

Kuitenkaan ei voi olettaa, että kaikki tiimin jäsenet koskaan olisivat samanlaisia “standardinillittäjiä”. Pikemminkin on valistettava työtovereitaan juuri riittävästi, että heidän parhaimmat puolensa saadaan esiin. Joskus tämä vaatii vittumaisen valittajan roolin ottamista, joskus vain faktojen luettelemista ääneen.

Bisnes ei johda mihinkään, jos tehdään vain kuten aina ennenkin. Lupulta innovaatio kuolee ja yritys siinä mukana. Isommat yritykset harvemmin kannustavat byrokraattisella ilmapiirillään yrittämään mitään uutta ja parempaa. Ei yrityksen johto tällaista todellisuudessa tavoittele. Heille asian kyllä voi perustella, mutta ei välttämättä nillittäjän sanavarastolla.

On totta ettei asiakaskaan aina ymmärrä parastaan. Mutta toimittajan se vastuu lopulta on. Mitä jos jättimäisen lentokoneyhtiön koneet tippuisivat taivaalta viikoittain, vaikka keskivertoa lahjakkaampi teini rakentaisi putoamattomia lennokkeja vaivatta? Ei silloinkaan syytettäisi tilaajaa tai prosessia, vaan nimenomaan tekijöitä.

Ihan samanlainen tilanne on nyt web-teollisuudessa. Isot toimittajat eivät osaa, mutta vähintään samalla prosentilla pienet toimittajat tekevät huonoa jälkeä. Se, että pienen organisaation on helpompaa tehdä hyvää jälkeä, ei tarkoita, että pienuus olisi ainoa tapa tehdä laatua. Isommassa organisaatiossa muutokset vain vievät enemmän aikaa. Ei kannata masentua. Pieni vinkki työtoverille aina silloin tällöin tuo ajan myötä ison muutoksen. Jos organisaatio ei ole rajaton, jossain vaiheessa ihan varmasti tapahtuu näkyvää kehitystä.

Standarditietoisuus leviää hitaasti mutta varmasti. Blogeihinkin kirjoittelu vaikuttaa ihan oikeasti, koska eihän tietoisuus itsestään voi levitä. Kärsivällisyyttä. Ennustan, ettei taulukoilla taita muutaman vuoden päästä kuin maakuntien kotskasivuammattilaiset. Kilpailu Google-näkyvyydestä johtaa vähitellen myös ainakin perustasolla saavutettaviin sivuihin. Huippulaadusta saa edelleen maksaa, mutta niinhän se on aina.

Tietysti on asiakkaita, jotka ostavat “meisseli tanassa” hypersurkeita mahdollisimman ison toimittajan megajärjestelmiä, mutta on myös asiakkaita, joille voi perustella erikoisosaamisensa hyödyt. Kannattaa yrittää.

Posted on

Validi vain etusivultaan?

Aina kun joku ison firman saitti saadaan validina ulos, standardipiireissä kohistaan ja iloitaan. Erittäin usein on kuitenkin vaivauduttu siivoamaan ainostaan etusivu. Alasivut voivat olla virheitä täynnä, mutta kukaan ei keksi enää parannettavaa. What more could you want? Indeed.

Esimerkiksi kelpaa tämä nyt kohistava AT&T, jolla tosin ymmärtääkseni oli ennenkin validi etusivu, nyt vain graafinen ilme muuttui. Satunnaisotannalla löysin vain yhden alasivun, joka validoitui. Miksi tavoitella validia koodia vain etusivulla? Siksi, että voisi paistatella alan piirien myötähyminässä? Kehno motiivi, mutta sentään motiivi ohjaa oikeaan suuntaan. Mozilla-kehittäjä Henri Sivosen mainioon listaan HOWTO Spot a Wannabe Web Standards Advocate (via) voisi siis lisätä yhden kohdan.

Posted on

Standardien seuraamisen vaikeus

Kokeiltuaan varsin naiivilla tavalla XHTML:n mukaista MIME typeä Milan Negovan on tullut siihen tulokseen, että application/xhtml+xml:ää ei tulisi käyttää web-sovelluksissa. Perustelunsa ovat tosin aika kehnot.

Selkeä pääsyy Nogovanin niskoitteluun on se, että hän käyttää web-sivujensa taustateknologiana Microsoftin ASP.NETiä ja on ilmeisen mieltynyt sen huomattavasti työtä vähentävään mutta webin rikkovaan Web Forms -malliin. Hän vertaa ASP.NETin valmiskontrolleja valmiiksi leikattuun leipään. Vertaus olisi parempi, jos se ottaisi huomioon sen semanttisen HTML:n irvikuvan, jota ASP.NET tuottaa. Kenties lisäaineet, jotka huolimatta viipaloinnista saavat leivän pysymään tuoreena ja pehmeänä voisivat edustaa sitä puolta. Lisäaineet kyllä hoitavat varsinaisen tehtävänsä, mutta eivät ole erityisen terveellisiä eikä lisäaineleipä enää maistukaan leivältä (toisin kuin ennen vanhaan) vaan kylmältä teollisuustuotteelta. Se kehnoista vertauksista.

Nogovanin esimerkkinä käyttämän ValidationSummaryn tuottama HTML on kammottavaa:

<code><table id="_ctl0_vs" class="vsummary" cellpadding="0"
cellspacing="0" border="0" width="100%">
<tr><td>
<font color="Red">Enter site URL<br></font>
</td></tr>
</table></code>

Edellisen tarkoitus on antaa käyttäjälle palautetta täyttämättä jääneestä lomakkeen kentästä. Asian voisi toki hoitaa tyylikkäämmin, kuten valveutuneet hyvin tietävät. Negovan itkee sitä, että käyttämällä application/xhtml+xml:ää Mozilla ei suostu näyttämään sivua jossa on päätteetön br-elementti. Kuten Anne van Kesteren kommenteissa kysyy, miksi ihmeessä sitten käyttää koko XHTML:ää? Jos välittää enemmän siitä, että oma työ on vähän helpompaa kuin että selaimelle menee vain puhdasta markupia, eikö olisi kaikille palvelus tyytyä HTML 4.01 Transitionaliin? (Ei olisi.)

Seuraava esimerkki on vielä edeltävääkin hirveämpi. Negovan valittaa, ettei ASP.NETin tuottama javascript suostu toimimaan Mozillassa application/xhtml+xml:ää käytettäessä. Kyseessä on ehkä pahin koko ASP.NETin yksittäinen suunnitteluvirhe, jo pelkällä nimellään kauhua herättävä javascript:__doPostBack(), joka muuttaa linkin lomakkeen lähettäväksi javascriptiksi. Paitsi ettei linkki ole missään vaiheessa linkki. En tiedä, kuinka ASP.NETin arkkitehdit osasivat perustella tuon kammotuksen tarpeellisuuden.

A-elementti on tarkoitettu muuttumattomille urleille ja input-elementti on lomakkeen vaihtuvasisältöisille kentille ja nappuloille. Jako on selkeä, eikä sen sotkemisesta seuraa muuta kuin käyttäjien hämmentyminen ja käyttömahdollisuuksien liian tiukka rajaaminen (yritäpä avata tuollainen linkki uuteen ikkunaan tai välilehdelle, turha toivo). Standardien noudattaminen on muutakin kuin validoituvuus, vähän kuten lain kirjaimen noudattaminen on eri asia kuin lain hengen noudattaminen.

Negovan käyttää linkkiä räikeästi väärin etusivullaan olevassa kyselylomakkeessa. Siihen vastaaminen tapahtuu luonnollisesti radio-buttonista vaihtoehto valitsemalla ja sitten lähetyspainiketta painamalla. Sen sijaan vastaukset saa näkyviin linkin näköistä alleviivattua tekstiä klikkaamalla. On typerää, että tuo linkiksi naamioitu skripiti lähettää lomakkeen, joka pitää sisällään Viewstaten eli tilatietoa. Koska sivulla ei ole mitään muuta “tilaa” kuin sen oletustila (paitsi tieto siitä onko äänestänyt, mutta senpä pitäisikin olla tallennettuna keksiin), on ajatus entistä typerämpi. Kuinka vaativaa on kirjoittaa: <a href="default.aspx?results=true">See results</a> ja parametrin perusteella päättää näytetäänkö äänestyslomake vaiko tulokset? Ilmeisesti aivan liian.

Milan Negovan pelkää, että käyttäjien syöttämä epävalidi XML voi rikkoa hänen huolella rakentamansa XHTML-sivun siten, että sen tilalla on selaimessa vain tyly virheilmoitus. Pelko on aiheellinen, muttei tilanteen estäminen ole edes kovin vaikeaa. Ensimmäinen sääntö on olla sallimatta HTML:ää. Tämä tapahtuu HTML-enkoodaamalla ihan kaikki käyttäjien syöte.

Jos on tarve kappalejakoa enemmän mahdollistaa rakenteiden kuvaamista, voi joko rakentaa oman yksinkertaisen kuvauskielen joka parsitaan XHTML-muotoon tai sitten sallia mahdollisimma pieni osajoukko XHTML-elementtejä syötteeseen. Tämä pieni osajoukko on helppo “validoida”, eli käytännössä varmistaa päätöstagien olemassaolo, mitään attribuutteja tuskin tarvitaan. Ja jos todella tarvitaan koko XHTML:n nimiavaruus käyttöön, voi käyttää HTMLTidyä varmistamaan siistin lopputuloksen.

Pelko rikkoutuneesta Citi Bankin sivusta on aiheeton, sillä kyllähän isoilla organisaatioilla on resursseja huolehtia HTML:nsä puhtaudesta. Pienemmät eivät tähän ehkä vielä pysty, mutta tarvittavat ammattitaito leviää kyllä niihinkin. Lopultakin, kyse on vain siitä, että tiettyjä metodeja noudatetaan kaiken sisään saapuvan syötteen suhteen. Tietoturvasta välittävä jo tekee näin joka tapauksessa.

Hassua, että Nogovanin sivujen alaotsikkona on ASP.NET with emphasis on web standards. Ehkä hän on matkinut populäärin lähestymistavan muualta webistä, mutta selvästi näyttää sitä, ettei hän ole alkuunkaan sisäistänyt otsikkoaan.

Posted on

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.