8 Vuorovaikutus ja tieto

Transkriptio

1 8 Vuorovaikutus ja tieto Pyrkimys laiteriippumattomuuteen ja tiedon saatavuuteen ohjaa jäsentämään tietoteknisen maailmaa entistä enemmän abstrakteina rajapintoina. Tuloksena sovellusten palvelulogiikka pelkistyy entistä enemmän ja (ennen kaikkea) sovelluksia suunnitellaan lähtökohtaisesti sillä ajatuksella että palveluun on mahdollista päästä käsiksi eri tavoin....tuloksena pyrkimys kohti tiedon ja vuorovaikutuksen itsensä kuvaamista sen esitystavan kuvaamisen sijaan. Huom. käytännössä esim. multimodaalisuus on (kuluttajasovelluksissa) pitkälti vasta "tulossa" asteella (mutta ne ideat...) 177

2 8.1 Välisoitto Tie tuotantoprosessin haltuunotosta monikanavaisuuteen ei periaatteessa ole pitkä tai kovin kivinenkään Vastaavasti, ideatasolla hyppäys laiteriippumattomuudesta multimodaalisuuteen on selkeä Harmaita hiuksia saattaa aiheuttaa se kuinka pitkälle asiat halutaan käytännössä viedä 178

3 8.2 Monikanavaisuus ja vuorovaikutus Monikanavaisuus tarjoaa puitteet yhden ja saman palvelun eri käyttötavoille (palvelukokemus) Laiteriippumattomuus sinänsä ei kuitenkaan tarkoita "vain" esim. tekstisisällön esittämistä erilaisten näyttölaitteiden erot huomioiden...vaan ottaa kantaa myös vuorovaikutuksen tapoihin tai moodeihin (seurauksena muutoksia myös palvelun käytön logiikassa) Kuva: IBM 179

4 8.3 Multimodaalisuus ("moniaistisuus") Laiteriippumattoman (verkko)sovelluksen pullonkaulaksi muodostuvat useimmiten syöte- ja tulostusmekanismit (tai vastemekanismit) Käytännössä "laiteriippumattomuus" so. siirtyminen pois työasemien/pclaitteiden maailmasta johtaa tilanteeseen jossa - "näyttö" pienenee, "näppäimistö" pienenee tai katoaa kokonaan ja "hiiri" korvautuu toisella laitteella Yhtäläisen toiminnallisen käyttökokemuksen tavoittelu sallii (joskus edellyttää) tuen useille eri (rinnakkaisille?) syöte- ja vastetavoille eli moodeille Multimodaalinen sovellus tai käyttöliittymä pyrkii tarjoamaan välineitä erilaisille vuorovaikutustavoille (ns. interaction mode), esim. ed. lisäksi myös - puhe, katse, kosketus, kynä, elekieli, jne. 180

5 8.4 W3C Multimodal Interaction Framework Pyrkimys laiteriippumattomaan multimodaalisuuteen edellyttää vuorovaikutusmekanismien (syöte, input ja vaste, output) abstrahointia ja standardointia - vrt. rakenteisen dokumentin idea Kuva: W3C/MMI (tietorakenne vs. esitystapa) Pelkistetty jäsennys multimodaalisesta järjestelmästä sisältää seuraavat osat: - käyttäjä (user), syöte (input), vaste (output), vuorovaikutuksen ja session hallinta (interaction manager, session component) ja ympäristö (system & environment) 181

6 8.5 Multimodaalinen syöte (input) Multimodaalisen syötteen käsittely jaetaan kolmeen vaiheeseen: - tunnistus (recognition) - tulkinta (interpretation) - yhdistäminen (integration) Esim. - H: "Move that," (points to an object), "there," (points to a location) - C: "Are you sure?" - H: "Yep!" Kuva: W3C/MMI 182

7 8.6 Multimodaalinen vaste (output) Multimodaalisen vasteen käsittely jaetaan myös kolmeen vaiheeseen: - generointi (generation) - mukautus esitystavan perusteella (styling) - esittäminen (rendering) Esim. - palvelun esittäminen XHTML- tai VoiceXMLdokumentteina - vrt. monikanavainen palvelu(!) Kuva: W3C/MMI 183

8 8.7 Extensible MultiModal Annotation markup language EMMA on rajapintakieli esim. syötelaitteen ja verkkopalvelun kontrollerin välille (määritys on tätä kirjoittaessa vielä keskeneräinen). Esim.: <emma:emma version="1.0" xmlns:emma=" <emma:one-of id="r1" emma:start=" " emma:end=" "> <emma:interpretation id="int1" emma:confidence="0.75"> <origin>boston</origin> <destination>denver</destination> <date> </date> </emma:interpretation> <emma:interpretation id="int2" emma:confidence="0.68"> <origin>austin</origin> <destination>denver</destination> <date> </date> </emma:interpretation> </emma:one-of> </emma:emma> 184

9 8.8 EMMA, yhdiste-esimerkki ("komento ja kaksi klikkausta") <emma:emma version="1.0" xmlns:emma=" <emma:group id="grp" emma:start=" t0:00:00.15" emma:end=" t0:00:00.515"> <emma:interpretation> <action>move</action> <object>ambulance</object> <destination>here</destination> </emma:interpretation> <emma:interpretation> <x>0.253</x> <y>0.124</y> </emma:interpretation> <emma:interpretation> <x>0.866</x> <y>0.724</y> </emma:interpretation> </emma:group> </emma:emma> Esim. puhe- ja kahden osoitintiedon yhdistäminen. 185

10 8.9 Multimodaalisuus ja ääniselaimet Multimodaalisia sovelluksia odotetaan "yleisesti" löytyvän esim. seuraavista sovelluskentistä - mobiilijärjestelmät, auto- ja paikkatietojärjestelmät, toimistosovellukset (esim. sulautetut käyttöliittymät), kotisovellukset (esim. kaukosäätimet) Lyhyellä tähtäimellä multimodaalisuus toteutunee konkreettisimmillaan juuri kohdistin- ja puhekäyttöliittymien yhdistelmissä Ääniselaimella (Voice browser) tarkoitetaan (kärjistettynä) puhedialogin (Speech dialog) varaan rakentuvaa Web-selainta Käytännössä teknisiä osa-alueita on useita, esim.: - puheentunnistuksen tekniikka, syntetisoidun puheen tuottamisen tekniikka, "puhelin"tekniikka ja sisällöntuotannon kysymykset esim. syntetisoidun puheen äänneasuun liittyen 186

11 8.10 Voice Extensible Markup Language (VoiceXML) VoiceXML on käyttäjän puhekomentoja, syntetisoitua puhetta, äänileikkeitä ja efektejä yhdistelevän dialogin liimakieli "Tyypillinen" toteutusstrategia: - puhelinkäyttöliittymä verkkopalveluun - puheentunnistuksen ja VoiceXMLsovelluksen osuudet Web-kehittimen osana (esim. IBM WebSphere) Kuva: W3C/VBA - yhteys "tavalliseen" verkkopalveluun esim. Java/JSP -tekniikalla (vrt. XHTMLsivut ja PHP) Puhedialogi voi haarautua eri sivuille, vaihtaa aktiivista sanastoa sovelluksen eri osissa, soittaa tehosteita, ajaa taustalla muita sovelluksia, hyödyntää puhelimen nappuloita, ohjata käyttäjän tavalliseen puhelinpalveluun jne. 187

12 8.11 VoiceXML, lomake-esimerkki <vxml version="2.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" <form id="weather_info"> <block>welcome to the weather information service.</block> <field name="state"> <prompt>what state?</prompt> <grammar src="state.grxml" type="application/srgs+xml"/> <catch event="help"> Please speak the state for which you want the weather. </catch> </field> <field name="city"> <prompt>what city?</prompt> <grammar src="city.grxml" type="application/srgs+xml"/> <catch event="help"> Please speak the city for which you want the weather. </catch> </field> <block> <submit next="/servlet/weather" namelist="city state"/> </block> </form> </vxml> C (computer): Welcome to the weather information service. What state? H (human): Help C: Please speak the state for which you want the weather. H: Georgia C: What city? H: Tblisi C: I did not understand what you said. What city? H: Macon C: The conditions in Macon Georgia are sunny and clear at 11 AM

13 8.12 Ääniselainten sovellusalasta ja vaikeista ongelmista Sovellusten todellinen pullonkaula on puheentunnistuksen tekniikka - taustaäänet, mikrofonin asettelu, tunnistus, puhujan opettaminen, sanastojen haasteet Ääniselaimet havainnollistavat siten osaltaan ns. tietojenkäsittelyn vaikeiden ongelmien (Hard Problems) roolia sovelluskehityksessä Muita samantyyppisiä ongelmia ovat esim. - hakutehtävissä helposti esiintyvä kombinatorinen räjähdys (vrt. kauppamatkustajaprobleema, Travelling Salesman Problem), tekoäly (Artificial Intelligence), ja siihen liittyen esim. terve järki ja arkipäättely (Common sense reasoning) Jos vaikeiden ongelmien rajoituksia ei olisi, sovellusten tekeminen helpottuisi merkittävästi! (esim. tehtävien delegointi ohjelmoinnin sijaan) 189

14 8.13 Saavutettavuuden ja laiteriippumattomuuden kehitys Voidaan perustellusti sanoa että sovellusten kognitiivisen saavutettavuuden merkitys korostuu ICT:n kasvun myötä Kuva: Sony Glasstron Syyt sekä teknisiä että sosiaalisia: - kannettavien (sulautettujen yms.) laitteiden tekninen kehitys vähentää "pöytä-pc":n roolia tietojenkäsittelyssä (esim. näytöt ja virtuaalinäppäimistöt) Kuva: H. Maurer - informaation tarjonta lisääntyy ja monipuolistuu (esim. paikka- ja liikeinformaatio, virtuaaliobjektit ja -ympäristöt, sulautettu tuoteinformaatio, jne. ) - käyttäjien tieto- ja koulutustason pirstaloituminen korostaa informaation haun, rajauksen, esikäsittelyn ja ymmärrettävyyden merkitystä - saatavilla olevan informaation määrä kasvaa ymmärrystä nopeammin 190

15 8.14 Toteutuuko Avaruusseikkailu 2001? Kysymys: Mullistaako tekniikka kaiken ja ratkeavatko esim. saavutettavuuden ongelmat laitetekniikan kehittymisen myötä? Vastaus: Ei ja ei. (No, kukaan ei tiedä varmasti...) Koska... - ihmisillä on taipumusta yliarvioida teknistä kehitystä ja aliarvioida de facto käytäntöjen merkitystä osana toteutuvaa kehitystä - uusi ja vanha tekniikka elävät aina rinnakkain, ainakin jonkin aikaa (vrt. LP CD vs. "paperiton toimisto") - toisaalta oman aikansa huipputekniikka ei koskaan ole "kaikkien" käytettävissä (vrt. taloudellinen saav.), joten nykyisen talouskehityksen valossa myös esim. "pc-kansan" absoluuttinen koko jatkanee kasvuaan 191

16 8.15 Lippmann's switch A. Lippmannin (MIT) teesi vuodelta 1995: "metadatan" määrä ja merkitys kasvaa suuremmaksi kuin "varsinaisen sisällön" Huomioita Content Description - kysymys teesin verifioimisesta on epäoleellinen - oleellista on sen sijaan esim. havainto siitä että mitä enemmän tietoa "joudutaan" hakemaan, sitä enemmän ollaan riippuvaisia tiedon kuvailutiedosta (lue: "tiedolla" joka ei ole saatavilla ei ole merkitystä) - toisaalta esim. verrattaisen yksinkertaisenkin monikanavaisen ja/tai multimodaalisen monikanavainen toteutus kuorruttaa ja moninkertaistaa palvelun yksinkertaisen loogisen ytimen eri esitystavoin ja moodein Time 192

17 8.16 Tiedon saatavuus ja semantiikka Osa tietojenkäsittelyn konkreettisista haasteista on seurausta siitä että tietoa (informaatiota) käsitellään eri sovelluksissa eri formaateissa ja eri tietorakenteissa, seurauksena yhteensopivuusongelma Vrt. tyypillinen toimisto-ohjelmistopaketti: - sähköpostin tieto ei ole suoraan käytössä esim. tekstinkäsittelyssä ja asiakashallinnan tieto ei ole suoraan käytössä esim. esitysohjelmassa - verkosta löytyvä uutistieto ei ole automaattisesti yhdistettävissä esim. kalenteriin myös semanttisesti käyttökelpoisessa muodossa jne. Käytännöllinen ratkaisu on tietenkin siirtyminen esim. yhden valmistajan ryhmätyöohjelmistoon joka toteuttaa kaikki sovellukset omalla tavallaan Todellinen pulma piilee kuitenkin tietoa sovelluksesta toiseen kuvaavassa rajapinnassa jos se standardoitaisiin, tieto liikkuisi helpommin 193

18 8.17 Semanttinen Web (SW) W3C:n Semanttinen Web on joukko standardeja ja tekniikoita joka tarjoaa - yhtenäisen tietomallin kuvailutiedolle, - standardin XML-tekstiformaatin kuvailutiedon tallettamiseen (RDF/XML), - välineitä tiedon kuvailurakenteiden kuvailuun (ns. skeemat ja ontologiat) Kuva: W3C SW:n teknisen ytimen muodostaa RDFperhe (Resource Description Format) joka puhuu URI-nimien avulla nimetyistä asioista tai objekteista (ns. Things), URI-nimin nimettyjen käsitteiden välityksellä Semanttista kuvailutietoa muodossa jota myös tietokoneet osaavat tulkita 194

19 8.18 RDF-tietomallin perusidea: subjekti-predikaatti-objekti RDF-tietoa ja RDF/XML-koodaus <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" /02/22-rdf-syntax-ns#" xmlns:contact=" 2000/10/swap/pim/contact#"> <contact:person rdf:about=" le/em/contact#me"> <contact:fullname>eric Miller</contact:fullName> <contact:mailbox <contact:personaltitle>dr.</contact:personaltitle> </contact:person> </rdf:rdf> Kuva: W3C 195

20 8.19 Esimerkki: tietomalli käytännössä Perusidea on siis mallintaa ja esittää eri järjestelmistä löytyvää tietoa standardinmukaisesti aliluokka Opiskelija JOO-opiskelija on tehnyt opintosuorituksen yhteystiedot on Sat arvosanalla Matemaattinen logiikka 5,4,4,5,5,4,5,5:(5) suorituksin Kiitettäv 196

21 8.20 SW ja universaalin tietokannan idea Ajatuksena ei kuitenkaan ole "siirtää" tietoja Semanttiseen Webiin, vaan kuvata tietoja (ts. kyse on enemmän loogisesta kuin fyysisestä rakenteesta) Käytännössä asian voi myös ajatella siten että kyse on universaalin tietokannan määrittelystä yhteensopiva tietomalli SW A' B' C' yhteensopiva tietorakenne sovelluskohtainen tietorakenne Adapter Adapter Adapter A B C 197

22 8.21 Esimerkki "metatietosanastosta": Dublin Core Dublin Core (DC) on kenties tunnetuin standardi esim. verkkosivujen yhteydessä yleisesti käyttökelpoisista kuvailuattribuuteista Perusidea on sopia mitä sanoja käytetään ja miten kun halutaan esim. kertoa sivun tekijästä tai luontipäivämäärä stä koneellisesti tulkittavissa olevassa muodossa 198

23 8.22 Yksinkertainen sovellusesimerkki: RSS Uutistiedon (yms.) välittäminen on konkreettinen esimerkki verkkopalvelusta jossa perinteinen portaaliajattelu kaatuu omaan mahdottomuuteensa kenelläkään ei ole aikaa kahlata käsin läpi kaikkien eri organisaatioiden uutistarjontaa RDF Site Summary (RSS 1.0) määrittelee kehyksen jonka avulla voidaan julkaista ja yhdistellä listamuotoista tietoa, esim. tiedotteita ja uutisia RSS-feed c RSS-feed b eri uutislähteitä yhdistelevä sovellus W3C news: RSS-feed - Ks. esim. ja 199

24 8.23 Tässäkö kaikki? Ei. Palveluiden helppokäyttöisyyden ja saatavuuden merkitys, ja laiteriippumattomuuden, multimodaalisuuden ja saumattoman palvelukokemuksen eri muodot sen kuin korostuvat tietotekniikan arkipäivästyessä (vrt. mobiilipalvelut, digi-tv, mp3-laitteet, kodin viihdekeskukset, ajoneuvosovellukset,...) Ääniselaimet muuttavat maailman. ;-) (vrt. paikkatieto + autosovellukset) Ja esim. SW on rikas, monipuolinen ja mielenkiintoinen järjestelmä (johon palataan opintojaksolla Rakenteisten dokumenttien jatkokurssi...) The bane of my existence is doing things that I know the computer could do for me." -- Dan Connolly, The XML Revolution 200

25 8.24 Lopuksi & kiitos Saavutettavuus tähtää välineiden ja tiedon käytön esteiden poistamiseen - Motto: "Accessibility is Not just for blind people!" (Charles McCathieNevile) Toteutuminen edellyttää tietoa ja osaamista - sovellusalueesta ja sen sisällöistä - käyttäjistä ja käyttötavoista - päätteistä, apuvälineistä ja normeista - tuotannosta ja sen kustannuksista - toteutustekniikasta ja eri vaihtoehdoista Tuotantotyön näkökulmasta DI on usein hyvä ja konkreettinen tapa jäsentää saavutettavia sovelluksia (suunnittelu ja olennaiseen keskittyminen...) 201