è è è Verkkosaavutettavuuden tekniset perusteet 3 Verkkosaavutettavuuden tekniset perusteet Saavutettavuuden toteuttaminen edellyttää lähtökohtaisesti tietoa laitteista ja sovelluksista, käyttäjistä ja käyttötavoista, sekä tekniikasta. Tavoitteenamme on nyt paitsi luoda yleiskuvaus perustekniikoihin, myös pohjustaa konkreettisten saavutettavuusohjeiden tulkintaa. Web-arkkitehtuuri ja sen standardointi Sisällön kuvauskielten tekniikkaa ja ideoita (X)HTML ja CSS Huom. Käytännössä oletamme Web-tekniikan perusteet pitkälti tunnetuiksi; esim. XHTML/CSS-tekniikkaa ei yksityiskohtaisesti esitellä luennoilla 44
è è è Verkkosaavutettavuuden tekniset perusteet 3.1 Välisoitto Tekniikka on todellinen hengen voitto aineesta, mutta joskus tekniikka näyttää silti saavan ihmisistä yliotteen Teknologian tarjoamien mahdollisuuksien ja sisältämien rajoitteiden osaaminen on perusedellytys toimivan suunnittelun perustana Motto: on helppo kritisoida, hankalampaa on "tehdä oikein" 45
è è è Verkkosaavutettavuuden tekniset perusteet 3.2 Osatavoite, WCAG 1.0 pähkinänkuoressa (1/2) Verkkosisällön saavutettavuusohjeen (Web Content Accessibility Guidelines 1.0, WCAG 1.0 ) sisältö lyhykäisyydessään: 1. Tarjoa samansisältöinen vaihtoehto ääni- ja kuvaperustaiselle tiedolle. 2. Älä luota yksin värien käyttöön. 3. Käytä merkkaus- ja tyylikieliä ja käytä niitä oikein. 4. Koodaa tekstin luonnollinen kieli selvästi (dokumentin tekniseen otsikkoon). 5. Käytä taulukoita siten että ne voidaan esittää eri tavoin ja eri välineillä. 6. Varmista että uusia teknologioita hyödyntävät sivut toimivat hyvin myös vanhemmilla asiakasohjelmilla....jatkuu 46
è è è Verkkosaavutettavuuden tekniset perusteet 3.3 WCAG 1.0 pähkinänkuoressa (2/2) 7. Varmista että käyttäjä voi hallita sovelluksen aikariippuvia osia. 8. Varmista sulautettujen tai upotettujen käyttöliittymäosien suora saavutettavuus. 9. Suunnittele laiteriippumattomasti. 10. Käytä ratkaisuja jotka toimivat myös tällä hetkellä (käytä tarvittaessa väliaikaisia ratkaisuja) 11. Käytä W3C-teknologioita ja ohjeita. 12. Pidä käyttäjä jatkuvasti selvillä asiayhteydestä ja sijainnista sovelluksessa. 13. Tarjoa selkeä navigointimekanismi. 14. Varmista että dokumentit ovat selkeitä ja yksinkertaisia. Ilmeisestikin ohjeen toteuttaminen edellyttää (myös) teknistä osaamista 47
è è è Verkkosaavutettavuuden tekniset perusteet 3.4 Tekniikka, ohjeet ja standardointi, peruskysymyksiä Tietotekniikasta kirjoitetaan "teknisiä määrityksiä", saavutettavuutta "ohjeistetaan" miksi? Koska... - toimiva tietotekninen standardi jättää paljon liikkumavaraa sen soveltamiseen - esim. asiakirjan sisällön liian tiukka standardointi koetaan yleensä luovuutta rajoittavaksi tekijäksi Miksi standardeista kannattaa puhua? Koska... - standardiin tukeutuminen tuo olemassa olevia sovelluksia ja välineitä - standardointi tarjoaa (liike)taloudellisesti järkevän tavan kehittää sovelluksia (erityisesti PK-yritysten näkökulmasta!) 48
è è è Verkkosaavutettavuuden tekniset perusteet 3.5 World Wide Webin (WWW) tekninen yhteensopivuus Perusidea: Web nimeää ja välittää resursseja joiden esitystapa (voi siis olla useita) voidaan tarvittaessa valitaan päätelaitteen tms. mukaan - nimi (verkko-osoite), resurssi (entiteetti, "thing"), esitystapa Yhtenäinen nimeämiskäytäntö URI ja tiedonsiirtoprotokollat (HTTP) asettavat yhteensopivan Webin teknisen perustan - Uniform Resource Identifier - Hypertext Transport Protocol "Arkikielessä" resurssi ja sen esitystapa usein samaistetaan (mutta oikeasti ei 1:1-suhdetta!) Kuva: W3C/TAG 2004 49
è è è Verkkosaavutettavuuden tekniset perusteet 3.6 Tiedon esitystavan yhteensopivuus Web välittää dokumentteja jotka voivat koostua useasta tiedostosta - (tarkemmin: Web välittää yksittäisiä tiedostoja, yhteen loogisesti kuuluvia tiedostoja ja/tai entiteettejä, "XML-fragmentteja") Sisällön näkökulmasta keskeistä on tiedon käyttötapauksista (prosesseista) sopiminen; tekniikan näkökulmasta erilaisista tietorakenteista sopiminen Koska tekninen standardointi tähtää mahdollisimman laajaan sovellettavuuteen, pitää esim. sovellusten saavutettavuus käytännössä ohjeistaa erikseen Webin Perusinfrastruktuuri on käsitteellisesti erittäin yksinkertainen - dokumenttien koostaminen, yhteyden tilan käsite, tietoturva, versiointi, yms. hoidetaan sovellusten tasolla 50
è è è Verkkosaavutettavuuden tekniset perusteet 3.7 Standardoinnin tasot, luonnehdinta Toimiva Web-standardointi koostuu eritasoisesta työstä Saavutettavan suunnittelun todellinen haaste on kokonaisuuden (ei yksittäisen tekniikan) monimutkaisuus Erityisen pulman muodostavat käytännöt: toteutuksen tekniseen suunnitteluun saatetaan (kukaties ajattelematta) uhrata enemmän resursseja kuin esim. prosessien saavutettavuuden suunnitteluun 51
è è è Verkkosaavutettavuuden tekniset perusteet 3.8 Webin standardipinon yleisrakenne Sovellusten sanastot yms. Rakdoktekniikka yms. Tiedonsiirto 52
è è è Verkkosaavutettavuuden tekniset perusteet 3.9 Pari sanaa XML:n ideoista Webin merkkauskielten melko yhtenäinen tekninen perusta helpottaa - eri sovellusten teknistä ja semanttista yhdistämistä, - Web-sovellusten opiskelua sekä - välineiden ohjelmointia (siirrettävyys). Sisällöllisesti keskeinen standardoinnin muoto ovat eri sovelluksiin tarkoitetut merkkauskielet Extensible Markup Language eli XML tarjoaa perustan eri sovelluksiin kehitettävien merkkauskielten tekniikalle - yhtenäinen merkistö ja merkkauskielioppi (<e a="v"><!-- elem. --></e>) - sovelluskohtaiset XML-tekstiformaatit ja yleiskäyttöiset välineet 53
è è è Verkkosaavutettavuuden tekniset perusteet 3.10 Esimerkki: XHTML-dokumentti XHTML-dokumentti on XML-dokumentti joka rakenteellisesti noudattaa tiettyä dokumentin tyyppimääritystä (DTD) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>virtual Library</title> </head> <body> <p>check <a href="http://example.org/">example.org</a>.</p> </body> </html> <!-- Mod. --> XML "näkyy läpi" XHTML-sanaston pohjalla: fyysinen ja looginen rakenne (tiedosto ja elementit), kommentit yms., nimiavaruuden käsite, jne. XHTML-dokumentin kirjoittajan ei tarvitse tietää "kaikkea" XML:stä (koska XML DTD ohjaa teknistä yhteensopivuutta) 54
è è è Verkkosaavutettavuuden tekniset perusteet 3.11 Hypertext Markup Language, HTML HTML on tarkoitettu verkkosivujen sisällön kuvailemiseen, tehtävä on: - sisällön loogisen rakenteen kuvailu (ulkoasu on sovelluksen heiniä) Useita suosituksia (ks. http://www.w3.org/markup/): - vanhat HTML-versiot (2.0, 3.2) ja HTML 4.01 - XHTML-perhe - XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) (Kolme versiota: Strict - Transitional - Frameset) - Modularization of XHTML - XHTML 1.1 - Module-based XHTML - XHTML Basic - Suositus "XHTML 2.0" kehitteillä Huom! (X)HTML on vain julkaisuformaatti ja hyvin rajoittunut sellainen 55
è è è Verkkosaavutettavuuden tekniset perusteet 3.12 Standardit, käytännöt ja perustason määrittely Standardi ei (yleensä) ole laki Historiallisesti esim. Web-standardien ja selainten (tms. prosessorien) kehitystyö on osoittanut että standardien käyttöönotto vaihtelee suuresti - "ellei laki pakota, markkinat ohjaavat" Standardien asettajat (ja työtä seuraavat sidosryhmät) saattavat projisoida standardeihin myös toiveita tai (yltiö)optimistisia odotuksia... Käytännössä tämä tarkoittaa esim. sitä että - kaikkia HTML & CSS -piirteitä ei toteuta yksikään selain -...kaikkia saavutettavuusohjeiden piirteitä ei yksinkertaisesti voi toteuttaa Saavutettavan palvelun tekninen toteutus on ilmeisesti sitä helpompaa mitä tarkemmin perustasosta (baseline) voidaan sopia 56
è è è Verkkosaavutettavuuden tekniset perusteet 3.13 XHTML Basic, se pieni & järkevä XHTML-sanasto XHTML Basic määrittelee HTML:n kuvailevan ytimen Rajaus ja moduulijako on hyödyllinen, vaikkei kirjoittaisi varsinaisesti XHTML Basic - dokumentteja Jatkossa XHTML kehittynee entistä selvemmin juuri moduulien suuntaan - yhdisteltävyys ja profilointi - XML-tekniikoiden hyödyntäminen 57
è è è Verkkosaavutettavuuden tekniset perusteet 3.14 Tärkeää: dokumenttien ja tiedon korrekti rakenne Koska tietokoneet eivät ymmärrä sisältöjä, niiden käsittelemien tietorakenteiden tulee olla rakenteeltaan täsmälleen määriteltyjä (X)HTML-dokumentin validoimisella tarkoitetaan testiä jossa valitun dokumentin rakenteen oikeellisuus selvitetään vertaamalla sitä (X)HTMLdokumentin tyyppimäärittelyyn ("malli tai muotti") Huom #1. Validius ei takaa että - dokumentti olisi sisällöllisesti mielekäs, tai että - dokumentti olisi saavutettava...koska dokumenttien rakenteella ja esim. tekstisisällöllä (merkkidata) on validiuden puitteissa varsin runsaasti liikkumavaraa (esim. kieli) Dokumentin tietojen järkevyys on siis tarkistettava muuten - Huom. #2 validointi on abstrakti XML-prosessi sopiva sovellusta ymmärtävä apuohjelma voi kuitenkin tukea myös sisällön tarkastamista 58
è è è Verkkosaavutettavuuden tekniset perusteet 3.15 HTML-dokumentin ulkoasu? Rakenteisen dokumentin perusidea: - HTML-dokumentin rakenne kuvailee dokumentin tietosisällön -...jonka ulkoasun ja toiminnallisuuden (tai esitystavan!) sovellus päättää (esim. selain) Esim. XHTML: - tiedon esitysrakenne: otsikot ja kappaleet - toiminnallisuus: linkit ja lomakkeet - yhteydet muihin dokumentteihin: kuvat, objektit, yms. (HTML ~ Webin liimakieli) Muista puhesyntetisaattoriesimerkki! 59
è è è Verkkosaavutettavuuden tekniset perusteet 3.16 Esimerkki: XHTML & CSS XHTML-dokumentin esitystapa voidaan ohjeistaa esim. CSS-tyyliohjeen avulla (Cascading Style Sheet): body { background: yellow; /* Pohja */ font-family: "Arial", sans-serif; color: rgb(0,0,50); } p { text-align:right; } p a { background: white; font-size: 150%; } a:active { background: black; color: white; } <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>virtual Library</title> <link rel="stylesheet" type="text/css" href="pc-yell.css"/></head> <body> <p>check <a href="http://example.org/">example.org</a>.</p> </body> </html> <!-- Mod. --> 60
è è è Verkkosaavutettavuuden tekniset perusteet 3.17 HTML-dokumentin ulkoasu ja tyylit, huomioita HTML-dokumentin esitystapa voidaan siis ohjeistaa esim. ns. tyylin (stylesheet) avulla CSS-tyyli voidaan päällekirjoittaa sovelluksessa, ts. esim. selain voi päättää tulkitako CSS-tyyliä vai ei (ja miltä osin) Tyyli kertoo miten rakenteinen dokumentti esitetään valitussa mediassa - tyyliohje määrittelee formatointiobjektit sekä näiden attribuutit (abstrakti käsite!) - yleisessä tapauksessa tyyliohje on tietokoneohjelma joka voi tehdä rakenteisella dokumentilla "mitä tahansa" Myös CSS-tieto pitää validoida 61
è è è Verkkosaavutettavuuden tekniset perusteet 3.18 Cascading Style Sheets, ja esitystavan idea CSS jäsentää rakenteisen dokumentin tarjoten formatointimallin (tai malleja) johon sisältöä formatoidaan Visuaalinen formatointimalli: Viewport, block (display), property Yleisemmin, CSS-formatointiominaisuudet jaotellaan mediatyypeittäin: - all, aural, braille, embossed, handheld, print, projection, screen, tty, tv ( mediavalitsimien käyttö) CSS määrittelee seuraava mediaryhmät: - continuous tai paged; visual, aural tai tactile; grid tai bitmap; interactive tai static; all 62
è è è Verkkosaavutettavuuden tekniset perusteet 3.19 CSS, taulukot ja tuotettu sisältö CSS osaa (periaatteessa) jäsentää rakenteisen dokumentin myös taulukkona (a la HTML 4) Vastaavasti elementtien formatoinnin yhteydessä tulosdokumenttiin voidaan liittää myös esim. numerointitietoja ja vakiotekstiä Em. ominaisuuksien hyödyntäminen on kuitenkin sovelluksissa pulmallista, johtuen esim. selaintoteutusten vajavaisuuksista Vastaavasti ääniselainominaisuuksia yms. ei toistaiseksi ole yleisesti toteutettu (kehitystyötä: Voice Browser) CSS-suosituksen kehityskaari: CSS 1.0, 2...2.1, 3 ( moduulit) 63
è è è Verkkosaavutettavuuden tekniset perusteet 3.20 Standardit tyylikielet, tyylikieli ja tieto Tyyliohjeita silmälläpitäen on kehitetty omia standardejaan: esim. XHTMLdokumentti voidaan esittää useilla eri tekniikoilla: - esim. CSS (Visual, Aural, Paged Media, Print, TV,...), XSL (XSLT, XSL-FO), mallikielet,... Käytännössä tyyliohje voi myös sisältää osan dokumentin välittämästä informaatiosta - esim. XSL-tyyli voi olla funktionaalinen kuvaus: T:XHTML XHTML - esim. rakenne-elementtien asemointi, vakiotekstit, sivun ylläpitäjän tiedot, päivämäärä, kappaleiden numerointi, jne. - käytännössä esim. verkkopalvelun navigoinnin käyttöliittymä (linkit ja nappulat) tuotetaan tyypillisesti tyyliohjeen tai mallipohjan (template) avulla (yleensä "dynaamisesti", ylläpidollisista syistä) 64
è è è 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
è è è Pari sanaa palvelutuotannosta 5 Pari sanaa palvelutuotannosta Palvelun tarkastelu "yksittäisten verkkosivujen tai tekniikoiden tasalla" ei luo kovin realistista kuvaa informaation saavutettavuuden haasteista. Tarkastellaan seuraavaksi palvelutuotannon lähtökohtia pelkistettyjen esimerkkien valossa. 75
è è è Pari sanaa palvelutuotannosta 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
è è è Pari sanaa palvelutuotannosta 5.2 Verkkopalvelun toteutuksesta (vrt. "Salivaraani") Tyypillinen verkkopalvelu perustaa palvelunsa johonkin perusjärjestelmään (ei merkitty ao. kuvaan) ja tarjoaa palveluun näkymän sopivan asiakasohjelman ymmärtämässä muodossa Esim. XHTML+CSS -tekniikka toimii siten lähinnä rajapintana selaimelle 77
è è è Pari sanaa palvelutuotannosta 5.3 Verkkopalvelun toteutusstrategioita 1. Staattinen palvelu käsityönä: kirjoitetaan "sivut" esim. käsin tekstieditorilla (tai sivupohjaisesti Web-editorilla) ja julkaistaan suoraan httpdokumenttihakemistossa 2. Dynaaminen palvelu template-tekniikalla: sovellus tuotetaan dynaamisesti skripti/template-kielen avulla (esim. PHP+MySQL) 3. Vapaasti ohjelmoitu sovellus: suunnitellaan sovellus ohjelmointikielellä X ja hyödynnetään jotakin sopivaa Web-sovelluskehystä (esim. Java+JavaServer Faces, Python+Django, ) 4. Sovellus julkaisuprosessin tuloksena: kuten edellä, mutta sovellusta (tai sen osaa; käyttöliittymää, dokumentaatiota, "lähdekoodia", ) ylläpidetään esim. rakenteisina dokumentteina joista sisältö prosessoidaan julkaisun yhteydessä sopivaan muotoon (esim. XML+XSLT HTML+PHP) Käytännössä sovelluksissa yo. toteutusstrategioita yhdistellään eri tavoin 78
è è è Pari sanaa palvelutuotannosta 5.4 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ä ( palvelutuotannon menetelmät) Verkkopalvelu on aina osa suurempaa kokonaisuutta, mistä seuraa omia reunaehtojaan (erit. tekn. tuotannon ja taustaprosessien/ylläpidon skaalautuvuus palvelutuotannon osalta) Toiminta verkossa Verkkopalvelu Verkkopalvelun tuottaminen Toiminta verkon takana (lue: sisältö) Taustaorganisaation palvelu Taustaorganisaation palvelutuotanto 79
è è è Pari sanaa palvelutuotannosta 5.5 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) - perustason kysymykset ja testaamisen mittarit selvitetään jo aluksi (!) 80
è è è Pari sanaa palvelutuotannosta 5.6 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ö <?...?> <?...?> <?...?> 81
è è è Pari sanaa palvelutuotannosta 5.7 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? 82
è è è Pari sanaa palvelutuotannosta 5.8 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?) 83
è è è Pari sanaa palvelutuotannosta 5.9 Ai niin -- 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 84
è è è Pari sanaa palvelutuotannosta 5.10 Toteutustapa #2: Dynaaminen sivu template-tekniikalla Sovelluksen "ohjelmoitavuus" paranee esim. mallipohjien käytöllä 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]) - Raja toteutustapojen 2 ja 3 välillä hämärtynyt vuosien varrella "koska Template-kielet lähentyvät jatkuvasti oikeaa ohjelmointia ja päinvastoin" 85
è è è Pari sanaa palvelutuotannosta 5.11 Toteutustapa #3: Vapaasti ohjelmoitu sovellus Sovelluksen toteutusta rajaa vain sovelluskehyksen valinta (mutta ohjelmointikieli ja kehitysvälineet ovat yleensä "parhaat mahdolliset") Perusidea: sovellus tuotetaan "yleisen" ohjelmointikielen avulla Kysymyksiä: - Mikä kehys valitaan? Mitä palvelimelle pitää asentaa tätä varten "lisää"? - Millä välineellä sovellusta/ohjelmistoprosessia viedään läpi? Hyviä ja huonoja puolia: - Saman ohjelmointikielen/teknologian käyttö verkkopalvelun ja perusjärjestelmien (yms.) toteutuksessa yleensä helpottaa työtä ja välinevalintoja - Alkuun pääsy edellyttää usein "enemmän" selvittelyä, tuotantoprosessi (ja tuote) saattaa muodostua aiottua raskaammaksi/monimutkaisemmaksi - Kehyksen käyttöikä (esim. päivitykset) saattaa muodostua ongelmaksi 86
è è è Pari sanaa palvelutuotannosta 5.12 Toteutustapa #4: Sivu julkaisuprosessin tuloksena Erityisesti dokumentaation osalta hyvä lähestymistapa on ottaa sovellus haltuun julkaisuprosessin osalta (sopii rajoitetusti myös logiikan ylläpitoon) Idea: Mallinnetaan data, määritellään esitystavat ja ohjelmoidaan tarvittavat muunnokset Kysymyksiä: - Miten käsikirjoituksen (lähdedokumentin) tai tietokannan tiedot valitaan? - Onko sovellus tarpeeksi laaja jotta systemaattisen lähestymistavan edut realisoituvat? (Vrt. sopivan sovelluskehyksen valinnat.) 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" - "Esiprosessoinnin" hyvät ja huonot puolet ohjelmoinnissa 87
è è è Pari sanaa palvelutuotannosta 5.13 #4 ja analogia: hallittu sisällöntuotantoprosessi 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 88
è è è Pari sanaa palvelutuotannosta 5.14 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 89
è è è Pari sanaa palvelutuotannosta 5.15 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ä) 90
è è è Pari sanaa palvelutuotannosta 5.16 Lopuksi: lisää saavutettavuuden tekijöitä 91