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.

Safari RSS

Apple demosi hiljattain OS X:n 10.4-version Safariin integroitua RSS-lukijaaa. (Steve Jobsin alustuspuheenvuoro Worldwide Developers Conference -tapahtumassa näyttää kenties hiukan paremmin Safari RSS:n käytännössä. Safarin esittely alkaa aika tarkkaan tunnin kohdalla. (Muutos 9.7.:linkki videoon poistettu toimimattomana)) Näyttää siltä, että Apple suorastaan innovoi selainmarkkinoilla, jossa viimeiset vastavan kokoiset muutokset taisivat olla ties kuinka monta vuotta sitten Operaan tuodut tabit ja hiirieleet.

Niin pitkään kuin olen RSS-feedeistä tiennyt, olen ollut sitä mieltä (ja muistaakseni niin totesinkin vanhan blogini höpinöissä), että feedien seuraaminen on luontevinta juuri selaimen yhteydessä. Operalla selvästi – tuoreen 7.5-version alkeellisen feedilukijan myötä – ollaan samaa mieltä, mutta ei olla ylletty ollenkaan sille tasolle mille voitaisiin.

RSS-lukijan integrointi sähköpostisovellukseen on toiseksi luontevin ratkaisu, onhan feedien esi-isällä, uutieskirjeellä pitkät perinteet ja vankat kannattajansa. Erillissovellus tai sähköpostisovellukseen integroitu RSS-lukija joko ryhtyy selaimen kanssa kilpasille, eikä pärjää alkuunkaan tai jää sovelluksena torsoksi voiden esittää vain pienen osan feedien tarjoamasta ja viittaamasta sisällöstä.

On juuri ja juuri hyväksyttävää joutua seuraamaan linkkiä ulkoiseen selaimeen sähköpostiviestistä, koska niin tapahtuu suhteellisen harvoin. Tyypillinen blogikirjoitus sisältää vähintään muutaman linkin, jolloin hyppiminen sovelluksesta toiseen käy liian raskaaksi ja tuo käytettävyysongelmia. Toinen vaihtoehto, linkin avaaminen lukijasovelluksessa, on vähintään yhtä kömpelöä ja toimii vain siinä teoreettisessa tilanteessa, jossa linkin takaa ei enää löydy kiinnostavia linkkejä.

Safari-demo osoittaa, että feedit voi tuoda selaimeen ihan toisella tavalla kuin jonain bookmarkien uudelleenlämmittelynä. Feedit elävät Safarissa luontevana osana selailukokemusta, varsinaisen saitin käyttöä tukevana palveluna. Ennustan, että Safarin ratkaisua tullaan kopiomaan rankasti. Sitä ennen alan tähyillä kohtuuhintaisia Macceja.

Update

Netscape elää. AOL aikoo päivittää Netscapen. (via Gemal’s Psyched Blog)

OpenOfficen versio 1.1.1 on ladattavissa. Kyseessä on bugikorjauspäivitys, mikä todella on tarpeen. Muutaman dokkaria vääntäneenä en paljon muuhun ole törmännytkään, paitsi ehkä kehnoon käyttöliittymään.

Ensi viikolla alkaa hartaasti odotettu loma, pääsen vääntämään tosissaan blogikonettani. Suunnitelmaa väkertäessä pääsin ihan innostumaan.