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
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
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
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
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
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
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
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
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.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
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
10.11 Palvelukonteksti käytännössä Käyttäjän asetukset sovelluksessa! Media Queries & Rules (esim. CSS2: @media screen { body { /*...*/ }}) HTTP-otsikkotieto (SERVER), ns. HTTP negotiation: - esim. palvelupyyntö "Web-sivusta" tango.html: GET /pub/www/tango.html HTTP/1.1 Host: www.dance.org 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
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
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
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
10.15 Esimerkki tietomallista: greetings.xml Yksinkertainen XML-pohjainen tiedontalletusratkaisu <?xml version="1.0" encoding="iso-8859-1"?> <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>2004-11-18</date> </item> <item lang="en"> <title>what is this?</title> <description>contact ee@corecump.es! </description> <author>elli Ester</author> <date>2004-10-11</date> </item> </data> 170
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>... 171
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
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
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 & @import), 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
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... 175
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
è è è 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
è è è 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
è è è 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" "http://www.wapforum.org/dtd/wml_1.1.xml"> <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
è è è 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
è è è 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. http://www.w3.org/mobile/ 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
è è è 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
è è è 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
è è è 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
è è è 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
è è è 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
è è è Pari sanaa mobiilipalveluista 11.10 Esimerkki UA-profiilin laitetason komponentista Kuva: WAP Forum MATHM-47050 SAAVUTETTAVUUS (syksy 2007) - ON 187
è è è Pari sanaa mobiilipalveluista 11.11 Esimerkki UA-profiilin selaintason komponentista... Kuva: WAP Forum 188
è è è Pari sanaa mobiilipalveluista 11.12 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
è è è Pari sanaa mobiilipalveluista 11.13 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
è è è Pari sanaa mobiilipalveluista 11.14 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
è è è Pari sanaa mobiilipalveluista 11.15 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