3.2. Tilastokeskuksen web-palvelun tuotantokuvaus

Tilastokeskuksen web-palvelu on tietopalvelu, jonka tarkoituksena on tarjota vaihtoehtoinen jakelukanava Tilastokeskuksen julkaisemalle tiedolle. Palvelun tarkoituksena on parantaa asiakaspalvelua asettamalla tietoa helpommin ja nopeammin saatavaksi.

Palvelun oletetut käyttäjät ovat ensisijaisesti julkisorganisaatioiden työntekijät, toissijaisesti suuret yritykset, opiskelijat, tutkijat ja toimittajat ja viime kädessä kaikki suomalaiset. Palvelun oletettu käyttö on tietyn tiedon etsiminen työaikana julkishallinnon työpaikoilla sekä opiskelijoilla ja mediatyöntekijöillä ajasta riippumatta.

Palvelu sisältää muun muassa Tilasto-oppaan, suositun Taskutilasto-kokonaisuuden, lehdistötiedotteet, sähköpostikyselyn päivystävälle informaatikolle, maksullisten tietokantapalveluiden käyttökansiot sekä maksullisen International Business Statistics-tietopalvelun.

Palvelun suunnittelu ja rakentaminen aloitettiin syksyllä 1994 ja se käynnistettiin helmikuussa 1995, jonka jälkeen sitä on rakennettu vähitellen. Ajan myötä palveluun syntyi uudistustarpeita, jotka toteutettiin uudistuksella vuonna 1997. Tämä uudistus valittiin myös tässä tarkasteltavaksi tuotantoprosessiksi.

Tuotantoprosessissa päätettiin edettiin vaiheittain. Suunnittelu aloitettiin palvelun rakenteesta, jonka jälkeen edettiin visuaalisen ilmeen ja käyttöliittymän suunnitteluun. Prosessin ja lopputuloksen kannalta keskeisimmät muutokset olivat ulkoisen hakupalvelun lakkauttaminen ja sen poistaminen osana palvelun käyttöä, tyylitiedostojen hyödyntämismahdollisuuksien vähyys sekä julkaisemisen automatisointi ja hajauttaminen suuremmalle sisällöntuottajaryhmälle organisaation sisällä. Ulkoasullisesti tavoiteltu organisaatiomaisen ilmeen poistaminen koettiin myös onnistuneeksi.

Palvelun kehittämistä veti web-kehityksen vastaava, apunaan ulkoasua tuottava graafikko ja joukko osa-aikaisia ohjelmointiresursseja. Varsinainen projektiryhmä oli siis luonteeltaan pieni ja raportoi tekemisistään web- puolen seurantaryhmälle. Pienryhmätyöskentelyn takia projektissa ei koettu tarpeelliseksi käyttää valmista projektin läpivientimallia. Projektiryhmä raportoi Internet- kehitystä valvovalle ryhmälle, joka vahvisti esitellyt toimenpide-ehdotukset ja antoi projektiryhmälle valtuudet edetä toteutuksessa.

Tavoitteet

Tilastokeskuksen web-palvelu on esimerkki tyypillisestä web-pilotista ja sen kehityksestä. Piloteilla ei usein ole määritelty tarkkoja tavoitteita, muita kuin pilottiprojektin kautta oppiminen. Usein onnistunee pilotit päätyvät kuitenkin tuotantojärjestelmiksi, jolloin niihin kohdistuu aivan erilaisia odotuksia ja muutospaineita, kuin mitä alkuperäiseen pilottiin. Tämän takia on järkevää arvioida pilottiprojektin tavoitteet uudestaan onnistuneen läpiviennin jälkeen.

Tavoitteiden arvioinnissa on tärkeää pystyä erottamaan vähintäänkin organisaation tavoitteet palvelun käyttäjän tavoitteista, sillä nämä kaksi voivat hyvinkin olla keskenään ristiriidassa. Ratkaisemattomat ristiriidat voivat puolestaan hankaloittaa suunnittelua ja heikentää hyvään käytettävyyteen pyrkiviä ratkaisuja.

Kartoitus

Tavoitteet ilmeen ja käyttöliittymän yhtenäistämisestä päätettiin toteuttaa hyödyntämällä CSS- tyylitiedostoja. Cascading Style Sheet on HTML-piirre, jolla kuhunkin HTML-dokumenttiin kutsutaan ulkoasumäärittelyjä tyylipohjasta. Tällöin samoja ulkoasumäärittelyjä ei tarvitse tuottaa joka sivulle erikseen vaan tyylipohjan muutokset vaikuttavat kaikkiin dokumentteihin. Tyylitiedostojen käyttö nähtiin tulevaisuuden kannalta tärkeänä, sillä tavoitteeksi asetettiin rakenteen (HTML) ja ulkoasun (CSS) erottaminen toisistaan.

Käyttäjien tarvekartoitus tehtiin saatujen palautteiden ja kehityspyyntöjen pohjalta ja nämä merkittiin ylös projektin dokumentointiin. Koko projektin läpi erilaisten suunnittelupäätösten ratkaisut kirjattiin ylös. Dokumentoinnilla on erityinen merkitys pitkään kestävissä tai muuten laajoissa projekteissa, jossa tehtyihin ratkaisuihin joudutaan usein palaamaan uudestaan. Päätösten historian avulla jokainen ratkaisu ja siihen johtavat päätelmät voidaan nopeasti tarkistaa, mikä säästää usein suunnittelussa ja tuotannossa aikaa.

Muodollisen tarvekartoituksen avulla on kuitenkin mahdollista päästä parempaan kuvaan asiakkaiden ja oman organisaatioiden tarpeista rakennettavan järjestelmän suhteen. Muodollisen kartoituksen tarkoituksena on auttaa pilkkomaan järjestelmän tavoite (esim. "tarjota tilastotietoa sopivassa muodossa kaikille verkkokäyttäjille") edellään toimintoihin, joiden avulla tavoitteisiin päästää (esim. lista uusista tutkimustuloksista, aihehakemisto eri tilastoalueista, haku tilaston sisällön perusteella, jne.) Tarvekartoitus pitää sisällään monta muuta vaihetta, mutta sitä voidaan skaalata käytettävissä olevan ajan ja tarpeiden mukaan (kts. tarkemmin Newell & Lemming, 1995). On tärkeää huomata myös, että vaikka tarvekartoitusta ei ikinä tehtäisikään muodollisesti, se on aina olemassa, vähintään suunnittelijoiden ja toteuttajien päässä. Näiden kirjoittaminen auki auttaa projektiryhmää löytämään kuitenkin nopeammin yhteiset tavoitteet joihin pyrkiä (Newman, Lamming, 1995).

Sisällöntuotanto tilastokeskuksessa oli hajautettu organisaation tilastoyksiköihin, jotka päivittivät oman vastuualueen tietonsa itse. Web- palvelun ulkoasusta, ylläpidosta ja tuesta vastasi keskitetysti organisaation web-toimituksessa. Osastojen halujen mukaan on tarve myös siirtää puhelinkyselyjä verkkoon niin, että useimmin kysytyt tiedot ovat saatavilla verkosta itsepalveluna.

Vaikka verkkopalvelun määriteltynä tavoitteena ei ollutkaan asiakaspalvelurakenteen keventäminen ja siirtäminen osittain itsepalvelun puolelle, oli tämä tarve organisaatiossa ilmeinen: useat tilastotiedon tuottajat pelkäsivät verkon kautta tulevien kyselyiden määrän paisuvan hallitsemattomaksi ja toivoivat itsepalvelun painottamista.

Käyttäjien hahmottaminen loki-tiedostojen perusteella antaa korkean tason yleiskuvan erilaisista käyttäjäryhmistä. Tämä ei kuitenkaan välttämättä kerro käytön motiiveista ja erityisistä tarpeista, jotka saattavat vaihdella korkean tason käyttäjäryhmästä riippumatta. Näiden tarpeiden tunnistaminen ja käyttäjien jakaminen ryhmiin näiden avulla antaa paremman pohjan järjestelmän tarvekartoitukselle (Newell & Lemming, 1995). On syytä huomioida myös, että käyttäjien tarpeet ovat yleensä olemassa olevien ratkaisuiden muokkaamia: jos tarjolla on vain tietty palvelu X, on todennäköistä että käyttäjät ilmoittavat tarvitsevansa sitä. Tämä ei kuitenkaan tarkoita, että kyseinen palvelu täyttäisi käyttäjien tarpeet, sillä usein käyttäjät pyrkivät ratkaisemaan ongelmansa niillä (puutteellisillakin) välineillä, mitä on tarjolla.

Suunnittelu

Palvelun käyttöliittymän rakenne haluttiin kuitenkin eriyttää organisaatiorakenteesta ja lähentyä enemmän sisältöön perustuvaa jaottelua. Sivukaavion ja kartan avulla tuotantoryhmä havainnollisti itselleen miten käyttäjän näkökulmasta palvelun pitäisi hahmottua. Tämä tavallaan pakotti tuotantoryhmän ajattelemaan rakennetta uudesta näkökulmasta. Lopulta kartta muodostui niin selkeäksi navigaatiovälineeksi, että se sijoitettiin lopulliseen palveluun yhdeksi navigaatiotavaksi.

Palvelun tietorakennetta suunniteltaessa on tärkeää erottaa useat päällekkäiset rakenteet, jotka palvelevat eri tarkoituksia: organisaatiorakenne soveltuu yrityksen kuvaamiseen, tiedostorakenne määritetään usein ylläpidon tarpeiden kautta, sisällön rakenne kertoo esitettävän sisällön luonnollisimman esityksen kun taas palvelun rakenne kuvaa sisällön puhutellun kohderyhmän tarpeiden näkökulmasta. Näistä tärkein on luonnollisesti viimeisin, eli palvelun rakenne, jonka kautta palvelusta muodostuu kokonaiskuva käyttäjälle. Palvelurakennetta ei saisi sekoittaa organisaatio- tai tiedostorakenteeseen ja toisinaan se täytyy erottaa myös sisältörakenteesta.

Painetun materiaalin graafinen ohjeisto ei sovellu verkkoviestinnän tai etenkään -palveluiden ulkoasun määritykseksi. Tämä johtuu useasta syystä: ensinnäkin web-sivuilla on mahdotonta esittää asioita graafisen ohjeiston absoluuttisten väriarvojen, kokojen ja tyylien mukaisesti. Verkkosivuilla nämä ovat parhaimmillaankin suhteellisia ja suuntaa-antavia. Toiseksi graafisen ohjeiston noudattaminen ruutusuunnittelussa voi johtaa hyvin huonosti käytettäviin ja luettaviin sivuihin. Tämä ei tarkoita, etteikö graafista ohjeistoa voisi hyödyntää verkkosisällön suunnittelussa, mutta se on otettava enemmänkin temaattiseksi suuntaviivaksi kuin absoluuttiseksi säännöstöksi. Esimerkkinä mainittakoon IBM, jonka yritysidentiteettiä tukeva graafinen ohjeisto on erittäin tarkan kontrollin alla. Tästä huolimatta yrityksen web-sivuilla on noudatettu ohjeistoa vain tietyissä graafisissa elementeissä, eikä esim. tekstissä, tyhjän tilan käytössä tai yleisessä taitoissa.

Toteutus

Työkaluina käytettiin Arachnophilia-ohjelmaa, jonka avulla koodattiin käsin pääosa HTML-koodista. Sisällön ylläpidossa käytettiin myös Excel ja Word-makroja. HTML-koodaus ja graafinen työstö ylittyivät arvioidusta ajasta.

Automatisoinnin ja yhtenäistämisen perustaksi valittu CSS-tekniikka ei toiminut tyydyttävällä tavalla. Keskeisimpiä ongelmia olivat, että selaimet toteuttivat tyylitiedosto-ominaisuuksia eri tavoilla (joitain ominaisuuksia eivät olleenkaan), ja että tulostus ei toiminut ennakoitavasti. Tyylitiedostoja sovellettiin kuitenkin laajasti niiltä osin kuin ne saatiin käyttäytymään ennalta arvattavasti, kuten marginaalit ja fontit.

Taskutilaston käyttöliittymän ja sivurakenteen teknisen toteutuksen osaksi valittiin kehykset (frames). Kehysten käyttö oli perustelua taskutilastossa selailtavuuden ja liikkuvuuden parantamiseksi. Tästä osiosta kehyksiä kuitenkin laajennettiin käyttöön myös joihinkin muihin osioihin.

Sisältötuotannossa ja julkaisemisessa päästiin tuotantoprosessin aikana osittaiseen automatisointiin ja manuaalisten työvaiheiden yhtenäistämiseen. Sisältötuotannossa ja julkaisemisessa on kaksi eri työvuota: automatisoitu / hajautettu ja osittain manuaalinen ja keskitetty.

Automatisoitu / hajautettu julkaiseminen käsittää lehdistötiedotteet, taskutilastot, tietokantojen käyttökansiot, kaupallisen uutispalvelun, extranet-palvelut ja jotkut taulukot. Työntekijät tekevät omilla toimisto- ohjelmillaan dokumentit käyttäen palvelulle suunniteltua tyylitiedostoa). VB-makroa käyttäen he tallentavat HTML-muotoisen version intranet-palvelimelle. Lopuksi HTML-versio tarkistetaan intranet-palvelimelta web- selaimella. Intranet-palvelin siirtää automaattisesti hyväksytyn HTML-version internet-palvelimelle.

Kaikki muu julkaiseminen toteutetaan manuaalisesti ja suurelta osalta keskitetysti. Työntekijät lähettävät toimisto-ohjelmalla tehdyn dokumentin sähköpostitse web-toimitukseen, joka muokkaa HTML-version ja laittaa sen hyväksyttäväksi Intranet-palvelimelle. Työntekijä yksikössä antaa hyväksyntänsä sähköpostitse. Hyväksymisen jälkeen Internet-toimitus linkittää hyväksytyn HTML-version internet- palvelun asianomaisille sivuille ja uudet/muutetut sivut siirretään automaattisesti säädettyyn aikaan illalla internet palvelimelle. Käsin päivittäminen on tarpeen vain poikkeustapauksissa, kuten poikkeava julkistamisaika tai mahdolliset korjaukset. Kolmisenkymmentä sisältöpäivittäjää tekee jonkin verran myös itse käsin HTML-koodia varsinaisen sisällön ympärille.

Testaus

Palvelun testaus tehtiin myös 14,4 kbps modeemilla ja kotisivu latautui alle 20 sekunnissa. Kriteerinä pidettiin 20 sekunnin latausaikaa 14,4 kbps modeemilla. Tuotantoryhmän mielestä työpaikkojen erittäin nopeat yhteydet voivat luoda väärän kuvan palvelun käytön nopeudesta. Siksi testaamista kotoa modeemilla pidettiin erittäin tärkeänä.

Aikaisemmassa testauksessa oli huomattu, että muualta linkitetty hakupalvelu ei toiminut halutulla tavalla. Kyseessä oli Tilastokeskuksen palvelusta riippumaton täysin ulkoinen, maksuton hakupalvelu, jonka hakulomake oli linkitettty Tilastokeskuksen palveluun. Haku oli rajattu etsimään annettua merkkiyhdistelmää vain Tilastokeskuksen palvelusta.

Tuloksena oli ollut liikaa vastauksia, liikaa vääränlaisia tietoja ja Tilastokeskuksen uusien sivujen indeksointi kesti 0-60 vuorokautta. Uusimmat ja kysytyimmät web-sivut eivät näkyneet ajantasaisesti Tilastokeskuksen palvelun käyttäjille.

Hakupalvelun tarjoaja ensin poisti rajausmahdollisuuden tiettyyn web-palveluun, jolloin haku poistui myös Tilastokeskuksen palvelusta navigointimahdollisuutena. Kun rajausmahdollisuus palautui hakupalveluun, niin tuotantoryhmä koki edellämainituista syistä, että hausta oli enemmän haittaa kuin hyötyä eikä maksutonta hakumahdollisuutta enää palautettu Tilastokekuksen palveluun. Ihmiset eivät löytäneet sen avulla tietoa, joka oli palvelussa ja valittivat tästä.

Palvelun laajuuden vuoksi haku parantaisi merkittävästi käytettävyyttä ja tarjoaisi käyttötavan kokeneemmille käyttäjille. Nyt sivukokonaisuus on ollut ilman sanahakua jo pitkään, koska oman toimivan hakujärjestelmän kehittäminen on hidasta resursseista riippumatta.

Tuotantoprosessissa pitäisi arvioida jo kartoitus- ja suunnitteluvaiheessa, millaisia vaikutuksia on sitoutumisella teknologiaan, joka ei ole tuotantoryhmän ohjailtavissa. Valitulle ratkaisulle pitäisi olla kakkos- ja kolmosvaihtoehtoja, jos esimerkiksi maksuttoman teknologian tarjoaja lopettaa kehitystyönsä tai vetää sen kokonaan markkinoilta.

Tässä tapauksessa maksuttoman - ja palvelun kannalta kriittisen - teknologian käyttö kävi kalliiksi käytettävyyden näkökulmasta. Koska Tilastokeskuksen palvelun käyttö itsessään on ollut maksutonta, niin syntyneet käytettävyysongelmat ovat kuitenkin vähemmän katastrofaalisia kuin jos kyseessä olisi ollut maksullinen palvelu. Periaatteessa koko tilanne olisi jäänyt syntymättä, jos Tilastokeskus olisi alusta alkaen lähtenyt kehittämään omaa, palvelun sisäistä hakua, mutta tämä taas on resurssikysymys.

Palvelu testattiin selaimista Lynxillä Unix- ympäristössä sekä Mosaicilla, Microsoft Internet Explorerilla ja Netscapella Windows- ympäristössä. Sisäinen testaus toteutettiin intranet-palvelimella ennen kuin palvelu julkistettiin.

Julkistus ja ylläpito

Palvelun uudistus julkistettiin osana Journalistipäiviä ja ilmoitettiin tärkeimpiin linkkihakemistoihin. Osa lehdistä raportoi uudistuksen. Kävijävolyymin kasvu ollut kiitettävää ilman erillistä palvelun uudelleenjulkaisuakin.

Tilastokeskuksen sivuihin on hakukoneita varten lisätty description ja keywords META-viitat, jotka tarjoavat hakupalveluille valmiita hakusanoja ja kuvauksen sivujen sisällöstä. Näiden avulla voidaan parantaa palvelun löydettävyyttä hakukoneiden kautta.

Palautteen ohjaaminen palvelun toimivuudesta ja toisaalta sisällöstä eri kanaviin on usein välttämätöntä järkevän ylläpidon saavuttamiseksi.

Tilastokeskuksen hajautettuun sisällöntuotannon malliin sopii hyvin sisältökohtaiset sähköpostiosoitteet (ainakin organisaation kannalta). Toisaalta palvelun toimivuutta ja tekniikkaa koskevat kommentit on syytä ohjata ylläpidon osoitteeseen. Mikäli näitä palautekanavia ei ole tarjottu palvelussa ja merkitty selkeästi on seurauksena usein sähköpostitulva pahaa aavistamattoman osoitteeseen, joka sattuu näkymään ensimmäisenä sivulla.

Jatkokehitys

Joitakin PDF-julkaisuja on tehty ja pääosin ne ovat olleet uusia. PDF-keskusteluissa on ollut kaksi näkökulmaa: painetut julkaisut laitettaisiin esimerkiksi tietyn ajan jälkeen ilmaiseksi verkkoontai kaikki voitaisiin laittaa verkkoon ilmaiseksi PDF-muodossa ilman että se lopettaisi tai edes vähentäisi painettujen julkaisujen myyntiä. Lopullista ratkaisua asiassa ei ole tehty ja toisaalta PDF-muotoisten julkaisujen kysyntä on ollut vähäistä.

Kehitysideoista osa on käytettävyyden kannalta ongelmallisia, kuten esimerkiksi selaintunnistus. Selaintunnistus edellyttää, että selaimesta saadaan kysymällä tarvittavat tiedot. Kaikki selaimet eivät kuitenkaan palauta tätä tietoa, se voi olla virheellinen tai ei lopulta vastaa käyttäjän tarpeita. Automaattisesti sisällön esityksen valitseminen selainversion perusteella voi siis tuottaa yhtä paljon ongelmia, kuin se antaa mahdollisuuden rakentaa erilaisia versioita eri selaimille.

Metatiedon käyttäminen (XML-kuvauskielen avulla) lisännee Tilastokeskuksen web-palvelun kaltaisen kokonaisuuden käytettävyyttä merkittävästi. Metatiedolla voidaan yhä tarkemmin erottaa sisältö viittaustiedosta, jonka perusteella voidaan hakea sisältöä järkevämmin. Tiedon rakenteellistaminen XML- määritystä hyväksi käyttäen tarjoaa myös monipuolisemman navigointimahdollisuuden tulevissa viidennen sukupolven web-selaimissa. Metatiedon käyttämisessä on kuitenkin omat ongelmansa: dokumenttien luokittelu jälkikäteen käsityönä on erittäin työlästä, Forrester Researchin mukaan 15 000 dokumentin suuruisen kokonaisuuden indeksoiminen jälkikäteen manuaalisesti maksaa helposti viisi miljoonaa markkaa (Rosenfeld, 1998). Tämä edellyttää vielä sopivan metadata- määrityksen löytymistä. Tilastokeskuksen päätyminen lähes standardinomaiseen Dublin Core metadata-määritykseen lienee paikallaan, joskin tämäkin määritys on vielä keskeneräinen (Mantis, 1998).

Tuotantoryhmän arvioita palvelun käytettävyydestä

Kehys-rakennetta ollaan muuttamassa ja ryhmän itsensä mielestä käyttöliittymässä tarvitaan ylipäänsä vielä isompi remontti. Käytettävyys ja mielikuva ovat kuitenkin molemmat parantuneet uudistuksen myötä.

Vapaasanahaun puuttumisen aiheuttamat käytettävyys-ongelmat on tiedossa, mutta tuotantoryhmällä ei ole ollut aikaa ottaa käyttöön jo ostettua, Ovalin suomen kieltä taivuttavaa hakupalvelua.

Latausnopeuden painottaminen on rajoittanut sivujen ilmaisuvoimaa tekijöiden mielestä, sillä kotisivun ulkoasusta on jouduttu tinkimään latausaikojen takaamiseksi. Lyhyttä latausaikaa on pidetty tärkeänä, koska palvelun lokitietojen mukaan suurin osa selaajista tulee palveluun kotisivun kautta.

Uutisten määrä on kasvanut IBS-palvelussa, kun julkaisutahti on muuttunut eräajosta lähes tosiaikaiseksi. Uutisia on julkaistu 4173 kappaletta ajalla 1.1.- 31.10.1998. Tämän seurauksena jotkut työnkuvat ovat muuttuneet radikaalisti ja tavallaan salakavalasti omalla painollaan. Ryhmä on havainnut tarpeen miettiä työnkuvia uudestaan, koska osa tiedon ylläpitäjistä kokee työnsä stressaavaksi. Myös sähköpostikyselyiden määrä on kasvanut niin paljon, että vastaaminen koetaan jo hieman raskaaksi ja pelätään lisäkasvun aiheuttamia ongelmia

Vuonna 1997 internetiä ei nähty oleellisena osana koko organisaation toimintaa, mutta tasaisen käytön ja tietoisuuden kasvun kautta kevään 1998 aikana tilanne on muuttunut merkittävästi. Tuotantoryhmä kokee myös, että uudistusten toteuttaminen edellyttää lisää resursseja, muun muassa ohjelmointiosaamista (CGI, Java, JavaScript) ja osastojen ihmisten resurssien parempaa hyödyntämistä sisällön tuotannossa.