Hypermediaohjelmointi

Heikki Salo

Armonkallion ATK ja estetiikka
Motto: korkean tason ohjelmointivälineet muuttavat ohjelmoinnin luonnetta - abstraktiotaso nousee, jolloin suunnittelun ja valmistelun merkitys korostuu.

Sisältö
Hypermediaohjelmointihanke kokonaisuus
Toteutuksen jäsentäminen
Aikaresurssi
Henkilöresurssit
Raharesurssit
Työryhmästä
Ohjelmointi
Aineiston järjestäminen
Ohjelmavirheiden korjaaminen ja jälkihoito
Lähteitä

Hypermediaohjelmointihanke kokonaisuus

Ohjelmointiprojekti on muiden projektien tapaan aika-, henkilö- ja raharesursseiltaan rajallinen määriteltyyn tavoitteeseen pyrkivä toiminto. Hypermediadokumenttien ohjelmointi tulee käsittää varsin väljästi, suuri osa ohjelmoinnista kun on itse asiassa näyttöjen suunnittelua ja asiakokonaisuuksien koostamista ja järjestämistä sopivien navigointipolkujen avulla. Lopultakin toteutettavat ohjelmointikieliset osuudet riippuvat tarpeelliseksi katsottavasta aineistosta ja sen toteutustavasta. Hypermediadokumentit sisältävät tekstiä, kuvaa, demonstraatioita, simulaatioita ja ääntä. Hypermediaohjelmointia suoritetaan perinteisestä ohjelmoinnista poiketen varsin korkealla abstraktiotasolla, ja voitaisiin sanoa hypermediaohjelmoinnin tietorakenteiden olevan teksti, ääninäyte, kuva, animaatio ja videoleike. Äänen käyttöä on syytä suunnitella huolellisesti, niiden viestinnällinen hyöty/kustannus -suhde on varsin ongelmallinen ja kulttuurisidonnainen, parhaimmillaan ääniä voidaan käyttää tehosteina varoittamaan, korostamaan tai ilmaisemaan esimerkiksi ajatuksellisesti pitkiä siirtymiä asiakokonaisuuksien välillä. Lisäksi voidaan helposti huomata äänten olevan sidoksissa paitsi kohdekoneiden toistomahdollisuuksiin ja dokumentin käyttäjien makumieltymyksiin ja kuuntelutottumuksiin. Kaiken kaikkiaan äänen käyttö vaatii ammattitaitoa ja huolellista suunnittelua.

Toteutuksen jäsentäminen

Tavoitteen määrittelyssä suosittelisin teatterikappaleitten näyttämöllepanossa käytettyä menetelmää, jossa kokonaisuudelle kiinnitetään aluksi pääsanoma. Pääsanomalla ymmärretään sitä viestiä, jonka lopullisen esityksen halutaan katsojille välittävän. Käytännössä se on muutamalla lauseella ilmaistu väljästi määritelty ajatus, johon sitten kaikkia näyttämö- ja ohjausteknisiä ratkaisuja testataan - miten ne tukevat määritellyn sanoman perillemenoa. Hypermediatoteutukselle voidaan määritellä vastaavasti päätehtävä tai -tarkoitus, jota sen tulee toteuttaa - määrittelyn väljyys tai yksityiskohtaisuus riippuu luonnollisesti lopullisen sovelluksen käyttötarkoituksesta (käyttöliittymän päätehtävä vaatinee yksityiskohtaisempaa määrittelyä kuin itseopiskeluun tarkoitetun ohjelman).

Näytelmän työstön seuraava vaihe on kohtauksiin jäsentäminen. Toisin kuin teatterissa, hypermediadokumentin osatehtäviin jäsentämiseen kytkeytyy käsikirjoituksen eli storyboardin laatiminen. Tässäkin voitaisiin soveltaa teatterin ja elokuvan piiristä tuttuja tekniikoita: hajoitetaan dokumentin osat (kohtaukset) sisällölliseen (sanomalliseen) ja toteutukselliseen (näyttämölliseen) kuvaukseen. Mielestäni sisällöllisessä osituksessa tulisi pyrkiä mahdollisimman varhaisessa vaiheessa lukkoon lyötyihin ratkaisuihin.

Hypermediadokumenttien asiasisällön tarkentaminen liittyy kiinteästi toteutuksellisten ratkaisujen kiinnittämiseen. Käytännössä tämä tarkoittaa päättämistä siitä, mitkä dokumentin osat toteutetaan tekstimuotoisina, mitkä kuvan, grafiikan tai videoleikkeiden ja mitkä demonstraatioiden ja simulaatioden avulla. Toteutuksellisissa ratkaisuissa tulee toisaalta huomioida käyttäjien asettamat vaatimukset selkeyden ja ymmärrettävyyden suhteen ( 'pitääkö piirtää vai vääntää malli' ) ja toisaalta kohdelaitteistojen ja -ohjelmiston rajoitukset (voidaanko käyttää värejä, videoleikkeitä jne). Perinteisen ohjelmoinnin termein tätä vaihetta voitaisiin kuvata tietorakenteiden suunnitteluvaiheeksi. Kohdelaitteiston asettamiin rajoituksiin voidaan varautua suunnittelemalla erilaisia vaihtoehtomalleja, esimerkiksi videoleikkeet voidaan korvata animaatioilla ja rasterikuvat vektorigrafiikalla.

Navigointistrategioiden (sallitut/halutut) suunnittelu mielestäni edellyttää dokumentin asiasisällön jonkinasteista kiinnittämistä. Assosiatiivisesti jäsennetystä tiedosta voidaan sanoa olevan 'niin monta mallia kuin on miestäkin', joten mitään selvää ja yksinkertaista ohjetta on mahdoton antaa. Hyvin määritelty päätehtävä ja tehtävän ositus jo itsessäänkin antavat osviittaa siitä mitkä lukemis-/tutkimispolut ovat tarkoituksenmukaisia ja järkeviä. Näytelmässä on pääjuoni ja sitä kommentoivia sivujuonia - hypermediadokumenteissa 'juonet' on toteutettu navigointipolkujen avulla.

Hypermediadokumenttien vallankumouksellisin ja sitä myötä vaikeimmin hallittava ominaisuus on muokattavuus. Työn viihtyisyyttä ja työmotivaatiota voidaan usein lisätä esimerkiksi sallimalla käyttöliittymän muokkaaminen enemmän 'käteen sopivaksi'. Jonkin asian ymmärtämistä ja hallitsemista on perinteisesti totuttu helpottamaan muistiinpanoin, reunamerkinnöin ja selventävin luonnospiirroksin. Mikä on lopullisessa toteutuksessa yksittäisen lukijan reunamerkintöjen ja muistiinpanojen suhde dokumenttiin, nehän voisivat parhaimmillaan avustaa muitakin dokumentin lukijoita. Onko tarkoituksena jakaa lopullinen tuote kopio/käyttäjä vai jakaa se hypermediapalvelimella paikallisverkkoon. Sallitaanko käyttäjän luoda omia navigointipolkujaan, muuttaa dokumentin polkuja? Lähimmäs perinteisiä ohjelmointitehtäviä joudutaan juuri toteutettaessa navigointi- ja muokattavuusstrategioita, usein vieläpä niin että niiden toteuttaminen ja toimivuuden varmistaminen vievät runsaasti ohjelmointiaikaa.

Aikaresurssi

Projektin kestoon voidaan lukea mukaan hankkeen määrittely, aineiston keruu, itse toteutus (layout ja varsinainen ohjelmointi) ja testaus. Perinteisen käsityksen mukaan ohjelman elinkaareen lasketaan myös ohjelman ylläpito, hypermediadokumenteissa erilaiset ylläpito- ja 'jälkihoitotoimenpiteet' korostuvat. Jos halutaan saada dokumenttien navigointi- ja yhdistelymahdollisuuksista sekä muokattavuudesta mahdollisimman suuri hyöty ja mahdollisesti kehittää yrityksen tietojenkäsittelyä edelleen mahdollisimman paljon hypermedian suuntaan, on aivan ensiarvoisen tärkeää kerätä tietoa dokumenttien loppukäyttäjien kokemuksista dokumenttien ymmärrettävyydestä, käyttöasteesta ja käytön mukavuudesta. Toteutettavan hankkeen (käyttöliittymä vai opastava dokumentti) luonteesta riippuen aineiston keruu ja/tai toteuttaminen vievät aikaa. Nyrkkisääntönä voidaan pitää, parempi liikaa kuin liian vähän. Jos yrityksessä halutaan suosia hypermediaa, on syytä vakavasti harkita mahdollisten olemassa olevien kuva-arkistojen muokkaamista sellaiseen muotoon, jossa ne ovat tulevaisten projektien hyödynnettävissä.

Kärjistäen voisi sanoa: mitä paperittomampi konttori, sitä nopeampaa on hypermediadokumenttien tuottaminen.

Henkilöresurssit

Työryhmän koko riippuu luonnollisesti ohjelmointihankkeen laajuudesta, siis päätehtävästä. Hypermediadokumenttien toteutuksellinen monimuotoisuus asettaa aivan erityisiä vaatimuksia työryhmän asiantuntemukselle ja ammattitaidolle. Vaaditaan yhtäällä esteettistä ja psykologista silmää näyttöjen tehokkaaseen ja toimivaan suunnitteluun, toisaalla ohjelmointiteknistä osaamista dokumentin selaamisen mahdollistavien navigointipolkujen - linkitysten - toteuttamiseen. Milloin toteutettava kokonaisuus on laaja tarvitaan informaatikkoja, jotka osaavat jäljittää ja valita määriteltyjen päätehtävän ja osatehtävien kannalta tarkoituksenmukaista aineistoa. Erityisen paljon informaatikon osaamista edellyttää materiaalin moninaisuus.

Raharesurssit

Valmisohjelmien hankintaa perustellaan omatuotannon kalleudella, samoja perusteluja voidaan soveltaa ainakin yrityksen ensimmäisten hypermedianimikkeiden osalta. Toisaalta toteutukset ovat usein niin sisällöltään kuin toteutustekniikoiltaan yritykseen ja sen toimialaan sitoutuneita, että on vaikeata löytää valmiita sovelluksia. Hypermediadokumentit ovat ohjelmakoodiltaan yleensä selkeän modulaarisia ja avoimia, niihin sisältyvää varsinaista koodia voidaan lähes pääsääntöisesti muokata, kopioda ja kehittää edelleen. Tämä ohjelmakoodin uudelleenkäytettävyys asettaa yrityksen omien ohjelmointihankkeiden kannattavuuslaskelmat uuteen valoon. Jos halutaan yrityksen tasolla tietojenkäsittelyssä sitoutua laajemmin hypermediaan, niin voidaan dokumentteja suunniteltaessa ja käynnistettäessä pyrkiä mahdollisimman suureen ohjelmakoodin uudelleenkäytettävyyteen.

Hypermediadokumenttien sisältö määrää paljolti niiden toimivuuden ja käyttökelpoisuuden. Kärjistetysti voidaankin väittää dokumentin sisältämän materiaalin hankkimisen ja tuottamisen olevan ohjelmointiakin kalliimpaa: jos käytetään muitten valmistamaa kuva- ja tekstiaineistoa, on varauduttava sijoittamaan tekijänoikeuksiin paitsi rahaa myös aikaa ja vaivaa. Pyrittäessä tuottamaan tarvittava aineisto itse, on varauduttava paitsi lisälaiteinvestointeihin, myös erityistaitoisen henkilöstön kiinnittämiseen projektin miehitykseen. Huolellisesti suunniteltu ja toteutettu hypermediatoteutus, mm. hallinnollisissa sovelluksissa, jalostavaa yrityksen tietovirtoja ja niiden käsittelyä siinä määrin, että investoinnit maksavat itsensä takaisin paitsi kustannussäästöinä myös parhaimmillaan lisääntyneenä työviihtyvyytenä ja -motivaationa.

Työryhmästä

Edellä mainitsemani toteutusympäristön 'monivälineisyys' asettaa melkoisia vaatimuksia niin työryhmän sivistyneisyydelle kuin ammattitaidollekin. Toteuttavassa ryhmässä pitäisi olla tietojenkäsittelijä, joka tuntee ja hallitsee ohjelmoinnin ja tiedonhallinnan ongelmia; graafikko, joka hallitsee kuvallisen ja videoilmaisun tekniikoita riittävässä määrin; työryhmässä pitäisi jonkun pystyä arvioimaan loppukäyttäjän näkökulmasta toteutuksellisten ratkaisujen ja valitun aineiston laatua, sen toimivuutta ja käyttökelpoisuutta; dokumenttiin liitettävän materiaalin hallinta vaatii eri tietolähteiden jäljittämistä, materiaalin hankintaa ja arkistointia.

Parhaimmillaan jokainen ryhmän jäsen saattaisi toimia jonkin, joko osakokonaisuuden tai materiaalityypin (kuva, teksti, video) informaatikkona, ts. voisi kertoa mitä materiaalia ja mistä voidaan hankkia ja soveltaa. Informaatikon asennetta vaaditaan myös ohjelmoijalta, joka toteuttaa, kerää, jäljittää ja arkistoi toteutuksellisten ratkaisujen edellyttämiä ohjelmamoduuleja.

Tehokkaan ja toimivan toteutuksen aikaansaaminen edellyttää työryhmältä luovan hengen säilyttämistä. Tällöin toteutuksen määrittelyn tulisi olla riittävän tarkka, jotta se voisi olla projektin ohjaamisen, tehtävänjaon ja osatehtävien tarkentamisen perusta, kuitenkin siten että se kannustaisi varsinaisen toteutusvaiheen aikana luoviin ratkaisuihin.

Työryhmässä pitää olla paitsi loppukäyttäjien työtehtävien tuntemusta myös tietoa siitä mitä ja mistä löytää teksti, kuva ja videomateriaalia. Projektin toteuttavassa ryhmässä tarvitaan siis graafikkoa, käsikirjoittajaa, ohjelmoijaa ja informaatikkoa toteuttamaan tarvittavan video-, kuva- ja tekstimateriaalin suunnittelua, keruuta ja tuottamista, teknisten ratkaisujen ohjelmointitoteutusta varten ja hankkeen koosta riippuen myös projektisihteeriä.

Ohjelmointi

Hypermediadokumenttien tuottamiseen tarkoitetuissa ohjelmointiympäristöissä sovelletaan yleensä samoja periaatteita. Usein kuulee näitä ympäristöjä väitettävän olio-ohjelmointia tukeviksi tai niihin perustuviksi ohjelmointiympäristöiksi. Tämä kuitenkin pitää vain osittain paikkansa: useimmiten ohjelmointiympäristöt tukevat vain olion käsitettä.

Dokumentit koostetaan ikkunoista, tekstikentistä, painikkeista ja/tai videoleikkeistä, joihin voidaan liittää erilaisia toimintoja. Esimerkkinä Hypercard, sillä luodut dokumentit perustuvat korttimetaforalle; sovellus eli pino muodostuu korteista, korteilla on pohja, joka on useammalle kortille yhteinen - pinossa voi olla useampiakin pohjia. Esimerkiksi jos olen tallettanut äänilevystöni tiedot käsikortistoon, blueslevyt sinisille korteille, jatsit keltaisille jne., niin äänilevykortistoni vastaisi pinoa, kortiston kortti korttia ja värit pohjia - niin korttiin kuin pohjaankin voidaan sijoitella lukuisa määrä tekstiä sisältäviä kenttiä ja/tai painikkeita sekä joko piirtää tai digitoida kuva. Pinoon, korttiin, pohjaan, kenttiin ja painikkeisiin voidaan kiinnittää toimintoja kirjoittamalla ohjelmia ko. olion ohjelma-asuun eli käsittelijään - minkä lisäksi joillakin olioilla on ominaisuuksia, joita voidaan ohjelmallisesti asettaa. Esimerkiksi kenttä tai painike voidaan ohjelmasta asettaa näkyväksi tai näkymättömäksi.

Hypercardin, niin kuin muidenkin hypermediaohjelmointiympäristöjen, ohjelmointi voidaan jakaa kahteen tasoon: 'scriptien laatimiseen', eli perinteisempään ohjelmointiin, ja korkean tason ohjelmointiin. Hypermediaprojektin jokaisen jäsenen tulisi mielestäni hallita vähintään korkean tason ohjelmoinnin periaatteet. Varsinaisten skriptien suunnitteluun, olioihin paikantamiseen ja toteuttamiseen (koodaamiseen) pitäisi mielestäni kouluttaa muuta ohjelmointikokemusta omaava ammattilainen.

Esimerkkinä korkean tason ohjelmoinnista uuden painikkeen luominen ja yhdistäminen tai linkitys. Alla (kuva 1) hypercardissa luotu painike: "uusi painike".

kuva 1. 'Objektit'-menusta valittu komento 'Uusi painike'

Korkeimmalla abstraktiotasolla olioiden käsittely (ominaisuuksien ja käyttäytymisen määrittely) ei edellytä käytännössä minkäänlaisia ohjelmointiteknisiä valmiuksia, vaan esimerkiksi painikkeen sijainti ja koko voidaan määritellä osoitinlaitteen (hiiren) ja valikkokomentojen avulla. Muita ominaisuuksia voidaan sitten edelleen määritellä määrittelydialogien (template) avulla. Esimerkki yllä luodun painikkeen ominaisuuksien määrittelystä. Valitun painikkeen muokkausdialogi saadaan valitsemalla 'objektit'-menun komento 'painikkeen tiedot'.

kuva 2. Painikkeen ominaisuuksien määrittely dialogin avulla.

Jos käyttäjä haluaa yhdistää luodun painikkeen uuteen asiakokonaisuuteen, hän painaa dialogin (kuva 2) 'linkitä...' - painiketta ja saa näytölleen seuraavan dialogin, minkä jälkeen hänen on siirryttävä joko 'mene'-menun komentoja hyväksikäyttäen haluamaansa korttiin tai luotava uusi kortti 'muokkaus'-menun 'uusi kortti' komennolla. Tämän jälkeen käyttäjän on hyväksyttävä linkki kuittaamalla dialogin 'Tämä kortti' painike. (kuva 3)

kuva 3. Linkitysdialogi sallii navigoinnin pinoissa ja kortteissa. Kuitattaessa palataan lähtökorttiin.

Linkitys luo painikkeelle seuraavan skriptin (kuva 4.), joka on muunneltavissa muokkausdialogin (kuva 2.) 'ohjelma...' -painikkeen avulla. Painikkeeseen on nyt liitetty aliohjelma 'mouseUp', jota kutsuttaessa siirrytään korttiin, jonka yksikäsitteinen tunnusnumero on 3649. Ohjelmointityön kannalta on mielekästä sopia nimeämiskäytännöstä, jolla nimetään pinot, kortit, pohjat, kentät ja painikkeet - nimeämistrategian suunnittelusta ja noudattamisesta vastaa ryhmän ohjelmointivastuullinen jäsen. Nimeämisen jälkeen voidaan kohteisiin viitata annetuilla nimillä tunnuslukujen sijaan.

kuva 4. Painikkeeseen liitetty aliohjelma 'mouseUp'

Ylläolevan aliohjelman käyttäytymistä voidaan muutella sisällyttämällä ohjelmaan lisäkomentoja, esimerkiksi 'hide card picture', 'show background picture', play "Bogart" tms.
Olioiden skriptien sisältämien ohjelmien kutsuminen tapahtuu viestien avulla. Esimerkin 'mouseUp' -viesti lähetetään luodulle painikkeelle, kun hiiren näppäintä painetaan kursorin ollessa painikkeen kohdalla. Jos painikkeen skripti sisältää aliohjelman 'mouseUp', se suorittaa aliohjelman - ellei, niin viesti välittyy esimerkiksi Hypercardissa edelleen alla olevan viestipolun mukaisesti (kuva 5). Yleensä hypermediaohjelmistojen ohjelmointiympäristöt on toteutettu kuvatun viesti-käsittelijä mallin mukaisesti (esim. Hypercard, Toolbook, Macromind Director). Käyttäjällä on mahdollisuus täydentää järjestelmään valmiiksi sisältyviä viestejä itse määritellyillä käsittelijä-aliohjelmilla. Joissakin ympäristöissä on myös mahdollisuus liittää muilla ohjelmointikielillä toteutettuja toimintoja järjestelmän omien mahdollisuuksien täydennykseksi ja tueksi. Näitä kutsutaan ulkoisiksi komennoiksi. Ulkoisia komentoja tarvitaan erityisesti silloin kun halutaan sovelluksen sisältä ohjata tietokonejärjestelmään liitettyjä muita laitteistoja (esim. valaistus, tuotantolinja tms).
Viestejä käsittelevien aliohjelmien sijoittaminen ja mahdollisten ulkoisten lisärutiinien suunnittelu, laatiminen, toteuttaminen ja kutsupolulle sijoittaminen on syytä jättää ammattitaitoisen ja kohteena olevan laiteympäristön tuntevien ohjelmoinnin ammattilaisten huoleksi. Ulkoisia komentoja toteutettaessa on usein myös syytä käyttää toteutuksen apuna ja tukena tarkoitukseen sopivia ohjelmointiympäristöjä (esim. Hypercardia täydennettäessä MPW:tä tms.).

kuva 5. Hypercardin viestien käsittely- ja välitysjärjestys, nuolet osoittavat viestien kulkusuuntaa. Kuvassa vasemmalla näkyvä ikonivalikko sisältää selaus-, painike-, kenttä- sekä graafiset työkalut.

Hypermediaprojekteihin liittyvään skriptien ohjelmointiin täytyisikin kiinnittää koulutuksen saanut ohjelmoinnin ammattilainen, joko niin, että sellainen palkataan projektia varten erikseen tai erikoistutetaan joku yrityksessä jo olevista tietojenkäsittelijöistä hypermedian ohjelmointitekniikoista. Projektiryhmän ohjelmoijan tulee tukea ryhmän muiden jäsenten sisällöllisiä oivalluksia ja ehdotuksia, siten että hänelle esitetään toteutussuunnitelmia, joiden tekniset toteuttamismahdollisuudet hän arvioi laitteiston ja ohjelmiston suhteen toteuttaen ne mahdollisuuksien mukaan. . Hyperromaaniprojektissa aineistoa toteuttaville jäsenille esitettiin myös erilaisia yksinkertaisia tekniikoita, esim. animoitujen jaksojen toteuttamista varten, joita he sitten sovelsivat kykyjensä ja mielikuvituksensa mukaan. Näin saadaan lisättyä lopullisen dokumentin moni-ilmeisyyttä.
Toteuttamismahdollisuuksien arvioinnissa on suureksi avuksi edelleen 'informaatikon asenne', so. järjestelmällinen hypermediasovellusten kirjaston kerääminen erilaisia innovatiivisia toimintoja sisältävistä sovelluksista. Usein haluttu toiminto voidaan toteuttaa lainaamalla malli jostain jo ennestään olevasta sovelluksesta. Tällöin laaja erilaisten sovellusten tuntemus ja saatavuus on ensiarvoisen tärkeätä. Mika Waltari sanoi lukemisen olevan kirjailijan tärkein itseopiskelun muoto. Samaa ajatusta voitaneen soveltaa hypermediaohjelmointiinkin.

Aineiston järjestäminen

Aineiston järjestäminen erilaisten navigointireittien mukaan vaatii yleensä eniten matalan tason ohjelmointia (skriptejä). Suositeltavaa on valita jokin perusmalli, joka toimii dokumentin selaamisen selkärankana. Alla kolme perusvaihtoehtoa, joita voidaan mainiosti käyttää navigointistrategioitten suunnittelun lähtökohtina.

kuva 6. Lineaarinen navigointimalli

Perinteinen esitysten jäsentämismalli, dokumentin selaajalle helposti miellettävä painotuotteista tuttu rakenne, joka ei tosin hyödynnä hypermedian tarjoamia mahdollisuuksia. Usein lineaarista mallia täydennetäänkin esimerkiksi selittävillä tekstikentillä. Saattaa olla varsin käyttökelpoinen jos käyttäjälle annetaan mahdollisuus liittää helposti osiin omia kommenttejaan.

kuva 7. Hierarkkinen navigointimalli

Useimmat hypermediadokumentit on järjestetty hierarkkisen mallin mukaan. Onkin helppoa esittää esimerkiksi laitteistojen teknisiä dokumentteja asteittain tarkentuvina dokumentteina, jolloin käyttäjät voivat valita itselleen sopivan yksityiskohtaisuuden tason. Tästä syystä usein hierkkisten dokumenttien abstraktiotasot linkitetään lineaarisesti, jolloin samalla tasolla liikkuminen on vaivatonta. Linkit totettavat ikonit on syytä suunnitella huolellisesti, niiden sijainti ja ulkoasu täytyy olla käyttäjälle selkeä luonteva ja johdonmukainen. Jos hierarkiatasoja on paljon ja niistä muodostuva kaaviopuu on kovin epätasapainoinen, on tasojen väliset takaisinpaluureitit suunniteltava tarkasti.

kuva 8. Säteittäinen tai tähtimäinen navigointimalli

Sovelletaan usein dokumentin osakokonaisuuksiin, esim. kartat, rakennusten pohjapiirrosten avulla toteutetut henkilöhakemistot ja messualueitten infopisteet yms.
Usein navigointimalleja on yhdistelty, niin että esimerkiksi päähakemisto on rakenteeltaan säteittäinen, jonka joitakin haaroja on täydennetty lineaarisilla tai hierarkkisilla osamalleilla.
Navigointimallien toteutuksessa voidaan käyttää erilaisia tekstikenttien avulla toteutettavia indeksejä, joista tekstiä - rivejä tai sanoja - aktivoimalla voidaan voidaan siirtyä uuteen asiakokonaisuuteen. Eräs tapa on käyttää kuvaa hakemiston perustana, esimerkiksi organisaatiokaavioita tai rakennepiirroksia, jolloin kuvan osia aktivoimalla voidaan siirtyä osia käsitteleviin kokonaisuuksiin. Ehkäpä lopulta kaikkein vaativin niin suunnittelultaan kuin toteutukseltaankin on toteuttaa navigointi niin, että käyttäjä tietää miten käsillä oleva dokumentin osanen suhtautuu kokonaisuuteen ja miten käyttäjä pidetään tietoisena siitä, mitä dokumentin osia hän on jo selannut ja miten hän pääsee takaisin tutulle navigointipolulle. Suositeltavaa onkin liittää dokumenttiin erilaisia ankkuroitumispisteitä. Käyttäjän kannalta hankalimpia ovat voimakkasti ristiin rastiin linkitetyt dokumentit, joiden alku- ja päätepisteet eivät oikein erotu muusta aineistosta, tällöin käyttäjä saattaa 'eksyä hyperavaruuteen'.

Ohjelmavirheiden korjaaminen ja jälkihoito

Projektin päätyttyä ja dokumentin valmistuttua on tärkeätä seurata ja kirjata käyttäjien kokemuksista paitsi ohjelmointivirheiden paikallistamiseksi ja korjaamiseksi myös kokemuksen saamiseksi toteutusratkaisujen toimivuudesta. On suositeltavaa kerätä tietoa käyttäjien mielipiteistä siitä; mitkä painikkeitten ikonit ovat epäselviä, mitkä toiminnot hämmentävät, mitä navigointipolut tuntuvat vaikeilta jne. Eräs harkinnan arvoinen toteutusvaihtoehto voisi olla jonkinlaisen käyttöpäiväkirjan liittäminen osaksi dokumenttia. Hypermedian erään ominaisuuden mukaan se voisi olla vuorovaikutteinen, niin että käyttäjät käytön myötä oppisivat antamaan käyttövihjeitä ja -ohjeita toisilleen 'Käyttäjän tietolaari' tyyliin.

Lähteitä

Ambron, Sueann; Hooper, Kristina eds. Interactive Multimedia. Microsoft Press. Redmont, Washington. 1988.
Bush, V. As we may think. (pp 101-108). Atlantic Monthly 176, 1. July 1945.
Heimbürger, Anneli, Alkula, Riitta, Kuhanen, Taru. Hyperteksti ja Hypermedia. Valtion teknillinen Tutkimuskeskus, Tiedotteita 1154. Espoo 1990.
Krueger, Myron, W. Artificial reality. Addison-Wesley. Reading, Mass. 1983
Hypertext '89 Proceedings. Special Issue - ACM SIGCHI Bulletin. ACM Press. New York. 1989.