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ä. 143

2 7.1 Välisoitto Laiteriippumaton suunnittelu on yleispätevä hyvän suunnittelun ohjenuora" Edellyttää testausta(!) Web-sovelluksissa suurimpia haasteita tuottavat yleensä: - laiteriippumattomat syötemekanismit - sisällön jäsentäminen aidosti eri tavoin eri laitteille (esim. sivutus ja navigointi?, pääsy verkkoon? asiakkaan muistin ja laskentatehon määrä?) 144

3 7.2 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."? 145

4 7.3 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 146

5 7.4 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 (tai -alkioiden, 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 147

6 7.5 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) 148

7 7.6 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) 149

8 7.7 Laiteriippumattomuus, tuottajan näkökulma (2/2) DI-minimitavoite: (yhtäläinen) toiminnallinen käyttökokemus laitteesta riippumatta - 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) 150

9 7.8 Laiteriippumattomuus, välittäjän näkökulma Laite (tai asiakassovellus) 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 151

10 7.9 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") 152

11 7.10 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. 153

12 7.11 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 - teknistä "lisä"tietoa HTTP -pyynnön osaksi 154

13 7.12 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 Mieti käsityön määrää: "PHP-sivuja" vs. "monikanavainen palvelu " (Huomaa Model-View-Controller- tyyppinen arkkitehtuuri) 155

14 7.13 Sovellusesimerkki: vieraskirja Yksinkertainen vieraskirjasovellus sisältää seuraavat sivunäkymät (taustalla loogisia toimintoja) - "sisäänkirjautuminen" (login) - viestilista (list) - yksittäisen viestin tarkastelu (view, vain PDA-kontekstissa) - tietoja kirjasta (about) - viestin kirjoittaminen (add) - viestin lisäys ok (ok) Piirteitä: - pc/pda-kanavat, kieliversiointi - käyttöliittymä esimerkin hengessä minimaalinen (mieti miten pitäisi parantaa esim. saavutettavuuden hengessä! [back-napit jne]) view login [pda] list about add greetings.xml ok 156

15 7.14 Tekniikkaa Perusideoita: - kysytään palvelukonteksti (nyt device=pda pc ja lang=fi en) sisäänkirjautumisen yhteydessä (saavutettavuus?) - kuorrutetaan loogiset toiminnot näkymillä, nyt esimerkin vuoksi listtoiminnon jäsennys muuttuu hieman laitteen perusteella (syöttömekanismien saavutettavuus?) - mukauttaminen tehdään nyt ajonaikaisesti XSL-muunnoksiin nojautuen (suorituskyky?) - hallitaan sovelluksen tietosisältö helppokäyttöisenä XML-dokumenttina (tehokkuus?) - sovelluslogiikan toteutuksena PHP: näkymät hallitaan XSL-muunnosdokumentteina, PHP-koodin murhe on pitää kirjaa palvelukontekstista ja kirjan tiedoista ja kutsua muuntimia (ts. PHP:n merkitys on varsin vähäinen oikeastaan vain 2 loogista toimintoa...) 157

16 7.15 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> 158

17 7.16 Esimerkki kielitiedostosta: gui.lang Yksinkertainen XML-pohjainen tiedontalletusratkaisu (informaatioyksiköt) <locals> <! > <ul category="general"> <li label="gen.title" lang="fi">vieraskirja</li> <li label="gen.title" lang="en">guest-book</li> <li label="gen.to_login" lang="fi">sisäänkirjautumiseen</li> <li label="gen.to_login" lang="en">to the login</li> <li label="gen.to_list" lang="fi">etusivun alkuun</li> <li label="gen.to_list" lang="en">to the main page</li> <li label="gen.to_about" lang="fi">tietoja vieraskirjasta</li> <li label="gen.to_about" lang="en">about the guest-book</li> </ul> <! > <ul category="list"> <li label="list.intro" lang="fi">tervetuloa vieraskirjaan. Toimitus ei vastaa viestien sisällöstä.</li> <li label="list.intro" lang="en">welcome to the guest-book. The editor is not resposible for the greetings.</li>

18 7.17 Tavoitteena "oliomainen" sovellus Suunnittelun näkökulmasta palvelua voidaan tarkastella "oliomaisesti" - motivaatio: hallittavuus ja liikkuvien osien lukumäärän minimointi - perusperiaate: loogiset toiminnot ja näkymät erotetaan teknisessä suunnittelussa - nyt oliomaisuus toteutuu XSLtekniikan avulla (sivupohja vs. palvelukontekstin mukainen näkymä) Perusidea voidaan toteuttaa usein eri tavoin PDAListView View device: DeviceType user: UserClass? lang: Language tomainpage(): Link toaboutpg(): Link ListView addgreeting(): Link PCListView viewgreeting(): Link 160

19 7.18 Erilaisia toteutusvaihtoehtoja 1) 2) greetings.xml greetings.xml gbookview.xml GbookView.php GbookView.php [pda] [pc] [pda] [pc] exec(pdaformat.xsl) exec(pcformat.xsl) exec(pdaformat.xsl) exec(pcformat.xsl) PDAgBookView.php PCgBookView.php PDAgBookView.php PCgBookView.php 3)... GbookView.php [pda] exec(pdaformat.xsl) exec(pcformat.xsl) PCgBookView.php PDAgBookView.php 161

20 7.19 MVC-tyyppisen julkaisumallin etuja Palvelun abstraktin toiminnon ja sen sitä vastaavan näkymän mallintaminen ja esittäminen erillään (vrt. HTML+CSS) - sivupohjien ja toimintokohtaisten näkymien toteuttaminen perintähierarkian mukaisesti (vrt. CSS skaalautuva suunnitteluratkaisu Uusien laitteiden lisääminen on periaatteessa helppoa, laite- ja kieliversiointi voidaan hoitaa symmetrisesti Toteutustyön prosessin haasteita ovat teknisten reunaehtojen ohella esim. saavutettavuus ja harmonisoidun käyttökokemuksen tavoittelu pc pda pc-page pda-page Esim. pda-page-xsl gui.lang pda-list pda-list pda-view pda-add pda-ok pda-about pda-list-xsl 162

21 7.20 Oliomainen vieraskirja, douppausta ja huomautuksia Ratkaisua olisi mahdollista helposti optimoida lisää skaalautuvuuden näkökulmasta, esim.: - näkymien ohjelmalogiikan siirtäminen kokonaan pois tyyleistä ja abstrahointi komponentteina (esim. lomakkeet) - kielitiedoston abstrahointi: informaatioyksiköksi myös esim. kuvia Erilaisten parannusten myötä päädyttäisiin lopulta keksimään/toteuttamaan yleiskäyttöisen monikanavaisen verkkopalvelun sovelluskehitin (jossa koko palvelun hoitaa "yksi skripti + n ohjaustiedostoa") - lue: em. suunnittelutehtäviin löytyy "valmiina" erilaisia välinekohtaisia ratkaisuja (myös "oikeisiin" olio-ohjelmointikieliin liittyen), vrt. Forrest & Cocoon á la xml.apache.org ja cocoon.apache.org) Samalla huomataan miten tuotantotyö alkaa ohjata esim. ulkoasun ja käyttöliittymän suunnittelua sekä päinvastoin

22 7.21 Erityyppisiä suunnittelutehtäviä riippuvuuksineen... Suunnittelun stereotyyppinen roolijako: - layout (taitto), style (look & feel), interaction (syötteet), navigation Sisällöntuotanto, reunaehdot: - saav. suunnittelu, laitteet, teknolog.,... - tuotantoprosessin hallittavuus & hinta Ansaintalogiikka (!) Luovuus ongelma? (vrt. harmonisointi) Kuva: W3C/DI 164

23 7.22 Sovelluksia? mobiili Web ja pienlaitteet Erilaiset mobiilipalvelut ovat tärkeä Web-sovellusten "erikoistapaus" (XHTML vs. WML -maailmat) Vaikka pöytäkoneiden suosio on suuri, uusia käyttöprofiileja syntyy syli- ja kämmenmikrojen myötä: - esim. vuonna 2002 Iso-Britanniassa matkapuhelimilla surffattiin yli 300M Web-sivulle kuukaudessa ( Web-palvelun saavutettavuuden merkitys korostuu kun siirrytään pois isojen näyttöjen, hiiren ja näppäimistön maailmasta (vrt. Mainstreaming) Web-palvelujen näkökulmasta monikanavaisen sisällöntuotannon (ja saavitettavuuden) keskeinen sovellus ovatkin juuri Webin mobiilipalvelut...digi-tv -palvelut voidaan (ainakin osin) toteuttaa samantyyppisten ratkaisujen varassa (mutta paluukanava/selainpulmat vielä merkittäviä!) 165

24 7.23 Sisältöesimerkki: WML-dokumentti WML-dokumentti on XML-dokumentti, kuten HTML-sivu, mutta pieni palvelu koostuu pakasta (Deck) sivuja. <?xml version='1.0'?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" " <wml> <!--...joka tulee sanoista Wireless Markup Language --> <card id="login" title="login"> <do type="accept" label="password"><go href="#password"/></do> <p>username: <select name="name" title="name:"> <option value="john Doe">John Doe</option> <option value="paul Smith">Paul Smith</option> <option value="joe Dean">Joe Dean</option> <option value="bill Todd">Bill Todd</option> </select> </p> </card> <card id="password" title="password:"> <do type="accept" label="results"> <go href="#results"/> </do> <p>password: <input type="text" name="password"/> </p> </card> <card id="results" title="results:"> <p> </p> </card> </wml> You entered:<br/> Name: $(name)<br/> Password: $(password)<br/> Kuva ja esimerkki: ThinkBurst Media 166

25 7.24 Sisältöesimerkki: XHTML Mobile Profile WAP forum on koostanut XHTMLmodularisaatioon ja XHTML Basic - profiiliin perustuvan XMLtekstiformaatin, XHTML Mobile Profile Vastaavasti CSS-tyylikielestä löytyy oma WAP-versio, WCSS Taulukot: WAP Forum 167

26 7.25 Mobiilin Webin tekniikkaa (ideoita) "Ideaalitapauksessa" mobiililaite toimii siis kuten pieni kannettava PC - yhteydenotto ja vuoropuhelu suoraan ensisijaisen Webpalvelimen kanssa (ns. Origin Server) Kuva: WAP Forum Matkapuhelimet yms. ovat kuitenkin (toistaiseksi?) ominaisuuksiltaan omanlaisiaan, niinpä tarvitaan esim. välittäjä: - yhteydenotto WAP-yhdyskäytävään (Wireless Application Protocol) joka välikäsien avulla esittää palvelun eri laitteiden ominaisuuksien mukaisesti Taloudellinen tapa toteuttaa mobiili-palvelu onkin rakentaan perinteinen verkkopalvelu WAP-yhdyskäytävien tarpeet huomioiden 168

27 7.26 Mobiilipalvelut, huomautuksia Mobiilipalvelut ovat periaatteessa samanlaisia kuin Web-palvelut ylipäänsä Kesk. erot syntyvät saavutettavuudesta (pieni näyttö/ näppämistö), laiteriippumattomuudesta ja osin erilaisesta teknisestä palveluinfrastruktuurista (johon emme nyt syvenny) Konkreettisia palveluntarjoajan pulmia ovat mm. (vrt. saavutettavuus!) - (palvelujen markkinointi ja kohderyhmän löytäminen) - (hyvä ja saav. sisältö [josta voi laskuttaa {vaan miten ja kuinka paljon?}) - sisällön esittäminen (esim. HTML/XHTML/WML/CSS/WCSS + gfx jne.) - palvelun jakelukanava (HTTP vs. WAP Gateway) - asiakaspäätteiden tunnistaminen 169

28 7.27 Laiteprofiileja ja ominaisuuksia: WAP UAProf Wireless Application Group User Agent Profile Specification (WAP UAProf) määrittelee oheisen jäsennyksen (komponentit) pienlaitteiden omin.: - HardwarePlatform: A collection of properties that adequately describe the hardware characteristics of the terminal device. This includes, the type of device, model number, display size, input and output methods, etc. - SoftwarePlatform: A collection of attributes associated with the operating environment of the device. Attributes provide information on the operating system software, video and audio encoders supported by the device, and user s preference on language. - BrowserUA: A set of attributes to describe the HTML browser application - NetworkCharacteristics: Information about the network-related infrastructure and environment such as bearer information. These attributes can influence the resulting content, due to the variation in capabilities and characteristics of various network infrastructures in terms of bandwidth and device accessibility. - WapCharacteristics: A set of attributes pertaining to WAP capabilities supported on the device. This includes details on the capabilities and characteristics related to the WML Browser, WTA [WTA], etc. 170

29 7.28 Esimerkki UA-profiilin laitetason komponentista Kuva: WAP Forum 171

30 7.29 Esimerkki UA-profiilin selaintason komponentista... Kuva: WAP Forum 172

31 7.30 Standardi profiilimäärittely? WAP UAProf on esimerkki ns. CC/PP-profiilimäärittelystä (Composite Capability/Preference Profiles 1.0) á la SemWeb CC/PP määrittelee yhteensopivat puitteet eri sovellusalueille soveltuvista profiilimäärityksistä - esim. Java Servlet-ohjelmointi DELI-kirjaston avulla Myös saavutettavuusprofiilin määrittely olisi siten mahdollista suoraan CC/PP:n puitteissa -..mutta käytännössä osa tekniikasta on vasta "tulossa" Kuva: WAP Forum 173

32 7.31 Laiteprofiilit käytännössä: WURFL-esimerkki Laiteprofiili on siis periaatteessa luettavissa HTTP 1.1 -otsikkotiedosta HTTP_UA_OS: Windows CE... Palvelun toteuttajan näkökulmasta oleellista on kuitenkin "vain" palvelukontekstin ja siten palveluprofiilin tunnistaminen "jotenkin" (black box) - luokittelutehtävä tunnistustehtävä?...käytännössä sovelluskehittäjä tarvitsee "vain" (tavalla tai toisella) menetelmän jolla luokitella laite (tai käyttäjä) palvelupyynnön takaa (ks. Wireless Universal Resource File (WURFL) yrittää ratkaista laitteen tunnistamisen pulman keräämällä profiilitietoja todellisista laitteista - tietokantaa täydennetään UAProf-tiedoilla "jatkuvasti" ("Resourcification") <?php require_once('wurfl_class.php'); $device=new wurfl_class($http_user_agent); /* PHP-versiosta riippuen...*/ if($device->browser_is_wap){ /* WAP-julkaisu, jne. */ }?> 174

33 7.32 Saumaton palvelukokemus? Realistisen kokoisessa sovelluksessa yksi ja sama käyttäjä hyödyntää yhtä ja samaa palvelua useita eri päätelaitteita käyttäen - myös vaihto laiteprofiilista toiseen kesken palvelutapahtuman - toimiva yksinkertaistus on ajatella että asiakas voi halutessaan käyttää palvelua kahdella eri selaimella, eri asetuksin (!) Tämä johtaa palveluntarjonnassa ns. saumattoman palvelukokemuksen (Seamless User Experience) tavoitteluun (vrt. saumaton palveluketju) Tyypillisiä strategisen tason tavoitteita (vain osa "teknisiä"): - turhan toiston välttäminen (lue: palvelun tilan ja tietojen sulava siirto) ja eri laiteprofiilien keskeisten hyötyjen tavoittelu (esim. verkko vs. puhelin) 175

34 7.33 Lopuksi: laiteriippumattomuus ja saavutettavuus Laiteriippumaton suunnittelu tarjoaa edellytyksen myös saavutettavan palvelun toteutukselle - "yhtäläinen palvelukokemus eri edellytyksin" - apuvälineiden yms. aktiivinen tukeminen palvelukontekstin perusteella (esim. monikanavaisuuden avulla) Haasteita: kognitiivinen saavutettavuus ja jäsennyksen tarve vrt. selkokieli - suunnittelun monimutkaisuus & sisällöntuottajien "lisäkuormitus" Keskeistä on palvelun käytön analysointi: mitkä piirteet oleellisia eri palvelukonteksteissa Laiteriippumattomuus ja saavutettavuus pitää huomioida myös käyttäjille tarjotuissa tiedon syöttömekanismissa - esim. luonnollisen kielen kysyminen, kuvien alt-tekstit kieliversioineen, jne. 176