Prototyypin testauksen loppuraportti

$Id: testreport.html,v 1.7 1998/02/12 14:13:51 sonkkila Exp $
Author: Tuija Sonkkila

Testauksen tavoitteet

Testauksen tavoitteena oli saada selville HUTpubl-prototyypin ja verkkojakelun toimivuus. Erityisesti pyrittiin saamaan selville HUTpubl DTD:n (Westerling 1997b) soveltuvuus testattavina oleviin julkaisuihin sekä testaajien mielipiteet testaukseen valittujen tekstureiden ominaisuuksista.

Prototyyppi

Testattava prototyyppi muodostui kahdesta editointivälineestä: Word ja FMSGML. Lisäksi prototyyppiin kuuluivat Word-tyylipohja, FMSGML:n sisäinen EDD-tiedosto, joka sisältää myös paperijulkaisun ulkoasutiedot sekä HUTpubl DTD, TKK:n julkaisusarjoille tehty rakennekuvaus.

Testaustapa

Testaus koostui seuraavista osioista:

• kaksipäiväinen koulutus: SGML-perusteet, HUTpubl-DTD, välineet
• ohjelmien asennus
• rakenteinen editointi ajalla 16.10-18.11
• viikottaiset tapaamiset editointijakson aikana (mukana yksi yhteinen tapaaminen projektin valvontaryhmän kanssa)
• email-lista sekä FAQ-tiedosto www:ssä
• kysely
• haastattelu ja loppukeskustelu

Testaajat

Testaukseen osallistui kolme henkilökunnan edustajaa: toimistosihteeri, koulutussihteeri ja tutkija. Jäljempänä heistä käytetään lyhenteitä TH, SH ja PE. Lisäksi testauksen alussa annettuun kaksipäiväiseen koulutukseen osallistui kolme viestintätekniikan opiskelijaa.

Kouluttajat

Ohjaajina ja kouluttajina toimivat Jörgen Westerling (opiskelija, diplomityöntekijä) ja Tuija Sonkkila (pääkirjasto, projektipäällikkö).

Testattava materiaali

Kukin testaaja työsti yhden itsevalitsemansa dokumentin. Kaikki testatuiksi valitut olivat valmiita, jo muussa digitaalisessa muodossa olevia dokumentteja, joten niistä tehtiin näin ollen takautuvasti rakenteinen. Jokaisesta oli myös paperille tulostettu versio olemassa. Dokumentit olivat muodoltaan: kurssin lopputyö, tutkimusraportti ja loppuraportti.

Testaajan PE aikomuksena oli ottaa testattavaksi uusi dokumentti, eli kirjoittaa uutta, rakenteista tekstiä suoraan FrameMaker+SGML:lla (FMSGML) Hän luopui kuitenkin ajatuksesta testauksen oltua jo varsin pitkällä. Työtä vaikeutti tuntuvasti se, että testikoneena ollut mikrotietokone osoittautui kapasiteetiltaan liian vaatimattomaksi, myös levytila oli jatkuvasti vähissä. PE tunsi erityistä kiinnostusta rakennekuvauksen toimivuuteen ja antoikin runsaasti palautetta siitä testauksen kuluessa. Kun testausaika näytti loppuvan kesken, hän hylkäsi aloittamansa dokumentin ja muunsi sen sijaan erään WordPerfect-muodossa olleen raportin rakenteiseen muotoon, vieläpä hyvin nopeassa ajassa. Työtä ripeytti myös ohjelmiston asennus toiseen mikrotietokoneeseen.

Testausvälineet

Kaikki testaajat työskentelivät omissa työpisteissään ja omilla laitteillaan eri puolilla kampusta. Projektin puolesta kahdelle testaajalle asennettiin testausta varten FMSGML-ohjelmisto tarvittavine lisätiedostoineen. Kolmannella, Word-testaajalla, oli ohjelmisto käytössään työn puolesta. Testaajien käytössä olivat seuraavat laitteistokoonpanot :

	Prosessori	Muisti	Kiintolevy	Näytön koko ja resoluutio
Testaaja PE (FMSGML) aluksi	486DX2 66 MHz	16 MB	1 GB	14" 800x600
Testaaja PE (FMSGML) lopuksi	Pentium Pro 200 MHz	64 MB	2 x 2 GB	17" 1024x768
Testaaja TH (FMSGML)	Pentium 166 MHz	32 MB	n. 2,5 GB	19" 1152x882
Testaaja SH (Word)	Digital HiNote VP LSS 5120 Pentium 120 MHz	24 MB	810 MB	11" 800x600

Koulutus

Testaajille ja kolmen hengen opiskelijaryhmälle annettiin kaksipäiväinen koulutus testauksen aluksi 6.10 ja 15.10. Kouluttajana ja koulutusmateriaalin tekijänä toimi Jörgen Westerling. Koulutustilan mikrotietokoneilla olivat käytettävissä FMSGML, Near&Far DTD:n hierarkkista tarkastelua varten sekä prototyyppiin kuuluneet tallennuspohjat.

Ensimmäisen koulutuspäivän aiheena olivat SGML:n perusteet sekä HUTpubl DTD. Osallistujat tekivät lisäksi pienimuotoisen harjoitustyön, jossa harjoiteltiin dokumentin rakenteen analysointia. Toisena päivänä aiheena oli FMSGML-ohjelman käyttö. Word-testaajalle neuvottiin tyylien käyttöä erikseen varsinaisen koulutusjakson ulkopuolella.

Yhteydenpitotavat

Testausryhmä kokoontui viisi kertaa testauksen kuluessa, puolesta tunnista tuntiin kerralla. Vapaamuotoisissa tapaamisissa käytiin läpi esiin tulleita ongelmakohtia ja korjausehdotuksia. Yhdessä tapaamisessa oli mukana myös projektin valvontaryhmän jäseniä. Tapaamisissa esiin tulleet kysymykset kirjattiin www-järjestelmään FAQ-listaksi. Testausryhmälle oli laadittu sähköposti-alias, mutta sitä käytettiin lähinnä vain viikkotapaamisten ajankohdasta sopimiseen.

Kysely

Testauksen loppuvaiheessa testaajille laadittiin kyselylomake, jolla kerättiin tietoja atk-kokemuksesta, käytössä olevista tekstinkäsittelyohjelmistoista, arvioita testauksessa käytetystä ohjelmasta, rakennekuvauksesta sekä testauksesta yleensä. Kyselyn jälkeen ryhmä kokoontui vielä kerran keskustelemaan kyselyn tuloksista.

ATK-kokemus, tekstinkäsittely ja web-julkaiseminen

Kaikki testaajat ovat käyttäneet tietokoneita yli 5 vuotta ja pitävät itseään keskivertona tietokoneen käyttäjänä. He käyttävät konetta monipuolisesti eri toimintoihin: tekstinkäsittelyyn, taittoon, tiedottamiseen jne. Ohjelmointia ei kukaan heistä kuitenkaan ole harrastanut ja vain yksi testaaja on tehnyt taulukkolaskentaa. Tietokoneympäristöistä ovat tuttuja PC (kaikki) , Mac (2) ja unix (1).

Tietokoneen käyttöä ohjailee paitsi työympäristön ohjelma- ja laitevarustus myös työnkuva ja aiemmat ohjelmistokokemukset.

Testaaja TH kirjoittaa lähes päätyökseen puhtaaksi toisten kirjoittamia tekstikokonaisuuksia kuten kirjeitä, muistioita, raportteja, kirjoja sekä erilaista koulutus- ja esittelymateriaalia. HTML-tekstiä hän ei tuota itse, mutta kertoi sen varmasti piankin tulevan ajankohtaiseksi. TH suunnittelee julkaisujen ulkoasun, taittaa ja huolehtii julkaisujen painatuksesta. Käytössä oleva ohjelmistovalikoima heijastelee lähinnä originaalitekstin tekijöiden valintoja ja TH:n hallitsema ohjelmistoarsenaali onkin varsin laaja. Word on yleinen ja siistittäväksi ja muokattavaksi tulevat tekstit ovatkin usein Word-muodossa. Organisaatiossa on lisäksi tehty päätös käyttää FrameMakeria, mutta myös PageMaker-taitto-ohjelmaa käytetään tarpeen vaatiessa. LaTeX:ia on käytetty kerran erään oppikirjan taittamiseen. Kuten testaaja itse haastattelussa mainitsi:

"Osaan vähän kaikenlaisista ohjelmista, mutta mitään en hallitse oikein kunnolla. Opettelen ohjelmista sen verran kun tarvitsen. Otan yrityksen ja erehdyksen kautta selville miten ne toimivat" (TH)

Testaaja SH:n kirjoitustyöstä 90% keskittyy omien tekstien työstöön. Ne ovat muodoltaan kirjeitä, muistioita, raportteja ja koulusmateriaalia. Ennen varsinaista kirjoitustyötä SH hahmottelee tekstejä kynän ja paperin avulla. Organisaatiossa on tehty jokin aika sitten päätös käyttää vain Wordia. Testaaja itse on ollut aiemmin WordPerfectin tehokäyttäjä ja siirtyminen Wordiin ei ole ollut ongelmatonta. Tästä on aiheutunut tekstinkäsittelyyn selviä motivaatiovaikeuksia. Wordin ilmenemismuoto ja toimintavat eivät miellytä häntä. Muista testaajista poiketen SH kirjoittaa päivittäin HTML-muotoista tekstiä, välineinä Word Internet Assistant ja Netscape Gold.

Kolmas testaaja, PE, työstää myös muita tekstejä kuin omiaan, mutta omien osuus on silti korkea, 90%. Muodoltaan ne ovat joko muistioita tai raportteja. Toisin kuin muut testaajat, PE hahmottelee tekstiensä - lähinnä raporttien - rungon aina ensin tietokoneella siten, että luo sisällysluettelon ja lisää sitten väliotsikot sekä niiden alle vähän tekstiä. Testaaja kirjoittaa lisäksi viikottain HTML-tekstiä HomeSite -ohjelmistolla. Myös hänelle WordPerfect on ensisijaisin tekstinkäsittelyohjelmisto, Word on tullut mukaan lähinnä muiden tekemien tekstien muokkauksen myötä. PE oli kokeillut testin ulkopuolella WordPerfect 8:aan saatavaa SGML-optiota muttei ollut päässyt kovin pitkälle, sillä se ei ollut suostunut lukemaan sisäänsä HUTpubl-DTD:tä.

Dokumentit

Testaajien tuntemat, heidän omien yksikköjensä tuottamat pidemmät julkaisut eroavat sisällöltään jonkin verran toisistaan. Grafiikkaa, taulukoita ja matemaattisia kaavoja oli vaihtelevia määriä. Yhdessäkään ei kuitenkaan mikään näistä ollut hallitsevassa asemassa.

Kokemuksia teksturista

Testaajia pyydettiin antamaan kouluarvosana (4-10) testaamilleen ohjelmille. FMSGML sai molemmilta testaajilta arvosanan 7, Word 8.

FMSGML

Molemmat FMSGML:n testaajat pitivät ohjelman parhaana piirteenä rakenneikkunaa, sen käyttö oli nopeuttanut ja helpottanut työskentelyä. Toinen testaajista mainitsi hoksanneensa käyttää sitä vasta jonkin ajan kuluttua ja tämän jälkeen käyttänyt sitä jatkuvasti:

"Tajusin, että siinähän voi kätevästi siirtää vaikka kokonaisia kappaleita paikasta toiseen. Paljon helpompaa kuin dokumentti-ikkunassa." (TH)

Koska käytössä ollut FMSGML-versio oli ns. työryhmä-Windows -versio, siinä eivät toimineet Windows-95:stä jo tutuksi tulleet toiminnot, kuten mm. alueen valinta ja sen jälkeinen hiiren oikean näppäimen painalluksella esiin tuleva valikko. PE piti tätä yhteensopimattomuutta ohjelman vähiten miellyttävänä piirteenä. Hänen mielestään myöskään elementtien lisäys ei toiminut aina täysin loogisesti.

Elementtien lisääminen oli ollut kohtuullisen helppoa, elementtivalikon käyttö joko hyvin tai ainakin varsin helppoa. PE oli käyttänyt usein pikanäppäimiä toimintojen tekemiseen, TH ei ollenkaan, mikä kertonee enemmänkin tekstureiden yleisistä käyttötottumuksista. FMSGML:ssa voi tehdä editointia joko dokumentti- tai rakenneikkunassa, kuten edellä kävi ilmi. PE oli käyttänyt kumpiakin yhtä paljon, TH enimmäkseen rakenneikkunaa, mitä voinee pitää mielenkiintoisena testituloksena. PE oli lisännyt joitakin attribuutteja elementteihin, TH ei ollenkaan.

FMSGML-testaajat olivat periaatteessa molemmat myötämielisiä ohjelmaan. He voisivat suositella sen käyttöä muillekin (tosin tällöin uudempaa versiota) ja jatkavansa jopa itse sen käyttöä. Tosin PE painotti sitä, että käytössä pitää olla vähintään 17 tuuman näyttö.

Word

Wordin testaajan mielestä parasta ohjelmassa on vain se, että se on tuttu:

"En pidä Wordista, mutta eipä tässä ollut paljon vaihtoehtoja…" (SH)

Hän piti Wordin hankalimpana piirteenä nimenomaan tyylien käsittelyä. Varsinkin niiden selaaminen näkyviin tyylivalikosta oli ollut työlästä. Koska tämä oli testauksen aikana jatkuvasti toistuva toimenpide, ei ollut mikään ihme, että testaajalle jäi Wordista varsin kitkerä muisto.

"Se on kyllä tosi tyhmä ohjelma. Aivan erilainen kuin WP. Esimerkiksi mitään koodeja ei saa näkyviin niinkuin WP:ssä, jossa niille saa kätevän pienen erillisen ikkunan auki ruudun alalaitaan. Siitä voi hakea ja korjailla juttuja." (SH)

Testauksen kuluessa tilanne paheni entisestään: Word päivitettiin uudempaan versioon (Office95:stä Office97:ään). Tyylivalikon alasveto oli aiemmin vienyt kannettavan pienikokoisesta näytöstä ison osan, mutta nyt se uhkasi haudata alleen kaiken tekstin. Microsoft ei selvästikään ole huomannut tarkistaa, minkälaista on työskentely tyylien kanssa pienikokoisella näytöllä. Kaikista teknisistä hankaluuksista huolimatta SH olisi valmis suosittelemaan ohjelman käyttöä prototyypissä, vaikkakin tietyin varauksin:

"Sitä tekee tyylien merkkausta tekstiin aika sokkona. Kun ei voi olla mitenkään varma siitä, tekeekö oikein vai väärin. Ei ole mahdollisuutta tarkistaa mitään. Ehkä se menettelisi, jos tekisi uutta tekstiä, mutta nyt sitä vain mekaanisesti lisäsi tyylejä. Vähän niinkuin mustaan aukkoon olisi heittänyt." (SH)

Tyylien nimet olivat SH:n mielestä olleet varsin selviä, epäloogisuuksia ei ollut.

Rakennekuvaus

Elementtien nimet olivat olleet ymmärrettäviä, kaikki testaajat olivat joutuneet vain harvoin ottamaan selvää niiden merkityksestä. Jos lisäselvityksille oli tarvetta, he olivat tutkineet jaettua dokumentointia (3) tai kysyneet ohjaajilta (2). Koska attribuuttien käyttö oli testissä hyvin vähäistä, niistä ei osattu olla mitään erityistä mieltä. Testaajat eivät myöskään olleet "kikkailleet" testin aikana saadakseen rakenteen validiksi. Tämä selittynee osin sillä, että Wordin testaaja ei voinut validoidakaan rakennetta millään lailla ja FMSGML:n testaajia ei taas erityisesti pyydetty validoimaankaan tekstiään. Riitti, että he keräsivät kokemuksia ohjelmasta ja rakennekuvauksesta. Validointi jäi oman harrastuksen ja ajan varaan.

Kysymykseen, tuntuiko joitakin elementtejä puuttuvan, kaksi testaaja vastasi kielteisesti, PE mainitsi viitteistä puuttuneen ISBN-elementin. Yleensä ottaen rakennetta pidettiin melko kelvollisena testatuille julkaisutyypeille. Dokumentaatiota pidettiin hyvänä sillä huomautuksella, että kaikille ei englanninkielinen teksti välttämättä avaudu.

Testaus yleensä

Kaikki testaajat pitivät testausta kohtuullisen mielekkäänä, mutta jotkut asiat olivat jääneet epäselviksi. Esitettyihin kysymyksiin oli kuitenkin aina tullut vastaus. Tästä on pääteltävissä, että epäselvät asiat olivat laajempiin asiakokonaisuuksiin liittyviä, vielä jäsentymättömiä. Todennäköistä on, että ne liittyivät projektin yleisiin tavoitteisiin ja SGML-muotoisen julkaisun jatkotyöstämiseen, vaikkakaan testaajat eivät suoraan ilmaisseet ajatuksiaan näin. Testaajien yleistä paneutumisesta asiaan kuvasi se, että heidän mielestään isompi testausryhmä olisi edesauttanut erityisesti testitulosten analysointia.

Loppukeskustelussa testaajat olivat yksimielisiä siitä, että testausaika olisi saanut olla pidempi, testaajia olisi saanut olla enemmän, samoin koulutusta ja normaalit päivätyöt olisivat saaneet haitata testausta vähemmän. Yksi testaajista valitti erityisesti työkiireitään ja oletti, että tulevaisuudessakaan ei tämäntapaisille testauksille liikene aikaa. Kaksi muuta testaajaa kertoivat olevansa halukkaita osallistumaan testaukseen jatkossakin, jos on tarvetta. He mainitsivat olevansa kiinnostuneita testaamaan muita editointiohjelmistoja (erityisesti WP8 SGML), SGML-selaimia ja projektissa tuotettavia muita sovelluksia.

Kaksi testaajaa osallistui Vaasassa järjestettyyn SGML Finland '97 -tapahtumaan, jonka ensimmäisen päivän ohjelmana oli SGML-peruskurssi, toinen päivä oli omistettu SGML-hankkeiden esittelylle. Tapahtuma sijoittui ajallisesti testikoulutuksen keskelle. Molemmat osallistujat pitivät Vaasan tilaisuutta hyödyllisenä, koska siellä SGML asettui paremmin. kehyksiinsä; erityisesti tieto sen käyttöalasta laajeni. Heidän mielestään ilman tilaisuutta osallistua tähän tapahtumaan varsinainen SGML-koulutus testin aikana olisi jäänyt liian ohueksi. Tämäkin tukee oletusta siitä, että avoimiksi jääneet asiat testauksessa liittyivät laajempiin kokonaisuuksiin kuin itse testattavaan välineeseen ja/tai rakennekuvaukseen.

Tulosten tarkastelua

Testauksen tarkoituksena oli saada selville HUTpubl-DTD:n soveltuvuus testattavina oleviin julkaisuihin sekä kerätä testaajien mielipiteitä testaukseen valittujen tekstureiden ominaisuuksista.

DTD:n soveltuvuudella tarkoitetaan tässä nimenomaan soveltuvuutta kirjoittamiseen. DTD:n merkitys on kuitenkin paljon kauaskantoisempi. Paitsi kirjoittamista sen olisi palveltava hyvin myös dokumenttien tallennusjärjestelmän ominaisuuksia, konversiota, hakua, julkaisemista ja tiedonvaihtoa (Best, 131). Tämä voi olla käytännössä liikaa yhdelle ainoalle DTD:lle. Yhdelläkin DTD:llä voi kuitenkin tulla toimeen, mutta vain siinä tapauksessa, että dokumentteja tuotetaan ja hallitaan vakaassa ja itseriittoisessa ympäristössä (ibid., 132). Arkikielellä voisi ehkä puhua "matalan profiilin" SGML-tuotantoympäristöstä.

Oslon yliopistossa tehdyssä pilottiprojektissa (Jenssen 1996), jossa tutkittiin opetusohjelman hajautettua digitaalista tuottamista, havaittiin, että systeemin rakentajien ja kirjoittajien välillä oli eroja suhtautumisessa itsetehdyn DTD:n käyttökelpoisuuteen. Systeemin rakentajat olivat tiukemman DTD:n puolella, kirjoittajat taas toivoivat enemmän vapauksia ja ne otettiin DTD:n kehitystyössä huomioon. Mitään varsinaista, erillistä DTD-testausta ei hankkeessa tehty vaan DTD:tä muokattiin osana hankkeen yleistä evaluointia, joka tehtiin haastattelujen ja vapaamuotoisen keskustelun pohjalta.

HUTpubl-DTD:tä muokattiin jonkin verran testauksen tuloksena (ks. tekniikkaliite). Osa muokkauksista oli puutteellisuuksia ja/tai virheitä, joista testaajat huomauttivat. Loput muutoksista olivat tapaamisissa käytyjen keskustelujen tuloksena syntyneitä uusia elementtejä tai sisältömallien muutoksia.

Uusia julkaisutapoja ei luonnollisestikaan voi testata tyhjiössä. Nykyiset, käytössä olevat menetelmät ja paperijulkaisut ovat vahvoja taustavaikuttajia. Vahvimmillaan vaikutukset näkyvät työskenneltäessä WYSIWYG-tekstinkäsittelyohjelmistoilla kuten Word. Vaikka niihin on rakennettu mahdollisuus työstää tekstiä kappaletyylien avulla, tyylien käyttö ei ole mielekästä, sillä WYSIWYG antaa kirjoittajan ymmärtää, että hän kirjoittaa paperille, jolloin dokumentin sisäisellä rakenteella ei ole merkitystä (Sørgaard 1997). Onkin esitetty, että digitaalisten dokumenttien aikakaudella tekstinkäsittelyohjelmien ei pitäisi johtaa kirjoittajia tällä tavalla harhaan (ibid.).

HUTpubl-testauksessa tuli selvästi esille se, että ohjelmistot voivat tehdä tyylien lisäämisen myös teknisesti erittäin hankalaksi. Tyylien käyttö Wordin alasvetovalikosta on problemaattista kahdesta syystä. Ensiksikin, jos tyylejä on paljon, alasvetovalikko kasvaa pitkäksi ja sen rullaaminen on työlästä, erityisesti pienikokoisella näytöllä. Toinen ongelma liittyy valikkoon käyttöliittymäteknisenä ratkaisuna. Valikon tarkoitus on keventää käyttäjän muistitaakkaa. Valikon avulla eri toimintojen käynnistyskomentoja ei tarvitse muistaa, riittää että ne tunnistaa nimeltä tai kuvasta (Preece 1994, s. 265). Mutta miten tunnistaa kappaletyylejä toisistaan? Word antaa tähän periaatteessa kaksi mahdollisuutta: kappaletyylien nimet voi saada ruudulle näkyviin, dokumenttitekstin viereen erityiselle tyylialueelle. Toinen tapa on ottaa yksittäinen tyyli esiin tyylin muuntonäytöllä. Kumpikaan tapa ei anna kirjoittajalle vihjettä siitä, valitsiko hän rakenteellisesti oikean tyylin, koska Word kertoo kappaletyylistä vain sen - ja tässä tullaan takaisin WYSIWYG-tematiikkaan - miltä teksti missäkin tyylissä näyttää, ei sitä, mikä rooli sillä on julkaisussa, mikä suhde sillä on muihin julkaisun osiin jne.

WYSIWYG-ongelma on hieman erilainen julkaisutyökaluilla, joissa rakenteinen editointi on lisäpiirre, kuten FMSGML:ssä. Rakenteinen editointi FMSGML:llä voi olla kirjoittajalle positiivinen, jopa mielenkiintoinenkin kokemus, kuten HUTpubl-testissäkin kävi ilmi. FMSGML:n ongelma on kuitenkin sen monipuolisuudessa. Ohjelmisto on raskas ajettava, ja lisäksi useat eri ikkunanäkymät dokumenttiin vaativat suurikokoisen näytön ja hyvätasoisen näytönohjaimen. Kirjoittajalle tulee myös halu vaikuttaa julkaisun ulkoasutietoihin, koska FMSGML tarjoaa niitä niin auliisti käytettäväksi. Joka tapauksessa muuhun kuin dokumentin rakenteeseen liittyvät seikat alkavat askarruttaa FMSGML:n käyttäjää. Se, onko tämä hyvä vai huono asia, riippuu luonnollisesti siitä, mikä on kirjoittajan rooli tuotantoketjussa. FMSGML:n käyttöliittymä ei kuitenkaan selvästi ilmaise sitä, missä kulkee rakenteisen tekstintekemisen ja julkaisemisen ero. Tämä aiheuttaa hämminkiä ainakin aloittelevassa käyttäjässä.

Kondrach (1997a) antaa seikkaperäisen, strukturoidun mallin kirjoitusvaiheen DTD:n testaukselle ja mm. käytettäville testilomakkeille. Kondrachin mukaan sopiva testausajan pituus korreloi dokumenttianalyysin keston kanssa suhteessa 1:1 tai 1,5:1. HUTpubl-projektissa dokumenttianalyysin kesto oli n. 2 kuukautta, joten Kondrachin kaavaa noudattaen testin olisi pitänyt kestää vähintään kuukauden kauemmin. Kondrachin suosittelema DTD-testi koostuu koulutujaksosta ja kahdesta peräkkäisestä testausjaksosta. Ensimmäisessä jaksossa DTD:tä testataan koko testausryhmän voimin valvotuissa oloissa käytettävyyslaboratoriossa. Toisessa jaksossa testi jatkuu kunkin testaajan työpaikalla vähemmän kontrolloidusti. Kondrach korostaa sitä, että testaajilla on oltava hyvä kokonaiskuva tuotantoketjusta sekä testattavana olevan DTD:n merkityksestä. Testausvälineiden tuntemus on niin ikään tärkeää, mutta testin kannalta tarpeettomat ohjelman piirteet on yritettävä pitää sivussa. Mitä yhtäjaksoisempi testi, sen motivoivampaa testaajille. Kondrachin (1997b) mielestä DTD:tä tulisi lisäksi testata valmiin dokumentin kanssa.

HUTpubl-testissä oli alun perin tarkoitus järjestää varsinaista testiä edeltävä koetestaus, mutta se jouduttiin aikataulullisista syistä hylkäämään. Ajatuksena oli, että koetestillä olisi saatu kokemuksia mm. siitä, miten paljon koulutusta DTD:stä ja testausvälineistä testaajat tarvitsisivat ennen testin alkua. TKK:n käytettävyyslaboratorion käytöstä DTD-testaukseen ei vakavasti edes keskusteltu. Testaustavoitteita ei asetettu näin korkealle. Tavoitteena oli tuoda DTD todellisten kirjoittajien ja dokumenttien koeteltavaksi. Preece et al. (1994, s. 604) mukaillen tämäntyyppistä testausta voitaneen nimittää todellisuuden ymmärtämiseksi.

Varsin selvää on, että HUTpubl-testi ei ollut ideaalitapaus DTD-testauksesta. Yhtä lailla selvää kuitenkin on, että siinä tehty työ oli arvokasta ja monella tavalla hyödyllistä. Testaajat olivat motivoituneita ja he osoittivat erittäin kiitettävää omistautumista asialle. Kommentteja ja mielipiteitä saatiin runsaasti sekä DTD:stä että editoreista. Koulutusta, dokumentaatiota ja opastusta pidettiin onnistuneina.

Tärkein asia DTD:n kehitystyössä on sen ymmärtäminen, mitä tarkoitusta varten DTD on tehty (Travis & Waldt 1995, s. 286). HUTpubl-projektissa on tässä suhteessa vielä paljon tehtävää, ja vastuu siitä lankeaa projektin henkilökunnalle. Tässä vaiheessa voidaan vain todeta, että prototyypin HUTpubl-DTD:tä on nyt testattu kirjoittamiseen. Testauksen perusteella tulokset siitä ovat rohkaisevia. Verkkojakeluta mainittakoon tässä yhteydessä, että HUTpubl-DTD:lle on tehty DSSSL-spesifikaatio HTML 3.2 -muunnosta varten (Westerling 1997a) ja että muunnos on toteutettu onnistuneesti. DTD:ssä on lisäksi määrittelyt Dublin Core -metadataelementeille, joten edellytykset DTD:n käyttämiselle tiedonhakuun ovat myös olemassa.

HUTpubl-DTD:ssä tehtyjä ratkaisuja on verrattu kahteen muuhun kotimaiseen rakennekuvaukseen Jyväskylän yliopiston digitaalisen median laitoksen järjestämässä elektronisen julkaisemisen seminaarissa 30.10.1997: Oulun yliopiston väitöskirjaprojektin DTD sekä Jyväskylän ja Vaasan yliopiston yhteistyönä syntynyt kurssikirja-aineisto-DTD. Lisäksi HUTpubl-DTD:n elementtien nimiä on pyritty yhtenäistämään Davenport Groupin DOCBOOK DTD:n kanssa.

Testaus ei tuonut ilmi kovinkaan paljon varsinaisesti uutta tietoa käytetyistä välineistä (Word, FMSGML). Osin tähän vaikutti testausjärjestely, mikä salli testaajille vapaat kädet kerätä niistä kokemuksia kirjoittamisen ohella. Testaajien ei edellytetty pitävän tarkkaa testipäiväkirjaa eikä kyselylomake eritellyt välineiden toimintoja yksityiskohtaisesti. Lienee kuitenkin kohtuullista sanoa, että testaajat löysivät ohjelmista olennaiset rakenteista editointia helpottavat tai hankaloittava seikat. Testaukselle olisi silti saattanut ollut hedelmällistä, jos testaajilla olisi ollut mahdollisuus kokeilla myös muita editoreita, esim. jotakin aitoa SGML-editoria. Tässä testauksessa ei kuitenkaan ollut tavoitteena verrata markkinoilla olevia editoreita toisiinsa tai esim. arvioida Nikusen ja Kuikan (1996, s. 51-54) listaa ihanteellisen SGML-editorin piirteistä.

Päätelmät

Kuten edellä on todettu, testauksen tavoitteena oli saada selville HUTpubl-prototyypin ja verkkojakelun toimivuus. Erityisesti pyrittiin saamaan selville HUTpubl DTD:n soveltuvuus testattavina oleviin julkaisuihin sekä testaajien mielipiteet testaukseen valittujen tekstureiden ominaisuuksista.

Testin pohjalta on pääteltävissä, että - tehtyjen muutosten jälkeen - pilottijulkaisun ja suppean dokumenttianalyysin pohjalta rakennettu HUTpubl DTD soveltuu hyvin ainakin testissä mukana olleiden julkaisusarjojen rakenteiseen kirjoittamiseen. Dokumentit olivat sisällöltään tekstipainotteisia, mutta niihin sisältyi myös kuva- ja taulukkomateriaalia. Tämänkaltaista aineistoa on TKK:n julkaisusarjoissa varsin paljon, joten HUTpubl DTD:n voi kohtuudella olettaa soveltuvan laajempaankin aineistoon. Dokumenttianalyysin ja testauksen pienimuotoisuuden vuoksi tähän tulokseen on kuitenkin suhtauduttava tietyllä varauksella. Selvää on, että TKK:n kaikkiin yli 200:een julkaisusarjaan HUTpubl DTD ei sovellu. DTD, joka kävisi näin suureen joukkoon julkaisuja, olisi rakenteeltaan niin salliva ja ylimalkainen, ettei siitä olisi enää hyötyä esim. rakenteisiin kohdistuvassa haussa; se olisi semanttisesti hyödytön. Projektiryhmän oma mielipide on, että HUTpubl DTD muuntuu jatkossa hyvin myös verkkojakelussa nopeasti yleistyvään XML-standardiin (W3C Recommendation). HUTpubl DTD ei sisällä XML-spesifikaation kieltämiä sisältömalleja (content model).

Word- ja FrameMaker+SGML -teksturit ovat molemmat kelvollisia dokumenttien rakenteen merkkaukseen. FrameMaker+SGML on monipuolinen ohjelmisto, ja sen rakenneikkunan käyttö editoinnissa ja elementtien siirtämisessä on varsin ongelmatonta. Ohjelmisto on kuitenkin varsin raskas ajettava ja tuottaa näin ollen käytettävälle laitteistolle suorituspaineita. Nykystandardit täyttävä Pentium-mikrotietokone ja 17 tuuman näyttö riittävät kuitenkin hyvin. Wordin suhteen on esitettäviä varauksia, sillä tyylien valitseminen useita kymmeniä tyylejä sisältävästä valikosta on työlästä. Pienikokoisella näytöllä tämä operaatio voi olla lähes mahdotonta. Ongelmallisinta Wordin käytössä on kuitenkin se, että mitään rakenteen validointia ei voi tehdä. Tästä huolimatta Word on silti eräs vaihtoehto, varsinkin rakenteeltaan yksinkertaisen dokumentin rakenteistamiseen. Koska WordPerfect on Wordin ohella yhä suosittu tekstinkäsittelyohjelmisto, on harkittava tallennusalustan ja konversioproseduurin tekemistä myös sille. Myös jonkin "aidosti" rakenteisen teksturin - kuten ArborTextin Author/Editor - testaus olisi syytä tehdä.

FrameMaker+SGML:n muunnostaulu on ominaisuuksiltaan liian vaatimaton tuotantokäyttöön. Sen tilalle on hankittava jokin kaupallinen muunnosohjelmisto. Tällä hetkellä ainoat vaihtoehdot ovat OmniMark ja Balise. Niillä on molemmilla myös muita käyttökohteita projektissa, esim. saatujen tietojen mukaan myös rakenteiset haut voitaisiin toteuttaa niiden avulla. Jatkoprojektissa onkin tehtävä näiden ohjelmistojen välinen vertailu. Hankintaa on kuitenkin harkittava tarkkaan, koska kyseessä on kummassakin tapauksessa varsin kallis ohjelmisto.

Aikatauluongelmien vuoksi dokumenttien SGML-validointi jäi testauksen ulkopuolelle, samoin paperitulostuksen yksityiskohtainen testaus. FrameMaker+SGML:n printteriajureiden suhteen on esitetty epäilyjä, ja siksi tulostuksesta on kerättävä enemmän kokemuksia. SGML-validointi tullaan tekemään osana jatkoprojektia, projektiryhmän toimesta, samalla kun dokumentit liitetään osaksi julkaisukantaa.

Verkkojakelun tekninen testaus on tavallaan tehty implisiittisesti osana HUTpubl - HTML 3.2 DSSSL spesifikaatiota ja onnistunutta käännöstä JADE:lla. Puuttumaan jäi vain puolueettomien käyttäjien tekemä vertailu SGML- ja HTML-muotoisten dokumenttien käyttökelpoisuudesta. Näiden sinällään hyvinkin tärkeiden tulosten kerääminen jää tehtäväksi jatkoprojektin aikana. Ajallisesti se soveltuukin paremmin sinne, koska varsinaista SGML-selainta - kuten MultiDoc Pro - tai plug-iniä ei vielä ole ollut käytettävissä. Myös julkaisukannan suureneminen auttaa vertailun tekemistä.

Lopuksi

HUTpubl-prototyypin testauksessa työstetyt kolme dokumenttia tullaan liittämään osaksi projektin julkaisukantaa.

Projektin henkilökunta kiittää testaajia aktiivisesta työpanoksesta.

Lähteet

Best, Karl F. (1996). Just how many DTDs do you need? SGML'96 conference proceedings, November 18-21, 1996, Boston, MA, s. 131-139. Alexandria, VA: Graphic Communications Association.

Jensen, Astrid E., Tone Irene Sandahl (1996?). Conflicts between the possibilities and the reality in the field of structured electronic documents : experiences from a large-scale SGML-project. Verkkojulkaisu: <URL:http://internet.adb.gu.se/publications/14/conflict.html>

Kondrach, George (1997a). DTD testing: find the devils in the details. Teoksessa SGML/XML'97 conference proceedings, December 8-11, 1997, Washington, D.C., s. 133-141. Alexandria, VA: Graphic Communications Association.

Kondrach, George (1997b). DTD testing: find the devils in the details. SGML/XML'97, December 8-11, 1997, Washington, D.C. (suullinen esitelmä, Jörgen Westerlingin muistion mukaan).

Nikunen, Erja, Elina Kuikka (1996). YAPE - Yet Another Perfect Editor. Teoksessa Proceedings of SGML Finland 1996, Hotel Korpilampi, Espoo, October 4-5, 1996, s. 47-55. Helsinki [?] : SGML User's Group Finland.

Preece, Jenny et al. (1994). Human-computer interaction. Wokingham : Addison-Wesley.

Sørgaard, Pål, Tone Irene Sandahl (1997). Problems with Styles in Word Processing: A Weak Foundation for Electronic Publishing with SGML. Verkkojulkaisu: <URL: http://internet.adb.gu.se/publications/6/pap.html>.

Travis, Brian E, Dale C. Waldt (1995). The SGML implementation guide : a blueprint for SGML migration. Berlin : Springer.

Westerling, Jörgen (1997a). HUTpubl_HTML32.dsl - DSSSL specification for HUTpubl to HTML 3.2 conversion. Verkkojulkaisu: <URL: http://www.hut.fi/Yksikot/Kirjasto/HUTpubl/technical/HUTpubl_HTML32.dsl>

Westerling, Jörgen (1997b). Document Type Definition for HUT publications. Verkkojulkaisu: <URL: http://www.hut.fi/Yksikot/Kirjasto/HUTpubl/technical/HUTpubl.dtd>

Tekniikkaliite

Yhteenveto HUTpubl-testaajien testipalavereissa esiin tulleista kommenteista ja kysymyksistä.

Elementtihin liittyviä kysymyksiä kysyttiin seuraavasti:

1. Tiivistelmien määrää kysyttiin, ja todettiin että tiivistelmiä voi määrittää useampia ja eri kielille käyttämällä <abstract>-elementin kieliattribuuttia lang.
2. Kysyttiin millä elementillä merkitään ylimmän tason lukujen (chapter) otsikot ja todettiin että ylimmän tason lukujen otsikot merkitään <head>-elementillä.
3. Kysyttiin miten ja missä merkitään sanastojen sanat ja niiden kuvaukset ja todettiin että sanaston sanat merkitään tekstin sekaan elementillä <glossterm>. Sanojen kuvaukset merkitään myös tekstin sekaan elementillä <glossdef>. Itse sanasto (glossary) generoidaan automaattisesti edellämainittujen mukaan. Sanoille on määriteltävä id-attribuutti ja sanojen kuvauksille vastaava refid-attribuutti.
4. Kysyttiin miten merkitään lähde taulukon alle ja todettiin että taulukon lähde kannattaa merkitä tavallisena kirjallisuusviitteenä (<xref type="bibl">) taulukon otsikkoon (<caption>).
5. Kysyttiin jos erityyppiset lähteet voi erotella eri otsikoiden alle lähdeluettelossa (esim. viitatut lähteet, muut lähteet, keskustelut) ja todettiin että tällä hetkellä kaikki lähteet tulee merkitä saman viiteluettelon (<bibl>) alle.
6. Kysyttiin jos kirjallisuusluettelon voi sijoittaa jokaisen luvun jälkeen ja todettiin että tällä hetkellä se ei ole mahdollista, vaan viitteet kootaan yhteen julkaisun takaosaan (<back>).
7. Kysyttiin jos on mahdollista jotenkin merkitä kielentarkastajien tekemiä muutosehdotuksia ja todettiin että tähän tarkoitukseen DTD:hen lisätään kaksi uutta elementtiä. <change>-elementin avulla merkitään se osa dokumenttia joka pitäisi muuttaa. <suggestion>-elementin avulla merkitään ehdotuksia muutokseksi. Nämä elementit liitetään yhteen id- ja refid-attribuuteilla.
8. Kysyttiin voiko taulukoiden kehyksiä jotenkin esittää HUTpubl-rakenteessa ja todettiin että tällä hetkellä taulukkorakenne ei tue raamien asettamista, vaan se tapahtuu käytettävässä editorissa. Taulukkomalli tullaan ehkä laajentamaan CALS-standardin mukaiseksi, jolloin raamien määrittely voidaan tehdä suoraan rakenteeseen.

FrameMaker+SGML-ohjelmistoon liittyviä kysymyksiä kysyttiin seuraavasti:

1. Kysyttiin onko Framen dokumenttipohjat tehty kaksipuolisille dokumenteille ja todettiin että näin on. Sekä A4-pohja että B5-pohja on tehty kaksipuolisille julkaisuille.
2. Kysyttiin jos julkaisun ulkomuotoa voi itse muuttaa Framen paragraph designerista ja todettiin että jos haluaa muutoksia julkaisun ulkonäköön, olisi suotavaa jos otettaisiin yhteyttä projektin henkilökuntaan. Tämä siksi että kaikki ulkonäölliset asetukset ovat määritelty EDD:ssä ja mutoksetkin pitäisi tehdä tässä samassa tiedostossa.
3. Kysyttiin miten tavutuksen saa oikealla kielellä päälle FrameMaker+SGML:ssä ja todettiin että se ominaisuus ei vielä oltu määritelty FrameMaker+SGML-ohjelmiston EDD-määrittelyihin. Tämä korjattiin myöhemmin, ja nyt dokumentit tavutetaan sen kielen mukaan mikä on määritelty dokuementin kieleksi (HUTpubl-elementin Lang-attribuutin avulla).

Muutoksia HUTpubl DTD:ssä jotka tehtiin testaajien palautteesta:

1. <symbol> ja <symboldef>- elementit lisättiin symbolien ja niiden määrittelyjen merkkamiseksi.
2. <front>-elementin sisältömalli muokattiin siten että jokaisen (erikielisen) tiivistelmän jälkeen voidaan laittaa samankieliset avainsanat.
3. Jotta mahdollistettaisiin kielentarkastajien merkinnät dokumentteihin rakennekuvaukseen lisättiin kaksi elementtiä tähän tarkoitukseen. <change>-elementillä kielentarkastaja voi merkata jo olemassa olevaa tekstia jota hän esitää muutettavaksi. <suggestion>-elementillä tarkastaja voi ehdottaa miltä muutettava teksti voisi näyttää. Elementit kytketään yhteen ID-IDREF-mekanismillä.
4. Puuttuva <glossdef> elementti lisättiin.
5. Liitteiden <appendix>-elementin sisältö muutettiin siten että se sisältää samat elementit kuin <chapter>-elementti alalukuja lukuun ottamatta.
6. Lista-alkioiden <listitem>-elementti voi nyt pitää sisällään kappaleita.
7. Kirjallisuusluettelo, <bibl>, sai attribuutin jolla määritellään mitä viittausjärjestelmää käytetään (Harvardin vai numeroituja viitteitä).
8. Verkkojulkaisujen viiteiden, <netres>, malli oli puutteellinen, joten se muutettiin SFS:n 5342 mukaiseksi kuten muutkin viitetyypit.