è è è Web & tekstiformaatit 4 Web & tekstiformaatit Verkkopalvelun käyttöliittymä ja sisältö eivät yleensä käsitä pelkästään (X)HTML-muotoisia dokumentteja. Tämä asettaa suuria haasteita teknisen saavutettavuuden suunnittelulle (riippuvuudet!) ja toteutukselle. Toisinaan verkkosivut tarjoavat vain pääsyn lähinnä "toimisto-ohjelmien" ymmärtämiin dokumenttityyppeihin (esim. PDF, RTF, PPT, PS) Luonnehditaan seuraavaksi lyhyesti vektorikuvien ja videoesitysten taustalta löytyviä tekstiformaatteja ja pohditaan mitä dokumenttien skriptiohjelmointi tarkoittaa saavutettavuuden näkökulmasta. 65
è è è Web & tekstiformaatit 4.1 Välisoitto Sovellusten tekniset vaatimukset näkyvät selkeimmin tilanteissa joissa kaikki ei toimi toivotusti Teknologiavalinta on vaikea osa suunnittelua (koska asioiden tulee toimia käytännössä) Saavutettavuuden näkökulmasta kehitystyö on tasapainoilua tekniikan mahdollisuuksien ja legacymaailman kanssa 66
è è è Web & tekstiformaatit 4.2 Jonosta (teksti) avaruuteen (grafiikka): SVG XHTML on "vain eräs" XML-tekstiformaatti Samalla perustekniikalla (XML) voidaan kuitenkin kuvailla (tai prosessoida) mitä tahansa tietoa - "yleisesti käytössä olevia" XML-tekstiformaatteja on satoja; "kuka tahansa" voi kehittää niitä lisää (mutta hyvän tekeminen...) Tyyppiesimerkki hyödyllisestä graafisten objektien (ja animaatioiden, yms.) kuvailuformaatista on SVG (Scalable Vector Graphics) Myös SVG-grafiikan saavutettavuuteen voi kiinnittää huomiota - käytännössä: objektirakenteen miettiminen, tekstivastineiden liittäminen objekteihin Kuvat: I. Herman 67
è è è Web & tekstiformaatit 4.3 SVG-dokumentin rakenne SVG-dokumentti on kuten XHTMLdokumentti, mutta XHTML-sanaston ja hypertekstin yms. sijaan puhuu SVG-sanaston avulla grafiikasta, filttereistä, jne. <?xml version="1.0" encoding="iso-8859-1" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/graphics/svg/1.1/dtd/svg11.dtd"> <svg width="12cm" height="4cm" viewbox="0 0 1200 400" xmlns="http://www.w3.org/2000/svg" version="1.1"> <ellipse cx="600" cy="200" rx="550" ry="175" fill="yellow" stroke="blue" stroke-width="20"/> <rect x="1" y="1" width="1198" height="398" fill="none" stroke="blue" stroke-width="2" /> <polygon fill="red" stroke="blue" stroke-width="10" points="350,75 379,161 469,161 397,215 423,301 350,250 277,301 303,215 231,161 321,161" /> <polygon fill="lime" stroke="blue" stroke-width="10" points="850,75 958,137.5 958,262.5 850,325 742,262.6 742,137.5" /> <text x="470" y="240" font-size="70">tekstiä</text> </svg> 68
è è è Web & tekstiformaatit 4.4 Skriptatut dokumentit XML-sovellukset tarjoavat tyypillisesti mahdollisuuden liittää dokumentteihin (esim. XHTML tai SVG) myös tapahtumaohjattuja selaimessa ajettavia skriptejä (esim. Ecmascript [Javascript], VBScript) - esim. hiiren liike, napinpainallus, ajastettu tapahtuma DOM-manipulointi Yleensä skriptien käyttö heikentää dokumenttien saavutettavuutta (...koska skripti voi toimia "selaimen käyttöliittymän ohi" määrittelemättömyys) Skriptien käytölle on hyvin huonoja, huonoja ja melko hyviä perusteita - hyvin huono syy on turha erikoistehoste, esim. näyttöelementin liikuttelu - melko huono syy voi olla esim. käyttöliittymän hallittu laajentaminen, esim. fiksu statuskenttä (dokumentin loogista rakennetta rikkomatta) - ok- peruste on rajattu sovellus, jonka selain ja käyttäjäkunta on tarkkaan tunnettu (esim. Intranet); joskus käytetään myös esim. syötteiden esitarkistukseen, mutta vaatisi miettimistä (...mutta esim. XForms) 69
è è è Web & tekstiformaatit 4.5 Avaruudesta aikaan Saavutettavuuden luonne hieman muuttuu kun tarkastellaan ajassa muuttuvia esityksiä -...ts. kun "poistutaan kuolleen tekstin maailmasta" vrt. SVG-esimerkki "reversi"... Yleisessä tapauksessa käyttöliittymä voi koostua erilaisista mediaelementeistä jotka ovat aikariippuvaisia Saavutettavuus tarkoittaa tällöin - vaihtoehtoisia tiedon esitystapoja (vrt. tv-ohjelman tai elokuvan tekstitys huonokuuloiselle suomenkieliselle henkilölle vs. tekstitys kuurolle suomenkieliselle henkilölle) ja - mahdollisuutta "pysäyttää aika" (esim. näkövammainen henkilö tai henkilö joka on hidas lukemaan tai haluaa pysäyttää esityksen esim. taustatietojen haun ajaksi) 70
è è è Web & tekstiformaatit 4.6 Synkronoitu multimedia ja SMIL Standardin synkronoidun multimedian koostamiseen määrittelee esim. SMIL (Synchronized Multimedia Integration Language) Edellyttää yleensä erillistä soitto-ohjelmaa (esim. RealPlayer) Myös SMIL sisältää saavutettavuuspiirteitä - vaihtoehtoinen sisältö, hakemistot,... Kuva: CSC -...mutta käytännössä soittoohjelman (käyttöliittymän) saavutettavuus sinänsä voi muodostua esteeksi 71
è è è Web & tekstiformaatit 4.7 SMIL-dokumentin rakenne <?xml version="1.0"?> <!DOCTYPE smil PUBLIC "-//W3C//DTD SMIL 2.0//EN" "http://www.w3.org/2001/smil20/smil20.dtd"> <smil xmlns="http://www.w3.org/2001/smil20/language" xml:lang="en" title="picture-in-picture Television"> <head> <layout> <toplayout width="320px" height="240px"> <region id="main-video" left="0%" top="0%" width="100%" height="100%"> <region id="corner-video" left="67%" top="67%" width="33%" height="33%" fit="scale" soundlevel="0%"/> </region> </toplayout> </layout> </head> <body> <par> <video id="chameleon-video" src="chameleon.mpg" alt="an animated chameleon" region="main-video"/> <video id="earthquake-video" src="earthquake.mpg" alt="san Fransisco earthquake aftermath" region="corner-video" end="chameleon-video.end"/> </par> </body></smil> Kuva ja esimerkki: C. Forno 72
è è è Web & tekstiformaatit 4.8 Lopuksi: tekniset menetelmät ja saavutettavuustyö Käyttäjien, käyttötapojen ja käyttökelpoisten sovellusten tuntemus on saavutettavuustyön perusta, mutta...... se ei vielä yksin riitä: tarvitaan suunnitteluosaamista koska - kyse on myös esim. verkkosovellusten menetelmien tuntemisesta teknisellä tasolla (esim. monikanavajulkaisu) ja esim. XMLtekstiformaattien teknisten saav.ominaisuuksien osaamisesta (esim. SVGdokumentin suunnittelu tekstivastineiden näkökulmasta)...muuten käy niin että juututaan puhumaan saavutettavuudesta yläkäsitteiden tasolla, tavalla, jolla ei ole merkittäviä vaikutuksia (verkko)sovelluksen loppukäyttäjän näkökulmasta -...eikä osata esim. arvioida tuotantotyön todellisia kustannuksia Standardoitujen XML-tekstiformaattien ja esim. näiden selaintoteutusten asteittainen kehittyminen (eri tahdissa) asettavat erittäin suuria haasteita käytännön saavutettavuustyölle 73
è è è Web & tekstiformaatit 4.9 Rajaus (tenttilukijoille tiedoksi) Keskeistä on nyt ymmärtää verkkosovellusten teknisen perustan ja tuotantotyön, sekä saavutettavuusohjeistuksen välinen suhde (muuten saav. jää yläkäsitteiden tasolla ohueksi) Itse saavutettavuusohjeet eivät kuitenkaan juuri opeta menetelmätason osaamista (koska ne on rajattu lopputuloksen arviointiin) - vrt. XHTML-perhe vs. HTML-perusteet ("kotisivun osaavat kaikki tehdä") Tentissä ei oleteta/vaadita seuraavien tekniikoiden yksityiskohtaista hallintaa - PHP, XML/XSL/XSLT, XForms, SVG, SMIL, tiedon formaali mallinnus...mutta koko homman idea ja riippuvuudet olisi syytä ymmärtää Asioita opetetaan tarkemmin osana esim. opintojaksoja HM ohjelmointi, Rakenteiset dokumentit ja Rakenteisten dokumenttien jatkokurssi 74
5 Pari sanaa palvelutuotannosta Tarkastelu yksittäisten verkkosivujen tasalla ei luo realistista kuvaa informaation saavutettavuuden haasteista. Tarkastellaan seuraavaksi palvelutuotannon lähtökohtia pelkistettyjen esimerkkien valossa. 75
5.1 Välisoitto (Verkkopalvelun) tuotanto kiteytyy viime kädessä lukuisten yksityiskohtien hoitamiseksi (joista eräs on WWW-sivujen tuottaminen) Pienen sovelluksen voi toteuttaa "lähes miten vain" Realistisen kokoisten sovellusten tuottamisessa keskeistä on työpanoksen kohdistamisen oikein (lue: turhaa käsityötä tulee välttää) 76
5.2 Pieni sovellusesimerkki: Opettajan käyntikortti Halutaan esittää seuraavat tiedot "verkossa":? Opettajan käyntikortti: Ossi Nykänen Tampereen teknillinen yliopisto, Matematiikan laitos, Hypermedialaboratorio Sähköposti: ossi.nykanen@tut.fi Huone: TD303 Opetusala: Hypermedia Opintojaksot: saavutettavuus, rakenteiset dokumentit, rakenteisten dokumenttien jatkokurssi,... Miten käytännössä? (Entäpä jos muille opettajille tehtäisiin vastaavat?) 77
5.3 Toteutusvaihtoehtoja 1. Staattinen palvelu käsityönä: kirjoitetaan sivut esim. käsin tekstieditorilla (tai sivupohjaisesti Web-editorilla) 2. Dynaaminen palvelu template-tekniikalla: sovellus tuotetaan dynaamisesti skriptikielen avulla (esim. PHP+MySQL) 3. Verkkopalvelu julkaisuprosessin tuloksena: sovelluksen tietosisältö ylläpidetään esim. rakenteisina dokumentteina joista sisältö prosessoidaan/tulostetaan eri medioihin sopivaan muotoon (esim. XML+XSLT) Käytännössä verkkosovellusten toteutus yhdistelee yleensä kaikkia em. vaihtoehtoja (ja käsityötä tarvitaan ainakin palvelun suunnittelun, ohjelmoinnin, mediaobjektien käsittelyn ja teknisen kirjoittamisen puitteissa) Palvelut voivat sisältää myös mm. loogisia sääntöjä 78
5.4 Toteutustapa #1: Staattinen sivu käsityönä Suoraviivaisin tapa on kirjoittaa sovellus käsin tai sopivalla WWW-editorilla sivu sivulta (edistynyt tuotantoympäristö voi myös sisältää mallipohjia tms.) Perusidea: Tuotetaan (X)HTML-koodia esim. tekstieditorilla Kysymyksiä: - Kuinka paljon sisältöä on, onnistuuko tuotanto ja ylläpito käsin? - Osataanko kaikki suunnitella ennen käyttökokeita? (Saavutettavuus?) Hyviä ja huonoja puolia: - Nopeasti alkuun mutta sovellus heikosti hallittavissa volyymin kasvaessa - Kaikki sovelluksen piirteet periaatteessa täysin räätälöitävissä, mutta esim. resurssisyistä johtuen, sovellus rämettyy helposti (esim. päivitykset ja versiointi, korjaukset, systemaattiset muutokset) - Tiedon esitystapa pitää käytännössä suunnitella täysin valmiiksi ennen toteutusta, täysin staattinen toteutus 79
5.5 Ettei totuus unohtuisi: verkkosivuista verkkopalveluun Verkkopalvelun toteuttamisessa on poikkeuksetta kaksi näkökulmaa: - sovellus toimii loppukäyttäjän näkökulmasta ( saavutettavuus ja käyttökelpoisuus) - toteutus- ja ylläpitokustannukset ovat järkeviä ( tuotantotyön menetelmät) Käytännössä verkkopalvelu on myös aina osa suurempaa kokonaisuutta, mistä seuraa omia reunaehtojaan (erit. tekn. tuotannon ja ylläpidon skaalautuvuus ja palvelutuotanto sisällön osalta) Toiminta verkossa Verkkopalvelu Verkkopalvelun tuottaminen Toiminta verkon takana (lue: sisältö) Taustaorganisaation palvelu Taustaorganisaation palvelutuotanto 80
5.6 Palvelutuotanto (RUP-jäsennys) ja saavutettavuus Development process (recursive step) Inception - rationale - scope - success criteria Elaboration - requirements - analysis & design - baseline architecture - construction plan Construction 1 2 3... Transition - testing, tuning, training "Kaikkien muutostöiden hinta" nousee tuotantoprojektin edetessä Jos haluamme optimoida resurssien käytön ja maksimoida lopputuloksen: - saavutettavuus (WAI-ohjeet) tulee selkeästi ottaa jo määrittelyssä huomioon yhtenä tavoitteena muiden mukana (myös ylläpidon osalta) - suunnittelussa on huomioitava sekä WAI-ohjeet että WAI-tekniikat (reunaehdot ja rajoitteet) - perustaso ja testaamisen mittarit selvitetään jo aluksi 81
5.7 Verkkopalvelun tyypillinen suunnittelu Harva palvelu koostuu yhdestä sivusta. Verkkopalvelu jäsennetään usein (käyttäjälle tarjotulta näkymältään) puumaiseksi rakenteeksi osioittain tai toiminnoittain (ylläpidon ja ymmärrettävyyden takia). Tulos: - palvelulla on tietty yleisjäsennys ja esim. hakutoiminto ( "navigointi") - asiasisältö (esim. aihealueittain) välittyy sivupohjien osoittaman jäsennyksen keinoin ( "viestiminen") - palvelu sisältää dynaamisia osia: palvelun jäsennys, esitystapa, sisältö tai toiminnallisuus saattaa vaihdella tai muuttua ( "vuorovaikutus") Uutiset Ohjelmoitava palvelualusta <?...?> Etusivu Artikkelit Uutiset Artikkelit Ryhmätyö... Ryhmätyö <?...?> <?...?> <?...?> 82
5.8 Tuotantotyön laskuoppia (mihin resurssit menevät?) Miksi palvelutuotannon mekaaninen hallittavuus on tärkeää? Triviaali esimerkki: palveluorganisaation yksinkertainen verkkopalvelu jossa työntekijöiden käyntikortit, tehtäväkuvaukset ja organisaation yleisinfo - N työntekijää, M tehtävää, kukin hoitaa T tehtävää, yleisinfossa etusivu, ohje, tehtäväkuvaukset ja sivukartta (sisällysluettelo), ts. 3 perussivua Peruskoulun laskuoppia, arvioidaan alarajoja (esim. N=5, M=15, T=4): - palvelussa on N+M+3 sivua tms. (23) - kunkin työntekijän sivulla on 1+T linkkiä (4), tehtävissä 1+N*T/M linkkiä (~2.3) ja sivukartassa N+M+2 linkkiä (22) - palvelussa on N*(1+T) + M*(1+N*T/M) + (N+M+2) linkkiä (127) - laskuissa ei ole mukana murupolkuja, hakutoimintoa, jne. (!) Tuotannon resursointi (versiointi ja muutokset?), ylläpito (sisällön eheys ja virheettömyys?),...mihin aikaa jää? Jääkö saavutettavuustyölle? 83
5.9 Huomioita saavutettavuustyöstä Matkaketjun hengessä, saavutettavuuden tulisi tietenkin toteutua koko palvelun osalta; - "saavutettava verkkopalvelu" voi hyvin hyödytön ellei palvelun varsinainen sisältö ole saavutettavissa (riippuvuudet vrt. esim. transaktion vahvistaminen paperikirjeellä johon allekirjoitus rapussa B2) Teknisen suunnittelun rakenteita kannattaa tietenkin hyödyntää saavutettavuustyössä: - verkkopalvelun arviointia ja kehittämistä kannattaa järkeistää arvioimalla saavutettavuutta sovelluksen verkkosivujen ja sivupohjien perusteella - (kognitiivinen) saavutettavuusarviointi kannattaa jakaa osiin myös esim. yleisrakenteen ja aihealueittaisen sisällön kesken, jne. Palvelutuotannon hyvä hallittavuus ("ohjelmoitavuus") mahdollistaa palvelun saavutettavuuden systemaattisen ja taloudellisen kehittämisen (profilointi?) 84
5.10 Toteutustapa #2: Dynaaminen sivu template-tekniikalla Sovelluksen "ohjelmoitavuus" paranee esim. mallipohjien käytöllä Tietomalli Lähdedokumentit Perusidea: sovellus tuotetaan dynaamisesti skriptikielen avulla (esim. PHP) Kysymyksiä: - Minne sivuilla näytettävä tieto talletetaan? (Tietokantaan) - Tarvitaanko dynaamisuutta? Riittääkö palvelimen teho? Mitä lisäarvoa ohjelmakoodilla haetaan? (Keksitäänkö pyörä uudelleen?) Hyviä ja huonoja puolia: - Nopeasti alkuun, lisäarvot suunnittelun myötä, volyymin kasvaessa työn painopiste siirtyy palvelun abstrahointiin ja esim. tietokantaohjelmointiin - Sovelluksen piirteet räätälöitävissä, myös vuorovaikutteisuus (yleisessä tapauksessa sivupohja-ajattelu on vain esim. ohjelmistonäkymä [view]) 85
5.11 Tuotannon näkökulma: (X)HTML on julkaisuformaatti Vaikka HTML-dokumentteja voi kirjoittaa suoraan tekstieditorilla, laajemmat sivustot tuotetaan hallittuun sisällöntuotantoprosessiin nojautuen: - sisältö kuvataan mediariippumattomasti sopivalla XMLsanastolla (+mediaobjektit) - kutakin julkaisumediaa (esim. HTML) kohti kirjoitetaan formatointiohje(lma tai tyyli) - käsikirjoitus formatoidaan kunkin median mukaisesti julkaisuprosessin yhteydessä ( monikanavajulkaisu) - jälkikäsittelyä pyritään välttämään, ylläpito, versiointi jne. hoidetaan keskitetysti 86
5.12 Monikanavajulkaisun perusidea Keskitetty ja hallittu sisällöntuotanto ja ylläpito, mekaaninen julkaisu Voi sisältää myös interaktiivisia osia yms. (Multi-Channel Publishing, Single Sourcing,..) XHTML käsikirjoitus Mediaobjektit SMIL XML 1.0 SVG PNG...... XLink XQuery XSL/FO XSLT XSLT CSS PDF CSS Sovellus #1 Sovellus #2 Sovellus #3 87
5.13 Toteutustapa #3: Sivu julkaisuprosessin tuloksena Suunnitelmallisempi lähestymistapa on mallintaa sovelluksen tiedot ja tietojen julkaisuprosessi Tietomalli Lähdedokumentit formatointi Tulosdokumentit Idea: Mallinnetaan data ja määritellään datan esitystavat Kysymyksiä: - Miten käsikirjoituksen (lähdedokumentin) tai tietokannan tiedot valitaan? - Onko sovellus tarpeeksi laaja jotta systemaattisen lähestymistavan edut realisoituvat? Hyviä ja huonoja puolia: - Työ alkaa selkeällä suunnitteluvaiheella, sovelluksen piirteet keskitetysti hallittavissa, mutta vuorovaikutteisuuden toteuttaminen edellyttää yhä esim. mallipohjatekniikoita, "ei räätälöintiä, geneerinen ratkaisu" 88
5.14 Saavutettavuusohjeistus vs. tekniikan mahdollisuudet Verkkopalvelun toteuttamisen menetelmät asettavat esim. verkkosisällön saavutettavuusohjeistuksen oikeaan perspektiiviin: - periaatteelliset mahdollisuudet (menetelmät, tekniikat, laitteet) - käytännölliset rajoitukset (tuotannon optimointi, mainstreaming, inhorealismi esim. sisällön ja ylläpidon rämettymisen suhteen, jne.) Normatiivinen verkkosisällön saavutettavuusohjeistus on pitkälti kirjoitettu "toteutustavan #1 hengessä" -...koska standardoinnin näkökulmasta rajaus on perusteltu -...mutta toteuttajan (ja arvioijan) pitää ottaa kantaa prosesseihin (ts. WAI-mittaristoa tarvitaan mutta se ei vielä yksin riitä) 89
5.15 "Tuotantoesimerkkien" rakenne ja viittaukset (1/2) Tietomalli ja tiedon esitystapa Käsityön määrä ja laatu Palvelinpään vaatimukset Saavutettavuusohjeistuksen ala! Välineet ja kirjoittajien ohjeistus #1: Käsityö ope-kkortti.html ope-kkortti.css #2: Template-tekniikka ope-kkortti.css ope-kkortti-tiedot.txt ope-kkortti.php ope-kkortti_phpfunc.php 90
5.16 "Tuotantoesimerkkien" rakenne ja viittaukset (2/2) #3: (Monikanavainen) julkaisuprosessi ja julkaisuputket (nyt kaikki Web-sivuja) ope-kkortti.css ope-kkortti-tiedot.xml teacher-single-html.xsl out.html teacher-all-html.xsl out2.html teacher-table-html.xsl out3.html teacher-single-php.xsl out4.php ope-kkortti_phpfunc.php... 91