LibraryThing on kirjoihin keskittynyt web-palvelu, jossa yhdistyy kirjahyllyn teosten tiedot, kirjaston hakukone ja lukemisen seuranta. Perustoiminnot löytyvät kirjojen lukemiseen liittyvistä asioista ja osittain sosiaalisista aspekteista kuten lukijoiden kirja-arvosteluista ja keskusteluista. Kirjojen listauksen ja lukuaikojen lisäksi teoksia voi luokitella kategorioihin kuten “luettavana”, “lukulistalla” ja “luetut” ja määritellä niitä tagien avulla. Kirjojen tietojen syöttö onnistuu esimerkiksi ISBN-numeron perusteella ja ne haetaan muun muassa Amazonista tai jopa Helsingin alueen kirjastoista. Kätevää. LibraryThingin ilmaiseen käyttäjätiliin saa talletettua 200 kirjan tiedot ja rajaton määrä irtoaa pienimmillään dollarilla vuodessa ja eliniäksi 19 dollarilla.

Olin jo aikoinaan miettinyt kirjojen listaamista LibraryThingissä, mutta koska palvelun ulkoasu ei ollut niitä hehkeimpiä ja tarpeet eivät siihen pakottaneet, jäi palvelun käyttöönotto tekemättä. Ei LibraryThing edelleenkään ole ulkoasultaan mihinkään muuttunut. Palvelu on toteutettu perinteiseen insinöörimäiseen tyyliin “tekee kaikkea mahdollista, vaikka käyttäjä ei haluisi” ja käytettävyyteen ei ole panostettu ollenkaan. Vanhanaikainen ja vaikeaselkoinen ulkoasu häiritsee edelleen palvelun mielekästä käyttöä, mutta alkutotuttelun jälkeen ei kuitenkaan liikaa. Ulkoasua voi jonkin verran muokata haluamakseen, mutta itselle tarpeettomia elementtejä ei saa kokonaan piiloon. Toiminnoiltaan LibraryThing on kattava ja erilaisia asetuksia ja toimintoja on runsaasti, eikä kaikkien tarkoituksesta ole aivan selvyyttä. Oikeastaan LibraryThing on aika sekava kokonaisuus, mutta ilmeisesti toimiva sellainen, sillä aktiivisia käyttäjiä sillä on enemmän kuin muilla vastaavilla palveluilla.

Muutamia ruudunkaappauksia LibraryThingin oleellisista osista:

Oma kirjahyllyni palvelussa on vielä aika vajavainen, mutta pitänee jossain vaiheessa luoda peräkkäistiedosto lukemistani kirjoista ja syöttää hyllyyn. Oman kirjahyllynsä tiedot saa tuotua csv- ja xls-muotoihin, joten tiedot eivät järjestelmään häviä, ja kirjahyllyyn saa vietyä kirjoja erilaisissa muodoissa. Tällä hetkellä palvelu tuntuu toimivan omiin käyttötarkoituksiini. Käyttäjäkunta ja “kehitystiimi” on aktiivinen, sillä aika nopeasti widgettien toiminnassa ollut omituisuus korjattiin, kun sellaisesta LibraryThingin foorumilla raportoin. Nyt Kirjasto-sivuni näyttää oikein eri kategoriaan merkityt kirjat.

Tietenkin netissä on tarjolla useita erilaisia kirjastosovelluksia, kuten Goodreads, mutta koska olen enemmän kiinnostunut kirjoista, joihin juuri kirjastonhoitajien kehittämä LibraryThing on keskittynyt, en jaksanut sosiaalisiin puoliin keskittynyttä Goodreadsia testata. Ja kun yhden palvelun on aikanaan valinnut, on kynnys vaihtamiseen suuri, vaikka tarjolla olisi tuonti- ja vientitoimintoja. Goodreadsin ja Librarything eroista on myös hyvin valaiseva kirjoitus, jonka kommentit ovat myös lukemisen arvoisia.

Usability Post kysyykin, pitäisikö Web-sovelluksilla olla yhtenäinen käyttöliittymä, eli ulkoasu näyttäisi ja toimisi visuaalisesti samoilla periaatteilla, kuten työpöytäsovelluksissakin eri käyttöjärjestelmissä sovellukset ovat usein yhtenäisiä keskenään. Tutut toiminnot näyttäisivät samoilta eri Web-sovellusten välillä, kun nyt painikkeiden ja komponenttien ulkoasut vaihtelevat enemmän tai vähemmän eri sovellusten välillä.

On totta, että sitä toivoisi sovellusten toimivan edes suurin piirtein samoilla periaatteilla, ettei aina tarvitsisi arpoa miten asiat nyt tässä toimivatkaan, mutta yleisesti ottaen on vaikea nähdä, että eri Web-sovellukset näyttäisivät peruspiirteiltään samanlaisilta, toimisivat samalla tavalla tai käyttäisivät samoja komponentteja. Web on visuaalisesti toinen maailma verrattuna työpöytäsovelluksiin, joka myös heijastuu sovellusten toimintoihin. Webin osalta ei oikeastaan odoteta, että eri sovellukset näyttäisivät yhtenäisiltä, vaan ollaan jo totuttu, että jokaisen sovelluksen kohdalla pitää aina oppia uudestaan perustoiminnot ja logiikka. Onneksi suunnittelijat tekevät sovellukset usein helposti opittaviksi ja joissa asiat toimivat kuten niiden olettaa toimivan. Tai ainakin näin haluaisi uskoa, sillä todellisuus on välillä aivan jotain muuta.

Kun asiaa ajatellaan pienemmällä skaalalla, olisi sovelluskehittäjällä hyvä olla karkealla tasolla välineet yhtenäisen käyttöliittymän toteuttamiseksi, ainakin saman asiakkaan sovellusten osalta. Toki usein saman kehittäjän sovelluksissa toistuvat samat ratkaisut ja uudestaan käytettävät palikat, joilla yhtenäisyyttä syntyy kuin itsestään. Miksi keksiä asioita uudestaan, kun ne ovat jo kerran toteutettu, ellei asiaa keksi “paremmin”. Suunnittelun ja ratkaisujen avuksi löytyy myös apuvälineitä, joilla visuaalista ilmettä ja sovellusmaista toimintaa voidaan tukea.

Webissä ei ole yhtä ja oikeaa tapaa toteuttaa asioita, vaan monet ratkaisut ovat yhtä hyviä. Mallia voi ottaa esimerkiksi useilta suunnittelumalli-sivustoilta kuten UI Patterns, YPatterns ja UI Pattern Factory. Lisäksi erilaiset komponenttikehykset kuten JQuery UI ja Java EE -maailmassa RichFaces ja PrimeFaces tarjoavat omia ehdotuksiaan toiminnoille. Vaihtoehtoja on monia ja lopputulos on usein eri ratkaisujen yhdistelemistä, jolloin sovellus koostuu useista erilaisista käyttöliittymäratkaisuista. Harvoin eri valmiiden ratkaisujen mallit toimivat suoraan omiin tarpeisiin nähden ja niitä joudutaan vähintäänkin visuaalisen ilmeen osalta virittelemään.

Koska Web perustuu pohjimmiltaan HTML:ään ja CSS:ään, voidaan valmiita komponentteja yleensä muokata ulkoasultaan tarpeiden mukaan ja soveltaa toisaalla havaittuja hyviä asioita. Esimerkiksi Web-sovelluksen käyttöliittymää varten voidaan soveltaa Cappucino tai Sproutcore -kehysten Creative Commons Attribution Share-alike -lisenssin alaisuudessa olevia Ace- ja Aristo-teemoja, jotka näyttävät siisteiltä ja tarjoavat yhtenäisen ulkoasun eri komponenttien välille.

Molemmat teemat näyttävät nykyaikaisilta ja niillä on enemmän yhteistä kuin eroa, jonka voi todeta lyhyestä vertailusta. Enemmän teemojen toiminnasta saa selville, kun vierailee teemojen demosivuilla. Sproutcoren Ace-teemasta on havaittavissa yhtäläisyyksiä OS X:n Aqua-teemaan ja SproutCoren kehitys onkin Applen sponsoroimaa. Cappucinon Aristo-teema ei ole niin silmiinpistävä kuin Ace, keskittyy näyttämään hyvältä sekä Windowsissa että OS X:ssä ja sopii paremmin vakavampiin sovelluksiin.

Molempien teemojen soveltuvuus omaan käyttötarkoitukseen riippuu toteutettavasta sovelluksesta, mutta niistä voi ainakin ottaa hieman mallia, miltä peruskomponentit voisivat näyttää. Cappucinon Aristo-teema on hieman helpommin otettavissa testiin ja se on saatavissa PSD -kuvina ja kolmannen osapuolen CSS 3 toteutuksena. Sproutcoren Ace-teema löytyy vastaavasti vain sprite-kuvina, joten teemaus pitää hoitaa itse loppuun, mutta se tarjoaa kattavamman valikoiman eri komponentteja ja malleja.

Ikävä tosiasia valitettavasti on, että sovelluksen ulkoasun eteen joudutaan aina askartelemaan enemmän tai vähemmän. Esimerkiksi jos sovelluksessa otetaan käyttöön jokin valmis komponentti, pitää sen ulkoasua joko muokata vastaamaan muuta sovellusta, tai käyttää valittua kirjastoa kaikilta osin jokaisen komponentin kanssa, jolloin eroavaisuuksia on mahdollisimman vähän. Valituista ratkaisuista riippuen tämä on enemmän tai vähemmän helppoa. Esimerkiksi JQuery UI:n komponenteille voi määritellä haluamansa ulkoasun kätevästi Theme Rollerin avulla, mutta vastaavasti samanlainen teemanrakentaja tarvittaisiin myös RichFaces-komponenteille, joiden teemaus on suhteellisen työlästä ja osittain arpapeliä. Muutenkin aina tuntuu, että useat valmiit ratkaisut eivät toimi kuten niiden haluaisi toimivan, eikä niitä usein voi myöskään helposti muokata riittävällä tasolla.

Kaikenkaikkiaan Web-käyttöliittymä voi näyttää upealta, jos siihen viitsii panostaa, mutta Web-sovelluksilla ei mielestäni tarvitse olla yhtenäisiä periaatteita. Web on monimuotoinen ja asiat saavat toimia, kuten ne parhaimmikseen näkee, kunhan ne silti toimivat loogisesti ja ymmärrettävästi. Toki yhtenäiset ratkaisut helpottavat käyttäjän elämää. Toisaalta Webin käyttöliittymät eivät helposti vertaudu perinteisiin työpöytäsovelluksiin, ainakaan nykyisillä teknologioilla ennen HTML5:n ja CSS 3:n yleistymistä, joten sallittakoon niille myös omat tyylinsä, kunhan ne ovat hyvällä maulla toteutettuja.

Pitääkin tässä edistää työlistalle hautautunutta tehtävää jalostaa omaa visuaalisesti yksinkertaista komponettiteemaa eteenpäin ja rakentaa vastaava teemaus myös RichFaces-komponenteille, jolloin asiakkaan sovellus saisi vielä nykyistä yhtenäisemmän ulkoasun.

Kokonaisuutena työ pohjaa viime syksynä tekemääni kandidaatin työhön, jossa käsittelin aihetta hieman laajemmin ja pintapuolisemmin. Tuolta perustalta oli helpohkoa jatkaa diplomityössä ja kohtalaisen nopeasti se työ lopulta valmistuikin, mutta vaati useita iltoja töiden jälkeen puurtamista ja useampia viikonloppuja aherrusta. Lisäksi viimeinen viikko, kun työ oli jo saanut painoluvan ja muutamia kommentteja ohjaajilta, meni aika lailla dippaa ajatellen ja viimeistellen. Tekstin hiomista, pilkkujen viilaamista ja kirjoitusvirheiden etsimistä. Tuntui, että viimeistely, byrokratian anomusten täyttäminen ja dipan sitomoon saattaminen oli paljon raskaampaa, kuin varsinaisen työn kirjoittaminen.

Tulostuksen, sidonnan ja yliopistolle toimittamisen osalta hoiti Lappeenrantalainen Saimaprint homman hyvin kokonaispakettina. Helpotti paljon aikataulutusta, kun työtä ei tarvinnut luottaa postin harteille tai lähteä itse sitä viemään. Hinnat olivat muistaakseni: mustavalkosivu 0,1e; värisivu 0,7e; sidonta 22,5e/kirja; toimitus yliopistolle 20e; käsittely- ja postikulut jotain. Eihän toi halpaa touhua ole, mutta enemmän sitä olisi palanut rahaa ja aikaa, jos olisi etsinyt halvimman vaihtoehdon ja ajellut yhtenä päivänä vajaat 600 km:iä.

Diplomityössäni käsittelin käyttöliittymän ja sen toiminnallisuuksien prototypointia projektin eri vaiheissa. Alkuosa oli teoriaa eri menetelmistä ja teknologioista, ja käytännön osuudessa käytin mallina viime vuonna ollutta projektia, jonka aikana sovelsin eri prototypointimenetelmiä sovelluksen määrittelyssä, suunnittelussa ja toteutuksessa. Eli alkuun piirtelin paperille hahmotelmia miltä sovellus voisi näyttää ja myöhemmin toteutin käyttöliittymästä mallin HTML:llä. Ihan opettavainen projekti kaikin puolin, jossa myös käytettiin itselleni uusia JSF-teknologioita.

Oikeastaan pitää kiittää tutkintorakenneuudistusta, joka tavallaan pakotti valmistumaan “Wanha tutkinto valmiiksi” -aikataulussa, johon nähden sain kaiken valmiiksi hyvissä ajoin. Koska 31.7.2010 päivämäärän jälkeen voi valmistua vain uuden kaksiportaisen tutkintorakenteen mukaan ja mahdollisesti lisäkursseja suorittaen, on tänä keväänä ja kesänä erityisen paljon valmistuvia. Itsekin olen diplomityötä hautonut useamman vuoden, mutta se vain vaati kunnollisen määräajan, johon mennessä se oli saatava valmiiksi.

Hieman kiireinen aikataulu tosin vaikutti myös työn tieteelliseen laatuun, sillä näin jälkeenpäin kun työtä lueskelee ja katselee, huomaa miten aihetta olisi voinut paremmin ja kattavammin käsitellä. Etenkin käytännön osuuteen olisi voinut lisätä tarinaa prototypointiprosessista ja toteutetuista malleista. No, työ on nyt kuitenkin tehty ja vaikka kaikki tietous ei kansien väliin päätynytkään, on se korvien välissä tallessa. Lisäksi työ ei nyt mitään järisyttävän uutta asiaa tuo prototypoinnista esille, vaan karkeasti sanottuna on katsaus miksi ja miten asioita voi projektissa mallintaa. Kyllähän kaikki tietää, että kynällä ja paperilla on helppo piirrellä kuvia sovelluksesta ja HTML:llä saa paljon aikaan nopeasti verrattuna Java-toteutukseen.

Kandidaatintyöni tapaan kirjoitin myös diplomityön LaTeXilla ja kirjoitusprosessiin soveltuu samat sanat kuin kesälläkin:

Vaikka aivan mutkatonta ei työskentely ollutkaan, oli kirjoittaminen helppoa ja muotoiluihin ei tarvinnut erikseen panostaa. Etenkin viitteiden ja viittausten hallinta oli erittäin kätevää BibTeX:llä: valmiit viitetiedot sai suoraan liitettyä muun muassa ACM:stä ja IEEE Xploresta. Vastaavasti oikoluvun puute teetti hieman lisätyötä ja taulukoiden, sekä kuvien joustava sijainti tekstin seassa hieman ärsytti.

Oikeastaan oli kohtalaisen turhaa kirjoittaa työ LaTeXilla, kun työssä ei kaavoja ollut, mutta kun kerran alkuun oli päästy, niin pitäähän se loppuun asti vängätä. LaTeX-mallipohjaa piti vielä hieman jalostaa muun muassa viiteluettelon, tiivistelmän ja nimiölehden osalta ja pitää siitä julkaistava versio jossain vaiheessa muistaa kasata. Kaikkien kuvien sijoittelu, oikoluku ja työvaiheessa kommentointi ja merkintä olisivat olleet paljon helpompia esimerkiksi Wordilla. Tosin nyt LaTex mahdollisti versionhallinnan ja kirjoittamisen riippumatta käytettävästä koneesta.

Diplomityön valmistuminen päättää myös yhden aikakauden elämässäni. Opiskeluaika on ihmisen elämään suuresti vaikuttava ajanjakso ja ainakin itsellä se tarjosi mukavia hetkiä, uusia ystäviä ja tietenkin paljon uuden oppimista. Hieman ikävä totuus kuitenkin on, että kaikki loppuu aikanaan ja on aika suunnata kohti uusia haasteita. Eiköhän se yhdeksän vuotta opiskelijana ole riittävästi, josta tosin vuosi aikalailla tyhjäkäynnillä ja pari vuotta töissä. Melkein varmaa kuitenkin on, että opiskelut eivät tähän jää, sillä elämä on jatkuvaa uuden oppimista.

Vielä tosin on edessä kypsyysnäytteen kirjoittaminen ja diplomityöesitelmän pitäminen, mutta kunhan työ arvostellaan 5.5.2010 ja saan paperit kouraan 28.5.2010, ovat opiskelut tältä erää paketissa. Paljon se vaati, mutta paljon se antoikin.

Lisäys: 18.7.2010:
Loppujen lopuksi työni sisälsi 65 sivua, 15 kuvaa, 3 taulukkoa, 43 viitettä ja 0 liitettä. Eli kohtalaisen tiivis katsaus aiheeseen, mutta ilmeisen onnistunut, ainakin työn tarkastajien mielestä, sillä arvosanaksi muodostui kiitettävä (5). Työn lausunnossa kehuttiin sujuvaa näkökulman vaihtoa prototypoinnista web-sovelluksiin ja itse toteutettuun sovelluksen prototypointiin, työn tasapuolisuutta, johdonmukaisesti etenevää kokonaisuutta ja mallikasta lähdekirjallisuutta ja sen käyttöä. Arvostelun osa-alueet muodostuivat seuraavasti:

• Työn tulokset: 5
• Tekijän itsenäisyys, omintakeisuus ja aikataulun hallinta: 5
• Esityksen johdonmukaisuus ja huolellisuus: 4
• Kieliasu: 5
• Kirjallisuuden valinta ja käyttö: 4

Helvetireader muuttaa Google Readerin ulkoasun minimaaliseksi: syötteiden lukemiseen liittymättömät asiat piilotetaan hienovaraisesti ja värimaailmasta muokataan hillityn harmaa. Helvetiredear-käyttäjäskripti toimii kaikissa käyttäjäskriptejä tukevissa selaimissa kuten Firefoxissa Greasemonkey-lisäosan avulla, Operassa, Google Chromessa ja Webkit-pohjaisissa selaimissa (Safari) GreaseKit-lisäosan avulla.

Myös aikaisemmin Google Readerille oli saatavilla gReader-teema, mutta sen ylläpito on lopetettu. Google Reader muuttuu ajoittain ja teemojen pitää aina sen mukaa päivittyä. Tähän mennessä Helvetireader on päivittynyt hyvin ja uuden version “lataaminen” on vain sivun päivityksen päässä, kun skriptiä ei asenneta vaan se haetaan Internetistä.

Espresso on Web-koodaukseen tarkoitettu editori, joka tarjoaa hyvät teksti- ja CSS-editorit ja niiden ympärille rakennetun toimivan kokonaisuuden. Tekstieditorista löytyy tagien ehdotus ja täydennys ja blokkeja voi piilottaa. Koodausta voi helpottaa koodipätkillä eli snippeteillä kuten TextMate tyyliset tekstieditori-toiminnoilla. Yksi kätevä ominaisuus on sivun toteutuksen seuraaminen reaaliajassa, sillä esikatselun saa auki omaan ikkunaan ja se päivittyy sitä mukaa, kun koodiin tehdään muutoksia. Ohjelmaa avatessa avautuvat myös edellisellä kerralla auki olleet ikkunat, jolloin työympäristö on nopeasti käyttövalmiina.

Espresso tukee vakiona HTML:ää, CSS:ää, XML:ää, JavaScriptiä ja PHP:tä, mutta sokerilla (Sugar) voi viritellä ohjelmaan tuen uusille kielille kuten jQuerylle, Rubylle ja Djangolle. Sivuston julkaiseminen on mahdollistettu käyttäen FTP:tä, SFTP:tä, FTP/SSL:ää tai Amazon S3:sta. Lompakkoa ohjelma keventää noin 60 euron verran.

Osallistuin alkutalvesta MacHeistiin, jossa jaettiin ohjelmia ilmaiseksi ja lisäksi ostin lopulta edullisen MacHeist Bundlen, jossa mukana tuli muun muassa World Of Goo, Hit List ja Espresso. Olen aikaisemmin tyytynyt pienet Web-sivujen rakennustarpeet toteuttamaan joko TextWranglerilla tai isomman muutoksen tapauksessa Aptanalla, mutta näihin verrattuna Espresso on toisesta maailmasta, paremmasta sellaisesta. Käytännössä Espresso on vastaava ja osittain parempi kuin kuin kehuttu Coda, jota myös nopeasti testailin.

Kävin jokin aika sitten läpi eri Web-palveluihin tekemiäni tunnuksia ja muutaman vuoden takaisista palveluista oli osa jo ehtinyt lopettaa toimintansa. Tällaisia olivat muun muassa Pownce, Widsets ja Ma.gnolia. Kahden ensimmäisen palvelun lopettamisesta tuli aikoinaan sähköpostiin tiedotteita, mutta sosiaalinen kirjanmerkkipalvelu Ma.gnolia päättyi tarinan mukaan yllättäen tietokannan hiljaiseen hajoamiseen. Onneksi en aikanaan vaihtanut Delicious -kirjanmerkkipalvelusta pois, vaikka Ma.gnolia tarjosikin muutamia käteviä ominaisuuksia. Siinä olisi samalla hävinnyt kasa kirjanmerkkejä, ellei niistä olisi ollut varmuuskopioita omassa tallessa, jotka palvelusta halutessaan sai.

Useissa Web-palveluissa ei ole välttämättä edes tarjolla mahdollisuutta itse tuottamansa sisällön tuomiseen omaan talteen, joten pahimmassa tapauksessa esimerkiksi urheilupäiväkirjan tai blogipalvelun kaatuessa rahoitusvaikeuksiin tai laiterikkoon, häviää käyttäjän “kallisarvoinen” tieto. Esimerkiksi GMailista omien sähköpostien tallettaminen on hankalaa ja Tumblr -blogipalvelusta, Flickr -kuvapalvelusta, Snipplr -koodiotteista, Moozement-urheilupäiväkirjasta tai Sports Tracker -urheiluseurannasta on turha varmuuskopiointimahdollisuutta etsiä. Vastaavasti muun muassa WordPress -blogipalvelusta ja Delicious-kirjainmerkkipalvelusta voi oman sisältönsä ottaa kätevästi talteen.

Tietenkin Webissä on lukuisia palveluita, joiden sisällöllä ei ole juurikaan arvoa myöhemmin, joten menetyksen arvo ei ole kovin suuri. Tällaisia ovat muun muassa tiettyyn ajan hetkeen sidottut palvelut, kuten Facebook-yhteistösivusto ja Twitter -lyhytviestin tai “portfolio-sivustot” kuten LinkedIn -verkostoitumissivusto. Monien foorumeiden keskusteluiden tai Wiki-tyyppisten sivustojen osalta sisällöllä on merkitystä myöhemminkin, mutta yhteisöllisestä luonteesta johtuen se on kollektiivista omaisuutta.

Tiedon turvaamisen näkökannalta Web-palvelut eivät paljoa eroa perinteisistä työpöytäsovelluksista ja vastuu on aina käyttäjällä. Muista siis ottaa varmuuskopiot, jos tieto on sinulle arvokasta.

BBC:n Formula 1 -lähetykset näkyvät valitettavasti vain Iso-Britannian verkkoalueelle, joten lähetysten katsomiseen tarvitaan muutamia kiertokeinoja. Kaikki on onneksi selvitetty valmiiksi ja asiaan löytyy Muropaketin keskusteluista selkeät ohjeet, joita seuraamalla kisat saa näkymiin muutamassa minuutissa.

Käytännössä ohjeissa asennetaan anonymisoiva Tor-verkko toimimaan verkkoliikenteen kierrättäjänä ja liikenteen ulostulopiste asetetaan sijaitsemaan Iso-Britanniaan. Tämän jälkeen asennetaan Firefoxiin FoxyProxy-lisäosa, jolla saadaan määriteltyä tarkemmin Torin kautta käytettävät osoitteet ja täten huijattua BBC:n kohdemaatarkistusta.

Kauden aikaisemmat kisat olen katsonut MTV 3:n kanavapaketin kautta vanhempien luona, tai jättänyt katsomatta, mutta tämän viikonlopun kisaa varten tuli tutustuttua Muropaketin ohjeisiin tarkemmin ja viriteltyä asetukset kuntoon. Ohjeissa seurasin vain Linuxille tarkoitettuja toimenpiteitä ja sovelsin niitä Mac OS X:lle. Eli asensin Tor-paketin Portsista ja käynnistin tor-verkon suoralla komennolla.

Kuvanlaadultaan BBC:n lähetys on ainakin peruslaadulla hyvää ja parempaa kuin mitä viime vuonna ITV:n lähetyksissä tuli katsottua. Lähetys myös toimi luotettavasti ja kisan seuraaminen onnistui ilman katkoksia. Pientä säätöä kisan katsominen vaati, mutta lopputulos on kokonaisuudessaan paljon miellyttävämpi kunnollisen selostuksen kera, vaikka kuvan koosta joutuukin hieman tinkimään. Lisäksi ratkaisu on myös ilmainen, joka lämmittää lompakkoa.

Kojelauta (dashboard) -kuvaketta hahmoteltiin tutuilla ideoilla: talo, mittaristo, sivu. Itse pidin eniten “talo”-metaforasta, joka siis viittaa kotiin. Kojelauta on WordPressin hallintapaneelissa saman arvoinen, kuin muun muassa web-selaimista löytyvän “talo”-kuvakkeen idea.

Kirjoitukset (posts) -kuvake tarjosi aika tuttuja ideoita: taulunasta, muistilappu, kappalemerkki. “Neliön sisällä oleva kappale-merkki” -kuvake lämmitti teknistä ajatusmaailmaani, mutta muistilaput ja taulunasta ovat kyllä selkeämpiä.

Mediaan (media) viitattiin perinteisellä kuvalla ja kameralla, mutta oivaltavin idea oli yhdistää kamera ja nuotti, joka kuvaa hyvin median monimuotoisuutta.

Linkkejä (links) kuvattiin totuttuun tyyliin ketjun linkeillä ja hieman harvemmin nähdyllä maapallolla. Sydämen muotoon yhdistetyt linkit olivat mainio idea ja viittaavat blogien keskinäiseen linkittämiseen (link love).

Sivuja (pages) kuvaava idea ei tarjonnut juurikaan juhlimisen aihetta.

Kommentteja (comments) hahmoteltiin puhekuplien ympärille ja hyvä idea oli liittää puhekuplaan myös henkilö. Kommenttien määrän ahtaminen puhekuplan sisään ei oikein tunnu loppupeleissä hyvältä idealta.

Ulkoasu (appearance) -kuvake-ehdotelmat tarjosivat hyvin vaihtelevia ideoita. Mielestäni silmä ja pensseli olivat ovelia, mutta kameleontin ja pönttömacin ideat eivät oikein auenneet. Monitori ja kaksi ikkunaa tarjosivat tuttua ja turvallista.

Lisäosat (plugins) -kuvakkeessa näkyy hyvin englannin vaikutus ja englanninkielisenä ideana töpseli toimii hyvin. Idealtaan legopalikka toimii hieman paremmin myös muilla kielillä, mutta olettaa kaikkien tietävän, mikä legopalikka on. Kuvalistan viimeinen kuvake viitannee hieman palapeliin, jota on käytetty esimerkiksi Firefoxin laajennukset-kuvakkeena. Akkupariston ajatus jäi hieman arvoitukseksi.

Käyttäjä-tietoja (users) kuvattiin perinteisesti henkilö-kuvilla ja ilmeisesti osoitekirjan sivuna.

Työkalut (tools) viittasivat loogisesti työkaluihin. Tarjolla oli jakoavainta, työkalulaatikkoa ja jakoavainta ruuvimeisselin kanssa.

Asetukset (settings) -kuvakkeet ehdottivat erilaisia säätövipuja ja ratasta, jotka ovatkin yleisesti käytettyjä, mutta ilmeisesti tarkistuslistaa kuvaava idea jäi aika heikoksi.

Oivaltavia kuvakkeita WordPressin kuvakeideointiin suunnittelivat Ben Dunkle, Verena Segert, Guillaume Berry, Open Source Design class at Parson’s in New york City ja Luke Smith. Sekä yllä olevat kuvakkeet että tekijät ovat järjestetty kuvake-kokonaisuuden äänten mukaan. Dunklen ideoimat kuvakkeet saivat 35% prosenttia äänistä ja Segertin kuvakkeet saavuttivat 29% prosenttia äänistä.

Kyselyn vastaukset julkistettiin eilen ja tulokset nojaavat myös omiin mieltymyksiini. Lisäksi voittaneita ja toiseksi tulleita kuvakkeita vielä tarkennetaan kyselyn mukaisilla tuloksilla muutamien kuvakkeiden kuten “kojelauta” ja “työkalut” -osilta. Eri kuvakekokonaisuudet ja WordPress-tiimin kommentit löytyvät kyselyn tuloksista, joka kannattaa vilkaista.

Pienillä eroilla esimerkiksi sovelluksen kuvakkeiden valinnassa on suuri ero käyttäjien kokemassa sovelluksen selkeydessä ja käyttäjäystävällisyydessä. Valitettavan usein ne pienet mutta merkittävät asiat ovat juuri niitä asioita, joita ei aina ehditä miettiä ja suunnitella kunnolla. Tietenkin, hyvä suunnittelija tekee samalla työmäärällä hieman paremman ja tähän pitäisikin pyrkiä. Jotta hyvän lopputuloksen suunnittelu ei olisi liian helppoa, eivät asiat koskaan ole yksiselitteisiä ja ongelmaan on harvoin vain yksi oikea ratkaisu.

Blueprint CSS on norjalaisen opiskelijan, Olav Frihagen Bjørkøy:n luoma CSS-framework, joka käytännössä kokoaa yhteen useita hyväksi havaittuja tekniikoita ja tarjoaa hyvän perustan web-sivun rakentamiselle. Kehyksen kokonaisuus rakentuu ristikkotaiton päälle (Grid Layout) ja tarjoaa järkevät perusarvot typografialle ja eri CSS-elementeille. Vakiona sivuston sisältö on suunniteltu 960px leveäksi eli 1024×768 -resoluutiolle. Blueprint CSS:n tarjoamia ominaisuuksia voi laajentaa muun muassa hienommilla napeilla. Jos Blueprint CSS:n taustat kiinnostavat, kannattaa lukaista Olavin haastattelu.

“Spend your time innovating, not replicating.” – Blueprint CSS

Parhaiten Blueprint CSS:n idea selvenee esimerkeistä:

Blueprint CSS:llä saa aikaan nopeasti sekä näkyvää että siistiä tulosta ja varsinkin hieman vähemmän CSS:n kanssa taistelleille web-koodareille se on hyvä lähtökohta. Vastaavasti hieman kokeneemmille toteuttajille Blueprint CSS:n käyttäminen voi tuntua hieman rajoittavalta ja jäykältä, vaikka monilta osin se tarjoaakin käteviä palikoita nopeaan toteutukseen. Tältäkin osin Blueprint CSS -framework toteuttaa monen muun frameworkin tavoin yhden niiden käytön ongelman: olet “rajoittunut” valitsemasi kehyksen sisään ja sieltä irtautuminen voi olla työlästä.

Kokeilin Blueprint CSS:n kätevyyttä muutaman web-projektin suunnittelussa ja etenkin sen sopivuutta omiin tarpeisiini, mutta vaikka kehys vaikuttikin näppärältä, ei se oikein taipunut haluamiini raameihin. Pala palalta kaipasin jotain hieman erilaista, jota Blueprint CSS ei tarjonnut, ja lopulta totesin helpommaksi vain poimia käyttöön ne osat, jotka havaitsin käytännölliseksi. Eli käytännössä olen osa osalta rakentamassa omaa CSS-kehystä, joka toki hiemankin enemmän web-sivujen suunnittelua tekeviltä jo jossain muodossa löytyy. Työläin vaihehan vain on kaikkien palikoiden kerääminen yhteen ja sen jalostaminen sopivaksi kokonaisuudeksi.

Vaikka Blueprint CSS ei oikein lämmittänyt, sen kanssa leikkiessä tuli kuitenkin todettua, että ristikkotaitto eli Grid Layout on aika kätevä tapa sijoitella komponentit ruudulle. Kehitysvaiheessa ristikkotaiton ja elementtien sijoittelun apuna on lisäksi kätevä käyttää Grid Layout JS -palikkaa, joka JavaScriptin avulla näyttää ja piilottaa sivutaiton sarakkeet.

Kenties seuraavaksi pitää tutkia, mitä tarjottavaa BlueTripillä on ja mitä kaikkia komponentteja Yahoo User Interface Librarysta löytyy. Open Sourcessa on se mainio ominaisuus, että jos jokin asia ei miellytä, lisäyksen saa kohtalaisen helposti toteutettua ja aina voi tietenkin forkata.