7 Saatavuus ja laiteriippumattomuus

Transkriptio

1 7 Saatavuus ja laiteriippumattomuus Taloudellisesti toteutettu ja saavutettava sovellus ilmentää laiteriippumatonta suunnittelua. Asian voi nähdä myös toisin päin: sopivasti käsitteellisesti terästettynä, laiteriippumaton suunnittelu sisältää saavutettavuuden yhtenä osa-alueenaan (tai jopa "erikoistapauksena"). Saavutettavuutta pitää aktiivisesti arvioida ja kehittää, todelliset käyttäjät huomioiden. Laiteriippumattomuus kuitenkin pitkälti näyttää miten saavutettavuus järkevästi toteutetaan esim. monikanavaisessa tuotantoympäristössä. Saavutettavuus ja saatavuus Laiteriippumaton sovellusarkkitehtuuri mobiili Web 127

2 7.1 Saavutettavuus vs. saatavuus Saavutettavuuden tai esteettömyyden (Accessibility) ideaa täydentää yleisempi saatavuuden (Access) käsite: - "saavutettavuus toimii (teknisen) saatavuuden varassa" Saatavuus on osa Web-kehitystyön pitkäjänteisiä tavoitteita (W3C, 2004): 1. Universal Access: "To make the Web accessible to all by promoting technologies that take into account the vast differences in culture, languages, education, ability, material resources, access devices, and physical limitations of users on all continents" 2. Semantic Web: "To develop a software environment that permits each user to make the best use of the resources available on the Web" 3. Web of Trust: "To guide the Web's development with careful consideration for the novel legal, commercial, and social issues raised by this technology."? 128

3 7.2 Laiteriippumattoman arkkitehtuurin perusteet Konkreettinen lähestymistapa jäsentää laiteriippumattomuuden (Device Independence) käsite on avata palveluprosessien teknisiä komponentteja Keskeiset osat ja käsitteet (W3C/DI, 2004): - asiakas, välittäjä(t) ja palvelin - palvelupyyntö ja palvelukonteksti (attribuutit) Ts. ideaalitilanteessa pääte valitaan asiakkaan mukaan ja sopiva välittäjä voi jäsentää palvelun haluttuun muotoon koska sillä on tieto käyttäjästä ja päätelaitteesta Kolme näkökulmaa: käyttäjä, välittäjä ja tuottaja 129

4 7.3 Laiteriippumattomuus, käyttäjän näkökulma (1/2) Tavoitteena on tietenkin sovelluksen käyttökokemus (User Experience) eri laittein - "laite" (Device) toteuttaa vain käyttäjäkokemuksen "loppupään", yleensä esittäen käyttöliittymän/näkymän yms. Käyttökokemuksen (ja siten myös Kuva: W3C/DI vuorovaikutuksen) perustana on informaatioyksiköiden (Perceivable Unit) kokoelma, joka voidaan välittää käyttäjien laitteille ja esittää eri tavoin eri laitteissa Käyttö toteutuu saantimekanismin (Access Mechanism) välityksellä, joka (tyypillisesti useiden välivaiheiden kautta) toteuttaa käyttökokemuksen, ennalta määriteltyihin informaatioyksiköihin perustuen 130

5 7.4 Laiteriippumattomuus, käyttäjän näkökulma (2/2) Tyypillinen tapa koostaa informaatioyksiköitä tapahtuu verkkosivujen (Web Page) muodossa - verkkosivu voi koostua yhdestä tai useammasta informaatioyksiköstä - verkkosivuilla (tai yleisemmin: Web-resursseilla (Resource)) on tunniste(nimi), URI-nimi (Web Page Identifier) Verkkosivun sisältämät informaatioyksiköt sekä näiden esitystapa voivat vaihdella eri laitteilla tarkasteltuna (ts. vaikka tunnistenimi pysyisi samana) Kun informaatioyksiköitä käytetään annetun tehtävän suorittamiseen, syntyy toiminnallinen käyttökokemus (Functional User Experience) - Huom. "tehtävä" voi olla täysin triviaali, esim. äänileikkeen kuunteleminen tai tekstin lukeminen (tyypillinen haaste on esim. käyttäjän syöte) 131

6 7.5 Laiteriippumattomuus, tuottajan näkökulma (1/2) Laiteriippumattomuuden lähtökohta on palvelukontekstin tunnistaminen (ja siten laitteen ja edelleen saantimekanismin tukeminen) -...ja edelleen verkkosivun mukauttaminen tai adaptointi (Adapting) ko. laitteelle sopivaksi Adaptoinnin yhteydessä informaatioyksiköistä jäsentyvä sivu kootaan välikäsien kautta tiedonvälitysyksiköiden (Delivery Unit) perusteella Kuva: W3C/DI -...joista saantimekanismi osaa tuottaa kontekstin mukaisen esitystavan verkkosivulle (tai yleisemmin: informaatioyksiköiden kokoelmalle) 132

7 7.6 Laiteriippumattomuus, tuottajan näkökulma (2/2) (Yhtäläisen) toiminnallisen käyttökokemuksen tavoittelu on laiteriippumattomuuden minitavoite - "vrt. saavutettavuuden A-taso" Käytännössä palvelun tuottaja tyypillisesti haluaa että laiteriippumaton palvelu paitsi "toimii", myös täyttää esim. PC/PDA-laitteille yleisesti asettamiaan laatu/ ulkoasu/ käytettävyystavoitteita:...tuloksena harmonisoidun käyttökokemuksen (Harmonized User Experience) käsite ("tasalaatuinen/huoliteltu käyttökokemus") lisäsuunn. esim. sovelluksen laitekoht. ulkoasun ja sommittelun suhteen Harmonisoidun käyttökokemuksen tavoite asettaa käytännössä haasteita monikanavaiselle julkaisuprosessille (johon siis myös käyttöliittymä sisältyy) 133

8 7.7 Laiteriippumattomuus, välittäjän näkökulma Laite (tai sen osa: käyttäjäagentti) esittää tai renderöi (Render) informaatioyksiköt käyttäjälle Lopputulokseen voidaan vaikuttaa asetusten tai preferenssien avulla, - esitystapaan (Rendering Prefs.), - mukauttamiseen (Adapting Prefs.), tai - personointiin (Personalization) liittyen Esim. "teksti isommaksi, kuvat pois ja sisältö suomen kielellä" Kuva: W3C/DI 134

9 7.8 Välikädet palvelun osana Tieto palvelukontekstista voidaan saada eri tavoin: - palvelua pyytävä asiakas (Requestor) voi kertoa kontekstin - palvelin (Server) tai palveluntarjoaja (Provider) voi (yrittää) tunnistaa kontekstin (tai täydentää sitä) Kontekstitieto voidaan myös esittää eri tavoin, esim. Kuva: W3C/DI - attribuuttijoukkona (näyttö: 240*320, selain: XHTML Basic, kohdistin: kynä) - laiteprofiilin tai laitteen tunnistenimenä ("Nokia 9210 Communicator 1.0") 135

10 7.9 Laiteriippumattoman suunnittelun periaatteet For some web content or application to be device independent, it should be possible for a user to obtain a functional user experience associated with its web page identifier via any access mechanism. A web page identifier that provides a functional user experience via one access mechanism should also provide a user experience of equivalent functionality via any other access mechanism. It should be possible to provide a functional user experience, in response to a request for a web page, in any given delivery context that has an adequate access mechanism. If a functional user experience of an application cannot be provided due to inherent limitations in the access mechanism, an explanatory message should be provided to the user. If the author wishes, it should be possible to provide a harmonized user experience, in response to a request for a web page, in any given delivery context that has an adequate access mech. The user agent should be able to associate the characteristics of the delivery context with a request for a particular web page. It should be possible for a user to provide or update any adaptation preferences as part of the delivery context. 136

11 7.10 Palvelukonteksti käytännössä Käyttäjän asetukset sovelluksessa! Media Queries & Rules (esim. screen { body { /*...*/ }}) HTTP-otsikkotieto (SERVER), ns. HTTP negotiation: - esim. palvelupyyntö "Web-sivusta" tango.html: GET /pub/www/tango.html HTTP/1.1 Host: Accept-Language: fi /* Haluan sivun suomeksi! (...vastauksena kenties sivu tango.html.fi ) */ Composite Capabilities/ Preferences Profile, CC/PP WAP User Agent Profile (UAProf): CC/PP-profiilit WAP-ympäristöön - toteutus CC/PP-HTTP: uudet Profile ja Profile-Diff -kentät HTTP -pyynnön osaksi & Profile-warning -vastaus palautteeseen Muitakin toteutustapoja toki on 137

12 7.11 Esimerkki: kaksikanavainen verkkopalvelu (idea) Get delivery context Adapt view & state to device / delivery context Rendering & service dialogue (access mechanism, intermediaries) [other] Device [PC] Bind/Transform/ Redirect "PC view" Sorry: no service! [PDA] Bind/Transform/ Redirect "PDA view" Supported devices Model / Origin server Controller Controller / Intermediary Toteutustekn. voi käytännössä vaihdella suurestikin: "sovellukset käsityönä" vs. " monikanav. julkaistu skripti per laite" vs. "oliopolymorfismi"

13 7.12 Menetelmä #1: mukautetut PHP-sivut (idea) greetings.xml parseprint.php... qbook.php Get delivery context qbook_show.php... greet_add.php greet_show.php qbook_default.css qbook_pda.css "Monikanavaisen vieraskirjan karvalakkiversio" - toteutuksen idea: kysytään/ongitaan palvelukonteksti (pda pc), jota viedään parametrina palvelun eri osat toteuttaville sivupohjille. Palvelun tiedot hallitaan XML-dokumenttina (Huomaa parametrinvälityksen määrä!) 139

14 7.13 Esimerkki tietomallista: greetings.xml Yksinkertainen XML-pohjainen tiedontalletusratkaisu <?xml version="1.0" encoding="iso "?> <data> <item lang="fi"> <title>terveisiä Porista!</title> <description> Hyvältä näyttää, hyvää Joulua kaikille! (En vain tajua miksei sisältö toimi oikein Gospel 2.1 -selaimessani!?!?!) </description> <author>aimo K. Pamaus</author> <date> </date> </item> <item lang="en"> <title>what is this?</title> <description>contact </description> <author>elli Ester</author> <date> </date> </item> </data> 140

15 7.14 Menetelmä #2: julkaistu oliomainen sovellus (idea) Palvelun mallintaminen oliomaisesti - huom. a) oliomaisuus systemaattisen suunnittelun tukevan vs. b) oliomaisuus tietyn työkalun osana Esimerkki "Vieraskirjan toteutus ja prosessin hallinta kanavatekniikalla" - erään toteutuksen idea: erotetaan abstrakti palvelu ja sen esitystapa ja kuvataan/mallinnetaan molemmat formaalisti. Kukin sovelluksen sivu tuotetaan XSL-muunnostyylillä palvelu- ja profiilitietoihin nojautuen (oo-qbook.php) PDAgBookView View device: DeviceType user: UserID lang: Language tomainpage(): Link GBookView addgreeting(): Link findgreeting(): Link "Toinen tapa jäsentää/toteuttaa qbook_show.php ed. sivulta" PCgBookView viewgreeting(): Link 141

16 7.15 Menetelmä #2: neljä toteutusvaihtoehtoa (muitakin on) 1) 2) greetings.xml greetings.xml gbookview.xml [pda] GbookView.php [pc] "ooqbook. php" [pda] GbookView.php [pc] exec(pdaformat.xsl) exec(pcformat.xsl) exec(pdaformat.xsl) exec(pcformat.xsl) PDAgBookView.php PCgBookView.php PDAgBookView.php PCgBookView.php 3, 4)... GbookView.php [pda] exec(pdaformat.xsl) exec(pcformat.xsl) PCgBookView.php PDAgBookView.php 142

17 7.16 Oliomaisen julkaisumallin etuja Oliomaisen julkaisuprosessin keskeisiä etuja ovat - palvelun asbtraktin näkymän/toiminnon (informaatioyksikön) ja sen esitystavan mallintaminen ja esittäminen erillään - sivupohjien ja toimintokohtaisten näkymien toteuttaminen "perintähierarkian mukaisesti" Käytännössä tämä tarkoittaa esim. - uusien laitteiden lisääminen on helppoa (uusi abstraktin näkymän esitystapa esim. XSLT-tekniikalla laitetiedon perusteella) - esim. laite- ja kieliversiointi voidaan hoitaa symmetrisesti Toteutustyön prosessin reunaehtoja ovat teknisten reunaehtojen ohella esim. saavutettavuus ja harmonisoidun käyttökokemuksen tavoittelu 143