10 Saatavuus ja laiteriippumattomuus

Transkriptio

1 10 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ääkin 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ä. 155

2 10.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ä?) 156

3 10.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."? 157

4 10.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 158

5 10.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 informaatioalkioiden (tai -yksikö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 159

6 10.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 informaatioalkiosta - verkkosivuilla (tai yleisemmin: Web-resursseilla (Resource)) on tunniste(nimi), URI-nimi (Web Page Identifier) Verkkosivun sisältämät informaatioalkiot sekä näiden esitystapa voivat vaihdella eri laitteilla tarkasteltuna (ts. vaikka tunnistenimi pysyisi samana) Kun informaatioalkioita 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 160

7 10.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ä informaatioalkioista jäsentyvä sivu kootaan välikäsien kautta tiedonvälitysalkioiden (Delivery Unit) perusteella Kuva: W3C/DI -...joista saantimekanismi osaa tuottaa kontekstin mukaisen esitystavan verkkosivulle (tai yleisemmin: informaatioalkioiden kokoelmalle) 161

8 10.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) 162

9 10.8 Laiteriippumattomuus, välittäjän näkökulma Laite (tai asiakassovellus) esittää tai renderöi (Render) informaatioalkiot 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 163

10 10.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") 164

11 10.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. 165

12 10.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 166

13 10.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) 167

14 10.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 view login [pda] list about add greetings.xml - käyttöliittymä esimerkin hengessä minimaalinen (mieti miten pitäisi parantaa esim. saavutettavuuden hengessä! [back-napit jne]) ok 168

15 10.14 Erään toteutusstrategian (#4) tekniikkaa Esimerkkitoteutuksen 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...) 169

16 10.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> 170

17 10.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 10.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 172

19 10.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 173

20 10.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 174

21 10.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 10.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 176

23 è è è Pari sanaa mobiilipalveluista 11 Pari sanaa mobiilipalveluista Web-palvelun saavutettavuuden merkitys korostuu kun siirrytään pois isojen näyttöjen, hiiren ja näppäimistön maailmasta (vrt. Mainstreaming). Ei liene suurikaan yllätys että erilaiset mobiilipalvelut ovat tärkeä Web-sovellusten "erikoistapaus". Erityisesti: vaikka pöytä- ja sylimikrojen suosio on suuri, uusia käyttäjiä ja käyttötapoja syntyy juuri mobiililaitteiden myötä: (N80, Kuva: Elisa.fi) "Maailmanpankin mukaan yli miljardilla ihmisellä on matkapuhelin ja 80%:lla maailman väestöstä on pääsy GSM-palveluun. Kun käyttäjien määrä lisääntyy miljoonalla joka päivä, lähes neljällä miljardilla ihmisellä on matkapuhelin vuoden 2010 loppuun mennessä" (W3C, 2006) 177

24 è è è Pari sanaa mobiilipalveluista 11.1 Välisoitto Webin Mobiilipalvelut ovat periaatteessa "vain Web-palveluja tietyntyyppisisssä laitteissa" Käytännössä kasvavat markkinat ovat kuitenkin nopeasti nostaneet alan aihepiirin raskaaseen sarjaan On myös mielenkiintoista huomata, että esim. matkapuhelinten käyttöä/käytettävyyttä ohjataan useissa maissa lain voimalla (jopa kohtuuhintaisuuttakin?) 178

25 è è è Pari sanaa mobiilipalveluista 11.2 "Historiallinen 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 179

26 è è è Pari sanaa mobiilipalveluista 11.3 Laitteiden kehittyessä: XHTML Mobile Profile, HTML4, 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 180

27 è è è Pari sanaa mobiilipalveluista 11.4 W3C-MWI (1/3): Mobiilipalveluita Web-tekniikoin W3C käynnisti 2005 "Mobiilin Webin aloitteen" (W3C Mobile Web Initiative, W3C-MWI) - "The Mobile Web Initiative's goal is to make browsing the Web from mobile devices a reality" - Ks. Mobile Best Practices Working Group: - Mobile Web Best Practices 1.0: Millaisia ominaisuuksia on hyvällä Webin mobiilisovelluksella? Mikä on mobiilin Web-käytön "perustaso"? (Se on Default Delivery Context [DDC]) - W3C mobileok Scheme 1.0: "mobileok Level 1", "mobileok Level 2"; vrt. WAI conformance levels 181

28 è è è Pari sanaa mobiilipalveluista 11.5 W3C-MWI (2/3): Mobiililaitteiden "perustaso" (DDC) Usable Screen Width: 120 pixels, minimum. Markup Language Support: XHTML Basic 1.1 [XHTML-Basic] delivered with content type application/xhtml+xml. Character Encoding: UTF-8 [UTF-8]. Image Format Support: JPEG. GIF 89a. Maximum Total Page Weight: 20 kilobytes. Colors: 256 Colors, minimum. Style Sheet Support: CSS Level 1 [CSS]. In addition, CSS Level 2 [CSS2]@media rule together with the handheld and all media types (see CSS 2 Media Types). HTTP: HTTP/1.0 [HTTP1.0] or more recent [HTTP1.1]. Script: No support for client side scripting. 182

29 è è è Pari sanaa mobiilipalveluista 11.6 W3C-MWI (3/3): Tekniikka ei yksin riitä käytännöt Device Description Working Group - Device Description Ecosystem (Millainen systeemi tuottaa ja ylläpitää kuvailutietoja? Keskitetty palveluhakemisto?) - Device Description Landscape (Mitä tekijöitä ja tekniikoita liittyy laitteiden kuvailutietoon) - Device Description Repository Requirements 1.0 (Edellä postuloidulta loogiselta tietovarannolta vaadittavat ominaisuudet?) Hyviä huomioita: - Tekniikan ohella mukana on (taas) tietenkin liiketaloudellisia intressejä - Matkapuhelimien Web-käyttö ja (taloudellis-sosiaalinen) saavutettavuus on keskeisessä asemassa esim. kehittyvien maiden palveluinfrastruktuurin kehittämisessä 183

30 è è è Pari sanaa mobiilipalveluista 11.7 Mobiilin Webin tekniikkaa (ideoita) "Ideaalitapauksessa" mobiililaite toimii käyttäjälle kuten pieni kannettava PC - sisäisesti (?): yhteydenotto ja vuoropuhelu suoraan ensisijaisen Web-palvelimen kanssa (ns. Origin Server); huomaa että jo tässä yhteydessä tietoa saatetaan esikäsitellä Kuva: WAP Forum - Matkapuhelimet yms. ovat kuitenkin (toistaiseksi?) ominaisuuksiltaan erilaisia kuin työasemat, niinpä välittämiseen voidaan tarvita esim. WAPyhdyskäytävää (Wireless Application Protocol) joka välikäsien avulla esittää palvelun eri laitteiden ominaisuuksien mukaisesti 184

31 è è è Pari sanaa mobiilipalveluista 11.8 Mobiilipalvelut, huomautuksia Kun verkkoyhteys löytyy, 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ältö ja vuorovaikutus (esim. XHTML/WML/CSS/WCSS + gfx jne.) - palvelun jakelukanava (HTTP vs. WAP Gateway) - asiakaspäätteiden tunnistaminen (!!!) 185

32 è è è Pari sanaa mobiilipalveluista 11.9 Laitteiden ominaisuuksien kuvailu? -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. 186

33 è è è Pari sanaa mobiilipalveluista Esimerkki UA-profiilin laitetason komponentista Kuva: WAP Forum MATHM SAAVUTETTAVUUS (syksy 2007) - ON 187

34 è è è Pari sanaa mobiilipalveluista Esimerkki UA-profiilin selaintason komponentista... Kuva: WAP Forum 188

35 è è è Pari sanaa mobiilipalveluista 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 189

36 è è è Pari sanaa mobiilipalveluista 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 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. */ }?> 190

37 è è è Pari sanaa mobiilipalveluista Saumaton palvelukokemus? Realistisen kokoisessa sovelluksessa yksi ja sama käyttäjä hyödyntää yhtä ja samaa palvelua useita eri päätelaitteita käyttäen (tai useaa eri palvelua samalla päätelaitteella) - jos kokonaisuus ei ole "saumaton", siirtyminen sovelluksesta tai laitteesta toiseen katkaisee työprosessin (tms.) tai häiritsee sitä tarpeettomasti - toimiva yksinkertaistus on esim. ajatella että asiakas voi samanaikaisesti käyttää yhtä palvelua kahdella eri selaimella, eri asetuksin Tämä johtaa palveluntarjonnassa ns. saumattoman palvelukokemuksen (Seamless User Experience) tavoitteluun (vrt. saumaton palveluketju) Tyypillisiä strategisen tason tavoitteita (joista vain on osa "teknisiä"): - toiston välttäminen (palvelun tilan ja tietojen sulava/eheä siirto) ja eri laiteprofiilien keskeisten hyötyjen tavoittelu (esim. verkko+puhelintuki) 191

38 è è è Pari sanaa mobiilipalveluista Lopuksi: laiteriippumattomuus ja saavutettavuus Laiteriippumaton suunnittelu tarjoaa edellytyksen myös saavutettavan palvelun toteutukselle - "yhtäläinen palvelukokemus eri edellytyksin" - mobiililaitteiden, apuvälineiden yms. ominaisuuksien huomioiminen palvelukontekstin perusteella (esim. monikanavaisuuden avulla) Haasteita: - laitteiden ja laitetietojen kirjavuus - palvelun rakenteen uudelleenjäsentäminen ja kognitiivinen saavutettavuus - tiedon syöttö - suunnittelun monimutkaisuus & sisällöntuottajien "lisäkuormitus" (hinta) Keskeistä on palvelun käytön analysointi: mitkä piirteet oleellisia eri palvelukonteksteissa & eri käyttötilanteiden vahvuuksien hyödyntäminen 192