Ohjelmistot ja ohjelmointi: maaliskuu 2008 - arkisto

Syötteistä on kovaa vauhtia tulossa, ja monen kohdalla jo tullut, blogien pääasiallinen seuraamismuoto. Käytettävyyssyyt tähän ovat ilmeiset, varsinkin kun lukulistalla on parikymmentä blogia tai muuta ajoittain päivittyvää sisältölähdettä: syötteenlukija ilmoittaa selkeästi milloin mistäkin lähteestä on tullut uutta sisältöä ja tarjoaa helpon ja ennen kaikkea yhdenmukaisen tavan käydä lukemassa kyseinen sisältö. Näppärää lukijoille, vaivatonta julkaisijalle, mikäs sen parempaa. Tästä kuitenkin seuraa, että lukijat yhä harvemmin varsinaisesti vierailevat blogin tai muun julkaisun sivustolla. Mitä tästä seuraa julkaisijan kannalta? Entä mitä syötteistä ja niiden lukijoista vielä puuttuu?

Ärsyttävää, kuka sitten ihailee vääntämääni hienoa grafiikkaa ja sivupalkkieni äänestyswidgettejä ja muita virityksiä, kun kaikki seuraavat blogiani syötteen kautta? Tai kuka enää käy klikkailemassa sivustoni mainoksia?

Syötteisiin siirryttäessä julkaisuun tuotettu sisältö on kuningas: lukijat (tai heidän lukijansa käyttöliittymäsuunnittelijat) päättävät miltä kirjoitus tai virtaan heitetyt kuvat näyttävät. Huomioitta jäävät armotta niin viimeisen päälle viilatut CSS-tyylimäärittelyt kuin sivuston pikselitarkasti piirretyt graafiset elementitkin. Sisältö, joka ei ole mukana julkaisun syötteissä, jää tietyltä osalta lukijoita huomaamatta.

Blogeissa sisällön syötteiden löytäminen ja sitominen toisiinsa on ongelma erityisesti kommenttien kannalta: vaikka blogin tai yksittäisen kirjoituksen kommenteille olisikin oma syötteensä, eivät lukijaohjelmat vielä juurikaan osaa näitä sivusyötteitä etsiä ja yhdistellä.

Atom-syötteessä voidaan viitata kirjoitussyötteestä kommenttisyötteeseen ja toisinpäin Atom Threading Extensions -nimisen standardin (RFC 4685) avulla. Sen mukaan kirjoitussyötteessä viitataan sen kommenttisyötteeseen rel=”replies”-attribuutilla varustetulla link-elementillä. Kommenttisyötteessä puolestaan viitataan kommentin kohteena olevaan kirjoitukseen erityisen <thr:in-reply-to> -elementin avulla, joka voi sisältää viitteen sekä kirjoituksen HTML-sivuun että kyseisen kirjoituksen Atom-syötteeseen. Virittelin nuo linkit juuri kuntoon tässä blogissa, joten niistä voi katsoa esimerkkiä.

RSS 2.0-syötteessä ko. kirjoituksen syöteet sisältävän (HTML-)sivun voi julistaa comments-elementin avulla, mutta kommenttisyötteen osoitetta ei tämän elementin avulla voi antaa. Syötteenlukijaohjelmien tuki näille linkityksille lienee vielä toistaiseksi heikkoa, mutta ainakin Atom Threading Extensions -standardille voi uumoilla lisääntyvää käyttöä.

Syötekuluttajien huomioiminen tarkoittaa syötteiden linkittämisen lisäksi panostamista kirjoitusten arkistointiin ja hakutoimintoihin sivuston koreuden kustannuksella. Syötteissä julkaistaan yleensä vain alle 20 uusinta kirjoitusta, joten vanhempaa tavaraa etsiessään lukijat turvautuvat sivuston tarjoamiin arkistoihin tai hakukoneeseen. Periaatteessa blogin sivusto voisikin keskittyä käyttöliittymässään kirjoitusarkiston ja hakukoneen tarjoamiseen ja ohjata lukijat kuluttamaan sisältöä syötteiden kautta.

Syötemuotoisen sisällön löytämisen helpottamiseen tähdätään myös OpenSearch-tekniikoilla, joilla oman sivustonsa olemassaolevan hakukoneen saa integroitua toisten hakukoneiden osaksi. Oman hakukoneen kutsurajapinta kuvataan erityisen kuvaustiedoston avulla, ja hakukone konfiguroidaan tuottamaan hakutulokset OpenSearch-integrointia varten joko Atom- tai RSS-muodossa. kuvitelmaa-blogin OpenSearch-kuvaus löytyy osoitteesta http://kuvitelmaa.net/opensearchdescription.xml ja kuvitelmaa-blogin OpenSearch-hakua voi käydä kokeilemassa A9.comin Column Chooser -hakukoneella (hae hakukonetta sanalla “kuvitelmaa”).

Blogikirjoitusten kommentointi on tällä hetkellä kenties hankalinta hoitaa muutoin kuin varsianisen blogisivuston kautta. Tähänkin on pikkuhiljaa tuomassa ratkaisua Atom Publishing Protocol (RFC 5023), joka määrittelee standardin HTTP-pohjaisille kutsuprotokollille web-resurssien julkaisemiseen ja muokkaamiseen. Hieman yksinkertaistaen sivusto kuvaa tarjoamansa resurssitkokoelmat (kuten blogikirjoitukset ja kommentit) hierarkisesti erityisen service-dokumentin avulla.

Service-dokumentissa kuvattuun kokoelmaan voidaan lisätä uusi elementti lähettämällä se HTTP-post-pyyntönä kokoelman URL-osoitteeseen. Kunkin kokoelman sisältö julkaistaan omana Atom-syötteenään, ja niiden kussakin entryssä on rel=”edit” -attribuutilla merkitty link-elementti, joka kertoo ko. resurssin koneelliseen muokkaamiseen käytettävän URL-osoitteen. Atom Publishing -protokollan vaikutusvaltaisin käyttäjä lienee Google, jonka GData API perustuu Atom- ja RSS-syötteiden käyttöön.

Mainosten sisällyttäminen syötteisiin tulee varmasti lisääntymään tulevaisuudessa. Teknisesti tähän ei ole mitään estettä: teksti- tai kuvamuotoinen mainos pujahtaa syötteen sisään kuten mikä tahansa HTML-sisältö. Eri asia sitten on, miten ärsyttäväksi lukijat syötemainonnan tuomitsevat.

Korviin osui Sula Pinta -podcastin jaksosta #21 uutinen, jossa mainittiin IBM:n puuhailevan virtuaalisen kolmiulotteisen 3-D Data Center -härpäkeen kanssa käyttäen Second Life -klooni OpenSIMä teknologia-alustana. Ei voi olla totta, hölmöin idea, minkä ole pitkään aikaan kuullut, oli ensiajatus.

Piti tietysti kaivaa lähde esille ja löytyyhän Ibarin sivuilta tosiaan moisesta kertova 20. helmikuuta 2008 päivätty lehdistötiedote ja kyseiseltä sivulta vielä YouTube-linkki, jossa esitellään ihmettä juoksentelemalla ympäriinsä virtuaalikonehuonessa, jossa serverit ovat sananmukaisesti liekeissä. Mistään ei kyllä käynyt selville mitä asialle olisi voinut tehdä.

Virtuaalimaailmat ja muut 3D-visualisoinnit ovat oikein kivoja ja monissa tapauksissa todella hyödyllisiäkin. Äkkiseltään tulee mieleen rakentamiseen ja sisutukseen sekä molekyylirakenteiden esittelyyn ja tutkimiseen liitttyvät sovellukset. Potentiaalisesti hyödyllisiä ovat varmaankin myös moniulotteisen datan visualisointiin liityvät työkalut, joissa ihminen toimii datanlouhijana etsien suuresta tietomäärästä jotain mielenkiintoista säännönmukaisuutta tai muuta epämääräisesti koneelle määriteltävää piirrettä.

Kolmannen dimension simulointi kaksiulotteisella pinnalla (joita näyttölaitteet vielä toistaiseksi useimmiten ovat) on visuaalisesti raskasta: näyttöpinta-alasta suurin osa menee 3D-illuusion luomiseen ja varsinaiselle datalle jää kovin vähän tilaa. Lisäksi reaalimaailman esineitä mallinnettaessa virtuaalimaailmaan raahataan mukaan aivan turhaan myös reaalimaailman heikkoudet.

En millään voi ymmärtää 3D-visualisoinnin etu Data Center -valvontatyökalussa verrattuna esimerkiksi kaksiulottaiseen skemaatiseen näkymään palvelimista, jossa niiden verkkoyhteydet ja -kaistankäyttö, sähkönsyöttö ja -kulutus, lämpötilat, yms. on visualisoitu käyttäen perinteisiä kognitiivisesta psykologista kumpuavia huomiokeinoja, kuten ryhmittelyä, kokoeroja, värejä, liikettä (harkiten), ja ääntä (todella harkiten). Jos operaattori sattuu virtuaalicentterissä katsomaan väärään suuntaan tai jokin rakenne sattuu sopivasti tielle, niin hälytys jää näkemättä. Tai jos pidetään huolta ettei varmasti jää, niin muutaman serverin samanaikainen paukahtaminen saa tilan tunnelman muistuttamaan tykistökeskitystä, mikä ei takuulla ohjaa käyttäjää keskittymään olennaiseen eli ongelman rauhalliseen ja järjestelmälliseen analysointiin ja ratkaisemiseen.

Jopa taulukkomuotoinen valvontalista on helposti datasisällöltään 3D-mallia parempi, vaikka etenkin toisiinsa liittyvien ongelmien, kuten vaikka yhden datakaapelin irtoamisesta aiheutuva muiden lähistön palvelinten ylikuormitus, selvittämistä se ei juurikaan tue.

Konehuoneen mallintamisesta voi kyllä olla hyötyäkin silloin, kun tarkoituksen on nimenomaan simuloida todellista tilaa. Esimerkiksi huoltomiehen kouluttaminen navigoimaan nopeasti suuressa konehuoneessa tai vaikkapa tulipalon sammuttamisen simulointi ovat järkevää virtuaalimaailman käyttöä.