7.17 "Tuotantoesim.": oliomainen vieraskirja

Transkriptio

1 7.17 "Tuotantoesim.": oliomainen vieraskirja Valmis esimerkkimme (yksinkertainen vieraskirjasovellus) sisältää seuraavat sivunäkymät - "sisään kirjautuminen" (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 [pda] list login about add greetings.xml ok 144

2 7.18 Skaalautuvia suunnitteluratkaisuja? Oliomaisuus syntyy näkymien toteutusrakenteesta joka hyödyntää ketjutetun sivupohjan mallia saantimekanismin toteutuksessa - jokaista sivunäkymää vastaa "laitetiedon" palvelukontekstin perusteella (device=(pc/pda)) valittu tyyli joka kokoaa sivun informaatioyksiköt - valittujen informaatioyksiköiden esitystapa määräytyy lopulta koko palvelukontekstin kieliasetuksen perusteella (device=(pc/pda), lang=lang) Esimerkissä PHP:n rooli palvelussa jää loppujen lopuksi melko vähäiseksi! - läh. muunnostyylien suorittaminen ja "tietokannan" käsittely 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 145

3 7.19 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>

4 7.20 Oliomainen vieraskirja, douppausta ja huomautuksia Ratkaisua olisi mahdollista helposti optimoida lisää skaalautuvuuden näkökulmasta, esim.: - näyttöjen ohjelmalogiikan siirtäminen kokonaan pois tyyleistä (vrt kohta 2) - kielivalintojen logiikka puhtaasti kielitiedoston perusteella (ks. add) + muu lokalisaatio(!) Erilaisten parannusten myötä päädyttäisiin lopulta keksimään/toteuttamaan yleiskäyttöisen monikanavaisen verkkopalvelun sovelluskehitin (jossa koko palvelun hoitaa "yksi skripti") - lue: em. suunnittelutehtäviin löytyy "valmiina" erilaisia välinekohtaisia ratkaisuja (esim. "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

5 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.,... Ansaintalogiikka (!) Luovuus ongelma? (vrt. harmonisointi) Kuva: W3C/DI 148

6 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ä!) 149

7 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 150

8 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 151

9 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 välittäjä: - yhteydenotto WAP-yhdyskäytävään (Wireless Application Protocol) joka välikäsien avulla käärii ja esittää sivut laitteiden ominaisuuksien mukaisesti Taloudellinen tapa toteuttaa mobiili-palvelu onkin rakentaan perinteinen verkkopalvelu WAP-yhdyskäytävien tarpeet huomioiden 152

10 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 kuitenkin mm. - (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 153

11 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. 154

12 7.28 Esimerkki UA-profiilin laitetason komponentista Kuva: WAP Forum 155

13 7.29 Esimerkki UA-profiilin selaintason komponentista... Kuva: WAP Forum 156

14 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 sopivaa standardia ei (vielä?) ole olemassa Kuva: WAP Forum 157

15 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 Wireless Universal Resource File (WURFL) ratkaisee 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. */ }?> 158

16 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) 159

17 7.33 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 - palvelukontekstin ansiosta myös kieliversiot yms. mahdollisia yhtenäisen perustekniikan varassa Laiteriippumattoman suunnittelun keskeisempiä haasteita 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, kuvat, jne.) 160