AALTO-YLIOPISTO Perustieteiden korkeakoulu Tietotekniikan tutkinto-ohjelma Luonto- ja kulttuurimatkailua tukevan mobiilipalvelun prototypointi Diplomityö Olli Rinne Tietotekniikan laitos Espoo 2012
AALTO-YLIOPISTO PERUSTIETEIDEN KORKEAKOULU Tietotekniikan tutkinto-ohjelma DIPLOMITYÖN TIIVISTELMÄ
Tekijä: Työn nimi: Olli Rinne Luonto- ja kulttuurimatkailua tukevan mobiilipalvelun prototypointi Päiväys: 30. tammikuuta 2012 Sivumäärä: 12 + 90 Pääaine: Ohjelmistotuotanto ja -liiketoiminta Valvoja: prof. Matti Hämäläinen Ohjaaja: TkL Sirpa Riihiaho Tämän tutkimuksen tavoitteena on suunnitella ja kehittää luonto- ja kulttuurimatkailua tukevan mobiilipalvelun prototyyppi ja arvioida kehitystyön ja sen tuloksena syntyneen prototyypin avulla teknologiaa kehittäjän kannalta sekä sisältöä ja käyttöliittymää käyttäjän kannalta. Työssä tarkastellaan tutkimusaihetta palveluissa käytettyjen ohjelmistoratkaisujen, paikkatiedon käsittelyn ja ihmiskeskeisen suunnittelun näkökulmasta. Työssä käytetään konstruktiivisen tutkimusotteen mukaista lähestymistapaa, jossa tosielämässä havaittuun ongelmaan pyritään kehittämään ratkaisu. Prototyypin kehitystyössä käytetään HTML5-standardiin perustuvia ohjelmistokehitysvälineitä mobiililaitteilla toimivan prototyyppisovelluksen toteuttamiseen. Sovelluksen käyttökelpoisuutta testataan keräämällä käyttäjätietoa sovelluksen käytettävyydestä ja sisällöstä. Työn teoriaosuudessa taustoitetaan kirjallisuustutkimukseen perustuen aiheeseen liittyviä teknisiä kysymyksiä, työssä käytettyjä tutkimusmenetelmiä sekä aihepiiristä aikaisemmin tehtyä tutkimustyötä. Työ empiirisessä osassa esitellään prototyyppisovelluksen kehitystyötä niin kehitysprosessin teknisen ja sisällöllisen kuin käyttäjätestauksenkin näkökulmista. Käyttäjätiedon keruussa käytetään laveaa menetelmävalikoimaa: teemahaastatteluja, käyttölokin keruuta, kyselyjä ja ryhmäkeskusteluja. Työssä tarkastellaan näillä menetelmillä saatuja tuloksia ja arvioidaan menetelmien käyttökelpoisuutta. Käyttäjiltä kerättyä tietoa hyödynnetään myös suunnitteluperustana ratkaisukonstruktion iteratiivisessa kehitystyössä. Tässä työssä osoitetaan, että HTML5-pohjaisilla ohjelmistokehitystyökaluilla voidaan toteuttaa sellaisia paikkatietoon pohjautuvia mobiilisovelluksia, jotka toimivat useissa eri käyttöjärjestelmiä käyttävissä mobiililaitteissa. Työssä kuvataan menetelmiä, joilla julkisista lähteistä kerätty paikkatieto saadaan prototyyppisovelluksen käyttöön. Työssä todetaan, että paikkatietojen ja kartta-aineistojen käyttöönotto vaatii niin teknistä kuin paikkatietojen kuvaamiseen liittyvää osaamista. Käytetyistä käyttäjätutkimusmenetelmistä haastattelut ja ryhmäkeskustelut todetaan kehitystyön kannalta hyödylliseksi. Käyttölokin keruun arvioidaan olevan mahdollisesti tehokas tutkimustapa kehitystyön myöhemmissä vaiheissa. Sovelluksen yhteydessä olevaa kyselyä ei näiden sijaan nähdä mielekkäänä tapana kerätä käyttäjätietoa. Avainsanat: luontomatkailu, mobiiliteknologia, paikannus, html5, prototypointi, paikkatieto, käyttäjätutkimus Kieli: Suomi
AALTO UNIVERSITY ABSTRACT OF SCHOOL OF SCIENCE MASTER S THESIS Faculty of Information and Natural Sciences Degree Program of Software Business and Engineering
Author: Olli Rinne Title of thesis: Prototyping a mobile service supporting nature and culture heritage tourism Date: January 30, 2012 Pages: 12 + 90 Professorship: Software Engineering and Business Supervisor: Professor Matti Hämäläinen Instructor: Sirpa Riihiaho, Lic. Sc. (Tech) This thesis reports a design process of a prototype mobile application supporting nature and culture heritage tourism. The development process of the prototype is evaluated from the software development perspective. The user interface and the content of the prototype application are analysed from the user s point of view. The research uses constructive approach as a research methodology. The constructive approach means problem solving through model solutions, in this case prototype application. In this research usefulness of the developed prototype application is tested by evaluating collected user data with various methods. Four user data collection methods; namely, theme interviews, focus-group discussions, activity logging, and surveys were used in this research. The collected user data is utilised in the iterative design process of the prototype application. This thesis consists of a literature survey and an empirical study. The literature survey introduces the methods and technologies used in the empirical study and related work on research subject. The empirical study introduces research from the three main research perspectives; namely, software development of HTML5-based mobile web application, management of geographically referenced data, and human-centred design of location-based mobile application. This thesis demonstrates that the HTML5-based software development architecture can be used to implement location-based mobile data applications. HTML5-based web applications with a single codebase can be executed on heterogeneous mobile devices. Interviews and focus-group discussions were found to be effective methods in user data collection for design process. Activity logging was assessed as apotentialmethodtobeusedinthelaterphasesofthedesignprocess. In contrast, web based survey associated with the prototype application had only minimal value to the design process mainly because of low response rate. Keywords: ecotourism, mobile technology, positioning, html5, prototyping, gis, lbs Language: Finnish
Kiitokset Osoitan kiitokseni kaikille tämän työn tekemiseen vaikuttaneille ja siinä auttaneille. Erityisesti haluan kiittää ohjaajaani Sirpa Riihiahoa ja valvojaani Matti Hämäläistä. Lisäksi haluan kiittää hyvästä yhteistyöstä Sampo Terästä prototyyppisovelluksen käyttöliittymän suunnittelussa sekä Outdoors Finland Etelä -hankkeen projektipäällikkö Pirjo Räsästä ja teemahaastattelujen tekijöitä Karoliina Jaskaria ja Maili Lydeckeniä. Helsingissä 30. tammikuuta 2012 Olli Rinne
Käytetyt lyhenteet A-GPS Ajax API AR BOM DOM CSS GDAL GIS GNSS GPS HTML KKJ LBS OFE OSM PDA POI REST W3C WCS WFS WGS84 WMS WWW Assisted GPS; avustettu GPS-paikannus Asynchronous JavaScript And XML; vuorovaikutteisuutta tukeva webtekniikka Application Programming Interface; ohjelmointirajapinta Augmented Reality; lisätty todellisuus Browser Object Model; selaimen ominaisuuksien lukemiseen ja päivittämiseen käytetty ohjelmointirajapinta Document Object Model; webdokumenttien lukemiseen ja päivittämiseen käytetty ohjelmointirajapinta Cascading Style Sheets; erityisesti WWW-dokumenteille kehitetty tyyliohjeiden laji Geospatial Data Abstraction Library; paikkatiedon konversioihin tarkoitettu ohjelmakirjasto Geographic Information System; paikkatietojärjestelmä Global Navigation Satellite Systems; koko maailman kattava satelliittipaikannusjärjestelmä Global Positioning System; Yhdysvaltain puolustusministeriön kehittämä ja rahoittama satelliittipaikannusjärjestelmä Hypertext Markup Language; hypertekstidokumenttien kuvauskieli Kartastokoordinaattijärjestelmä; käytöstä poistuva suomalainen koordinaattijärjestelmä Location-Based Service; paikkatietoon perustuva palvelu Outdoors Finland Etelä; luonto- ja kulttuurimatkailureitistöjen kehityshanke OpenStreetMap; yhteisöllinen kartoitushanke Personal Digital Assistant; kämmentietokone Point of Interest; kiinnostava kohde Representational State Transfer; HTTP-protokollaan perustuva ohjelmistoarkkitehtuurimalli World Wide Web Consortium; webteknolgioiden standardointiorganisaatio Web Coverage Service; hilamuotoista (esim. korkeusmallit) paikkatietoa tuottava palvelurajapinta Web Feature Service; vektorimuotoista paikkatietoa tuottava palvelurajapinta World Geodetic System 1984; Yhdysvaltain puolustushallinnon määrittelemä koordinaattijärjestelmä ja koordinaatisto Web Map Service; rasterimuotoista kartta-aineistoa tuottava palvelurajapinta World Wide Web; internetissä toimiva hajautettu hypertekstijärjestelmä
Sisältö 1 Johdanto 1 2 Paikkatietoon liittyvä teknologia 3 2.1 Paikannusteknologia... 3 2.1.1 Matkapuhelinverkkoon perustuva paikannus... 3 2.1.2 Satelliittipaikannus... 4 2.1.3 Muita paikannusteknologioita... 5 2.2 Paikkatiedon hallinnan ohjelmistoarkkitehtuuri... 5 3 Websovelluskehitys mobiiliympäristössä 7 3.1 Ohjelmointiympäristön valinta... 7 3.2 HTML5... 7 3.3 JavaScript... 8 3.4 Ajax... 9 3.5 REST - the Representational State Transfer... 9 3.6 Geolocation API... 9 3.7 Offline-sovellukset... 10 4 Tutkimusmenetelmät 11 4.1 Konstruktiivinen tutkimusote... 11 4.2 Ratkaisumallin testaustavat... 13 4.2.1 Kenttätestaus... 13 4.2.2 Teemahaastattelu... 14 4.2.3 Kysely... 14 4.2.4 Ryhmäkeskustelut... 14 4.2.5 Käyttölokin kerääminen... 15 5 Aikaisempi tutkimus 17 7
5.1 Luontomatkailijan käyttötarpeet... 17 5.1.1 Retken suunnittelu ja kohteen löytäminen... 18 5.1.2 Sijaintitieto ja turvallisuus... 18 5.1.3 Olosuhteiden seuraaminen... 19 5.1.4 Kokemusten tallentaminen ja jakaminen... 19 5.1.5 Integroidut ja mukautuvat palvelut... 19 5.2 Mobiilikarttasovelluksen käyttökontekstit... 19 5.3 WebPark... 22 5.3.1 WebPark-tutkimushanke... 22 5.3.2 iwebpark-mobiilisovellus... 23 5.4 Travel MoCo... 24 5.5 CRUMPET... 25 6 Suunnitteluprosessin kuvaus 27 6.1 Iteratiivinen järjestelmäkehitys... 27 6.2 Kartoitusvaihe... 28 6.2.1 Paikkatietoaineistoihin tutustuminen... 28 6.2.2 Kehitysympäristöjen arviointi... 30 6.3 Ensimmäinen iterointivaihe... 30 6.3.1 Prototyypin kohderyhmän ja palvelusisällön määrittely... 31 6.3.2 Kehitysarkkitehtuurin ja -työkalujen valinta... 31 6.3.3 Käyttöliittymän suunnittelu... 31 6.3.4 Sovelluksen toteutus ja ylläpito... 32 6.3.5 Käyttöliittymän toteutusvaiheen aikainen kenttätestaus... 33 6.3.6 Käyttäjähaastattelut kentällä... 33 6.3.7 Osallistuminen Apps4Finland-kilpailuun... 33 6.3.8 Ryhmäkeskustelut... 34 6.4 Toinen iterointivaihe... 34 7 Prototyyppisovelluksen tekninen suunnittelu 35 7.1 Yleisarkkitehtuuri... 35 7.2 Asiakasohjelmiston tukikirjastot... 35 7.2.1 Tunnistuspalvelut... 36 7.3 Sovelluspalvelimen ja asiakassovelluksen kommunikaatio... 37 7.4 Sovellustietokanta... 38
7.5 Mediawiki... 38 8 Prototyyppisovelluksen sisällöntuotanto 39 8.1 Kartografinen sisältö... 39 8.1.1 Taustakartat... 39 8.1.2 Kohteiden karttasymbolit... 40 8.2 POI-aineistot... 40 8.2.1 Tiedosto- ja koordinaattikonversiot... 40 8.2.2 ESRI Shapefile -muunnokset... 40 8.2.3 Suomen ympäristökeskuksen aineistot... 41 8.2.4 Museoviraston muinaisjäännösrekisteri... 41 8.2.5 Natura-luontotyyppiaineistot... 42 8.3 Yhteisöllinen sisältö... 42 8.4 Linkitetty sisältö... 43 9 Käyttäjätutkimuksen toteutus ja tulokset 45 9.1 Kenttätestaus... 45 9.2 Haastattelut... 47 9.3 Kysely... 48 9.4 Käyttöloki... 49 9.5 Ryhmäkeskustelut... 51 9.5.1 Suunnittelu ja toteutus... 51 9.5.2 Käyttäjäkommentit sovelluksesta... 53 9.5.3 Käyttäjäkommentit loppukeskustelussa... 53 9.6 Tutkimusaineiston tarkastelu... 54 9.6.1 Kenttätestaus... 54 9.6.2 Haastattelut... 54 9.6.3 Käyttöloki... 54 9.6.4 Kysely... 55 9.6.5 Ryhmäkeskustelu... 55 9.6.6 Eri tutkimustapojen tuottamien tulosten vertailu... 55 10 Johtopäätökset 57 10.1 Teknologiset ratkaisut... 57 10.2 Sisältö... 57
11 Pohdinta 59 11.1 Tutkimuksen kautta tullut kokemus... 59 11.1.1 Paikkatietoaineistojen hallinta ja julkisen datan käyttö... 59 11.1.2 Paikkatietoa hyödyntävä mobiiliwebteknologia... 60 11.1.3 Käyttäjätiedon hankinta osana suunnitteluprosessia... 60 11.1.4 Käyttäjätarpeiden toteutuminen... 60 11.1.5 Tutkimuksen yleistettävyys... 61 11.2 Jatkokehitys... 61 11.2.1 Tekninen jatkokehitys... 61 11.2.2 Käyttöliittymän kehittäminen... 61 11.2.3 Palvelusisällön kehittäminen... 62 Lähteet 64 Liitteet 70 A Käyttölokiin kirjattavat toiminnot 71 B Käyttölokin tutkimustulokset 73 C Ohjeistus prototyypin koekäyttöön - sähköposti 75 D Kyselylomake 77 E Kyselyn tulokset 79 F Tietokannan kuvaus 81 G Käyttöliittymän rakennekaavio 83 H Näyttökopiot käyttöliittymästä 85 I Haastattelurunko 87 J Haastattelujen tuloksia 89
1Johdanto Luontomatkailu on matkailua, jonka vetovoimaisuus perustuu oleellisesti luonnonympäristöön, esimerkiksi maisemaan, ja siellä toteutettavaan toimintaan (Koivula, 2010). Tässä työssä luontomatkailulla tarkoitetaan sekä opastettua että omatoimista retkeilyä, luontoliikuntaa ja luonnossa tapahtuvia aktiviteetteja. Kulttuurimatkailulla tarkoitetaan tässä työssä kaupunkien ja taajama-alueiden ulkopuolella tapahtuvaa matkailua, jossa kulttuurikohteet, kuten kulttuuriperintökohteet tai -alueet, toimivat matkailun vetovoimatekijänä. Matkailijalle, esimerkiksi pyörä- tai melontaretkeilijälle, yksittäisen matkan vetovoima voi perustua sekä luonto- että kulttuurikohteiden tuottamaan vetovoimaan. Tämän työn kannalta luonto- ja kulttuurimatkailua palvelevan sovelluksen käyttäjätarpeet nähdään pitkälti yhtenevinä. Tämän tutkimuksen tavoitteena on suunnitella ja kehittää luonto- ja kulttuurimatkailua tukeva mobiilipalvelu ja arvioida kehitystyön ja sen tuloksena syntyneen prototyypin avulla teknologiaa kehittäjän kannalta sekä sisältöä ja käyttöliittymää käyttäjän kannalta. Tutkimuksen päätavoitteena on arvioida prototyyppisovelluksen avulla erityisesti sovelluskehityksessä käytettyjen ohjelmistoteknisten ratkaisujen soveltuvuutta paikkatietoa hyödyntävän mobiililaitteilla toimivan websovelluksen toteutukseen sekä teknisen kokonaiskonseptin toimivuutta. Useilla eri menetelmillä toteutettujen käyttäjätutkimuksien avulla selvitetään prototyypin käytettävyyttä sekä käyttäjien kiinnostusta palvelun sisältöön ja käyttämiseen. Käyttäjiltä kerättyä tietoa hyödynnetään myös suunnitteluperustana ratkaisukonstruktion iteratiivisessa kehitystyössä. Tässä työssä ei painotuta mobiilipalvelun käyttämien teknisten ratkaisujen, kuten tietokantojen ja niitä hyödyntävien palvelinkomponenttien, ohjelmistokehitykseen, vaan näitä palveluita on toteutettu vain siinä laajuudessa, kun prototyyppipalvelun toimivuuden varmistamiseksi on nähty tarpeelliseksi. Prototyyppisovelluksen ja sen karttanäkymien visuaalinen ulkoasu ja ulkoasusuunnittelun kautta saatu käyttäjäkokemus ei myöskään ole työn tutkimuskohteena. Tutkimustavoitteen saavuttamiseksi tutkimuksessa käytetään konstruktiivista tutkimusotetta, jossa tieteellisen tutkimuksen ja kohdealueen käytännön välillä on kiinteä vuorovaikutus. Konstruktiivisen tutkimusotteen mukaisessa tutkimuksessa lähdetään liikkeelle tosielämässä havaitusta ongelmasta ja tutkimuksella pyritään kehittämään ongelmaan ratkaisu. Tämän jälkeen kehitettyä ratkaisumallia testataan käytännössä, minkä jälkeen tulokset kytketään aikaisempaan tietämykseen samalla pohtien mallin soveltamisalueen laajuutta. Ratkaisukonstruktion tavoitteena on johtaa käytännössä toimivaan ja tosielämässä sovellettavaan ratkaisuun. (Lukka ja Tuomela, 1994) Tämä työ jakautuu kolmeen osaan, joista ensimmäisessä taustoitetaan aiheeseen 1
LUKU 1. JOHDANTO 2 liittyviä teknisiä kysymyksiä, työssä käytettyä tutkimusmenetelmää sekä aihepiiristä aikaisemmin tehtyä tutkimustyötä. Kuudennesta luvusta alkavassa toisessa osassa esitellään prototyyppisovelluksen kehitystyötä niin kehitysprosessin teknisen ja sisällöllisen kuin käyttäjätestauksenkin näkökulmista. Työn lopussa arvioidaan tutkimuksen tuottamia tuloksia ja sen onnistumista ja pohditaan mahdollisia jatkotoimenpiteitä.
2Paikkatietoonliittyväteknologia Tässä luvussa käsitellään mobiililaitteiden paikannukseen liittyviä teknologisia ratkaisuja sekä paikkatiedon käsittelyyn liittyviä ohjelmistoteknisiä palveluita ja koordinaattijärjestelmiin liittyviä kysymyksiä. Ulkona liikkuvan matkailijan paikannukseen ja paikkatietoon liittyvä käyttökonteksti on kuvattu yleisellä tasolla kuvassa 2.1. Tämän käyttökontekstin keskeisiä osia ovat luonnossa liikkuva mobiilisovellusta käyttävä retkeilijä, sovellukselle paikkasidonnaista sisältöä tuottavat palvelut ja tietokannat sekä paikannukseen ja tiedonsiirtoon liittyvät laitteet ja yhteydet. Kuva 2.1: Matkailijan paikannukseen ja paikkatietoon liittyvä käyttökonteksti 2.1 Paikannusteknologia Mobiililaitteen käyttäjä voi määritellä sijaintinsa ulkotiloissa suhteellisen tarkasti satelliitteihin perustuvan paikannuksen avulla. Matkapuhelinverkon tukiasemiin perustuva paikannus täydennettynä alueen muista radioverkoista saatavalla paikannustiedolla mahdollistaa paikannuksen etenkin tiheämmin asutuilla alueilla. 2.1.1 Matkapuhelinverkkoon perustuva paikannus Matkapuhelinverkossa olevan mobiililaitteen summittainen sijainti saadaan selvittämällä, mihin tukiasemaan puhelin on sillä hetkellä yhteydessä. Jos puhelimesta on samanaikainen radioyhteys useisiin tukiasemiin, voidaan sijaintitiedon saamiseksi laskea mobiililaitteen etäisyys kantavuusalueella oleviin tukiasemiin. Kaupunkialueilla tukiasemaperusteisessa paikannuksessa voidaan päästä noin 50 metrin tarkkuuteen. Harvaanasutuilla alueilla, joissa verkon tukiasematiheys on pienempi, paikannuksen epätarkkuus voi olla useita kilometrejä. Tukiasemapaikannuksen etuna on se, että se ei vaadi 3
LUKU 2. PAIKKATIETOON LIITTYVÄ TEKNOLOGIA 4 matkapuhelimelta mitään erityisominaisuuksia, vaan sama paikannustarkkuus on saavutettavissa kaikilla matkapuhelimilla. (Kaasinen, 2003) 2.1.2 Satelliittipaikannus Tunnetuin ja näihin päiviin saakka ainoa maailmanlaajuisesti kattava satelliittipaikannusjärjestelmä (engl. Global Navigation Satellite System, GNSS) on Yhdysvaltain kehittämä ja ylläpitämä GPS-järjestelmä (engl. Global Navigation System), joka otettiin operatiiviseen käyttöön vuonna 1995. Muita GNSS-hankkeita ovat venäläinen GLONASS (venäjäksi GLObalnaja NAvigatsionnaja Sputnikovaja Sistema) sekä eurooppalainen Galileo. Vuoden 2011 lokakuussa tehdyn satelliittilaukaisun jälkeen myös GLONASS-järjestelmä saavutti GPS:n ohella maailmanlaajuisen kattavuuden (Interfax, 2011). Yhteiseurooppalaisen Galileo-paikannusjärjestelmän on arvioitu olevan täydessä tuotantokäytössä aikaisintaan vuonna 2020. (de Selding, 2011; Cojocaru et al., 2009) GPS-järjestelmä, samoin kuin GLONASS, perustuu 24:ään maata kiertävään radiosignaalia lähettävään satelliittiin, joista vähintään viiteen on suora yhteys avoimelta paikalta mistä tahansa kohtaa maapalloa. Laskeakseen sijaintitiedon paikannuslaitteen pitää pystyä vastaanottamaan signaalia vähintään neljästä satelliitista. Pelkästään radiosignaalin kulkunopeuksiin perustuvassa paikannuksessa on useita virhelähteitä ja sen tarkkuus vaihtelee 20 100 m välillä. Paikannuksen tarkkuutta ja luotettavuutta voidaan kuitenkin parantaa useilla menetelmillä. Differentiaalinen GPS (engl. Differential Global Positioning System, DGPS) on menetelmä, jossa etenkin ilmakehän ominaisuuksien paikallisista vaihteluista aiheutunutta virhettä voidaan vähentää alueellisilta tukiasemilta saatavilla korjaustiedoilla. Avustetussa GPS-paikannuksessa (engl. Assisted GPS, A-GPS) parannetaan paikannuksen tarkkuutta ja nopeutta yhdistämällä satelliittiperustainen paikannustieto yleensä matkapuhelinverkosta saatavaan sijainti- ja korjausdataan. (Bajaj et al., 2002) Matkapuhelimen kiihtyvyysantureiden ja kompassin antaman liike- ja suuntatiedon perusteella (engl. Inertial Navigation System, INS) voidaan laskea sijainnin muutos, vaikka yhteys satelliitteihin olisi hetkellisesti menetettykin rakennusten tai kasvillisuuden aiheuttaman katveen takia (Gao ja Lachapelle, 2007). Satelliittipaikannuksen nopeuden ja tarkkuuden kannalta on ratkaisevaa miten nopeasti paikanninlaite pystyy vastaanottamaan radiosignaalin riittävästä määrästä satelliitteja. Pohjoisilla leveyspiireillä venäläisen GLONASS-järjestelmän satelliittien radat ovat korkeammalla käyttäjän horisontista katsottuna kuin GPS-järjestelmän satelliittien radat. Korkeamman lentoradan ansiosta satelliittien lähettämä signaali on paremmin vastaanotettavissa paikannuslaitteelle. GLONASS-sateliittiverkon täydennyttyä esimerkiksi Ruotsin maanmittauslaitos on alkanut käyttää GLONASS-satelliittien signaalia kansallisen paikannustiedon tuottamisessa GPS-signaalien sijaan. Paikannukseen vaikuttavat paikalliset maastoesteet, kuten alueen maaston muodot, puut ja rakennukset, jotka voivat estää paikannukseen tarvittavien radiosignaalien vastaanoton. Korkeamman lentoradan ansiosta todennäköisyys maastoesteiden aiheuttamille häiriöille on
LUKU 2. PAIKKATIETOON LIITTYVÄ TEKNOLOGIA 5 pienempi GLONASS-järjestelmää käytettäessä. (Bryanski, 2011; Segan, 2011) Mikäli satelliittipaikannin pystyy vastaanottamaan paikannussignaalia useampien kuin yhden paikannusjärjestelmän satelliiteilta, paikannustieto saadaan nopeammin kuin yhteen paikannusjärjestelmään nojauduttaessa. Ensimmäiset kuluttajille suunnatut sekä GPS- että GLONASS-satelliittien signaalia hyödyntävät paikannuslaitteet ja älypuhelimet on julkaistu vuoden 2011 aikana. Ne mahdollistavat pelkkää GPS-signaalia hyödyntäviä laitteita nopeamman ja tarkemman paikannukseen. (ST-Ericsson, 2011; Segan, 2011) 2.1.3 Muita paikannusteknologioita Asutuilla alueilla paikannustarkkuutta voidaan parantaa hyödyntämällä tietoa mobiililaitteen kantavuusalueella olevista langattomista lähiverkoista ja Bluetooth-laitteista (LaMarca et al., 2005). Luonnossa liikuttaessa näitä lyhyen kantaman radioverkkoja on kuitenkin harvoin riittävän lähellä, joten näiden merkitys paikannuksessa on tämän työn aihealueella marginaalinen. 2.2 Paikkatiedon hallinnan ohjelmistoarkkitehtuuri Open Geospatial Consortium (OGC) on kansainvälinen yritysten, viranomaistahojen ja yliopistojen muodostama standardointiyhteisö (The Open Geospatial Consortium, 2010). Se on määrittänyt paikkatietoon ja paikkasidonnaisten palveluiden toteuttamiseen liittyviä tietojärjestelmien rajapintastandardeja. Web Map Service -standardi (WMS) määrittää palvelurajapinnan, joka on tarkoitettu paikkatietoaineistosta luotujen karttakuvien katseluun. Web Feature Service -palvelurajapintastandardi (WFS) määrittää vektorimuotoisen paikkatietoaineiston siirtotavan tietoverkossa. WFS-standardi sisältää lukuoperaatioiden lisäksi myös operaatioita, joiden avulla voidaan päivittää palveluntarjoajan paikkatietoaineistoa. Web Coverage Service -määrittely (WCS) kuvaa hilamuotoisen paikkatietoaineiston, kuten korkeusmallien, tiedonsiirrossa käytettävät tekniset rajapinnat. Kaaviokuvassa 2.2 on kuvattu erilaisten paikkatietoaineistojen Kuva 2.2: Rajapintastandardit käyttäjän sovelluksen ja paikkatietoaineistojen välisessä kommunikaatiossa.(vehkaperä, 2009) siirtäminen käyttäjän sovelluksen käyttöön edellä mainittujen rajapintastandardien avulla. (Vehkaperä, 2009)
3 Websovelluskehitys mobiiliympäristössä Tässä luvussa tarkastellaan sellaisia mobiilisovelluksen kehittämiseen liittyviä standardeja ja ohjelmistokehitysympäristöjä, jotka ovat erityisen merkityksellisiä tämän työn webteknologioihin perustuvan prototyyppisovelluksen kehittämisessä. 3.1 Ohjelmointiympäristön valinta Mobiilisovelluksen ohjelmointiympäristön valinnassa on kaksi vaihtoehtoista lähestymistapaa. Ensinnäkin sovellus voidaan toteuttaa HTML5-standardin ominaisuuksia hyödyntävänä websovelluksena, joka on optimoitu käytettäväksi mobiililaitteiden webselaimilla. Toisena vaihtoehtona on toteuttaa mobiililaitteen käyttöjärjestelmäkohtaisilla ohjelmontityökaluilla niin sanottu natiivisovellus (engl. native application). HTML5-sovelluksen toiminnot ohjelmoidaan pääasiallisesti JavaScript-ohjelmointikielellä, kun natiivisovelluksissa käytetään käyttöjärjestelmästä riippuen muun muassa Java-ohjelmointikieltä sekä C-kieleen pohjautuvia ohjelmointikieliä(charland ja Leroux, 2011). Käyttöjärjestelmäriippuvaisen natiivisovelluksen etuna on muun muassa mahdollisuus hyödyntää täysipainoisesti mobiililaitteiston ominaisuuksia, kuten kompassin ja kiihtyvyysantureiden tarjoamia ohjelmointirajapintoja sekä valmistajien tarjoamien ohjelmointiympäristöjen vakiintuminen. Natiivisovelluksen kehittämiseen kuhunkin tuettavaan käyttöjärjestelmäympäristöön tarvitaan kuitenkin erikoisosaamista vaativaa kehitystyötä, eikä yhteen ympäristöön ohjelmoitua sovellusta voi suoraan siirtää helposti toiseen käyttöjärjestelmäympäristöön (Charland ja Leroux, 2011). Tutkimuksen kohteena olleen sovelluksen mahdollisen käyttäjäjoukon arvioidaan olevan palvelun luonteesta johtuen varsin rajallinen, minkä takia eri käyttöympäristöihin tuotettujen sovellusversioiden kehittäminen ja tukeminen sovelluksen mahdollisessa kaupallistamisvaiheessa arvioitiin taloudellisesti ylivoimaiseksi. Tämän takia tässä luvussa keskitytään tarkastelemaan HTML5-standardiin tukeutuvia sovelluskehitystekniikoita. 3.2 HTML5 HTML5 on World Wide Webin keskeisen kuvauskielen HTML:n (engl. Hypertext Markup Language) kehitteillä oleva versio, joka koostuu useista eri kehitysvaiheissa olevista osastandardeista. HTML5:ssa on standardoitu ominaisuuksia, joiden toteuttamiseen on aikaisemmin vaadittu laitteisto- tai käyttöjärjestelmäriippuvaisia ohjelmakirjastoja. World Wide Web Consortiumin (W3C) johtama HTML:n standardointityö mahdollistaa aikaisemmin käyttöjärjestelmäkohtaisia kehitystyökaluja ja ohjelmointikieliä vaatineiden ominaisuuksien, kuten 6
LUKU 3. WEBSOVELLUSKEHITYS MOBIILIYMPÄRISTÖSSÄ 7 multimedia, laitteiston paikantaminen ja sovelluksen paikallinen tietovarasto, toteuttamisen laitteistoriippumattomalla ohjelmistokehitysympäristöllä. Sovellusten kehittämisen kannalta tämä mahdollistaa kustannussäästöt, kun yksittäinen sovellusversio voidaan jakaa useaan eri mobiilikäyttöjärjestelmiin, joita ovat esimerkiksi Apple ios, Android ja Windows Phone, eikä sovelluksesta tarvitse kehittää erillisiä käyttöjärjestelmäkohtaisia versioita. On arvioitu, että jo seuraavan kahden vuoden aikana HTML5:een perustuvat mobiilisovellukset tulevat merkittävältä osalta korvaamaan käyttöjärjestelmäkohtaisilla työkaluilla kehitetyt natiivisovellukset. Vaikka HTML5-standardia ei olekaan vielä kokonaisuudessaan hyväksytty, monet uusimmista selainohjelmista tukevat ainakin osittain HTML5:ssä jo määriteltyjä toiminnallisuuksia. Koska selainohjelmien tarjoama tuki eri toiminnallisuuksille vaihtelee, joudutaan sovellusta kehitettäessä huomioimaan millä selaimilla sovelluksen halutaan toimivan. Seuraavassa esitellään tämän tutkimuksen kannalta olennaisimpia HTML5-osastandardeja. (Hickson, 2011a; Hartmann, 2011; Marshall, 2011) 3.3 JavaScript JavaScript on webympäristöön suunniteltu kevyt oliopohjainen skriptikieli, jota käytetään webpohjaisten järjestelmien päätelaitteissa olevan toiminnallisuuden toteuttamiseen. JavaScript muodostuu kuvan 3.1 mukaisesti kolmesta osasta, jotka ovat ECMAScript, DOM (Document Object Model) sekä BOM (Browser Object Model). ECMAScript perustuu Ecma Internationalin standardiin (Ecma, 1999). DOM on W3C:n standardi, joka määrittelee alusta- ja kieliriippumattoman ohjelmointirajapinnan, jonka avulla ohjelmat ja skriptit voivat dynaamisesti lukea ja päivittää webdokumenttien sisältöä, rakennetta ja tyylitietoa (W3C, 2011). Browser Object Model kuvaa nimensä mukaan selainikkunan, kehysten sekä kaikkien selainikkunaa hallitsevien JavaScript-laajennusten, kuten keksien (engl. cookie) ja location-objektin, hallintarajapinnan. ECMAScriptistä ja DOM:sta poiketen BOM:lia ei ole standardoitu, vaan sen toteutus vaihtelee eri selainympäristöissä. (Zakas, 2011) Kuva 3.1: JavaScriptin osat (Zakas, 2011)
LUKU 3. WEBSOVELLUSKEHITYS MOBIILIYMPÄRISTÖSSÄ 8 3.4 Ajax Ajax (engl. Asynchronous JavaScript And XML) on joukko websovelluskehityksessä käytettäviä tekniikoita, joiden avulla websovelluksista voi tehdä vuorovaikutteisempia. Perinteisessä websovelluksessa websivu ladataan kokonaisuudessaan palvelimelta jokaisen käyttäjän tekemän palvelimelta tietoa vaativan muutoksen tai haun jälkeen. Ajax-tekniikoiden avulla voi websivu voi vaihtaa tietoa palvelimen kanssa taustatoimintona samanaikaisesti kun käyttäjä on käyttämässä sivua. Näin voidaan parantaa websovelluksen vuorovaikutteisuutta, nopeutta ja käyttäjäkokemusta. (Garrett et al., 2005) 3.5 REST - the Representational State Transfer REST (Representational State Transfer) on Fieldingin (2000) vuonna 2000 esittelemä arkkitehtuurimalli verkossa olevien laitteiden ohjelmointirajapintojen toteuttamiseen. Viitteellisenä arkkitehtuurimallina REST-mallilla ei ole standardin asemaa vaan se voidaan nähdä joukkona suunnitteluperiaatteita rajapintojen toteuttamiseksi. REST-malli mahdollistaa monia muita vastaavia arkkitehtuurimalleja, kuten Web Services tai RPC, yksinkertaisemman tavan palvelukutsujen toteuttamiseen. REST-mallin mukaiset palvelukutsut käyttävät tiedonsiirrossa World Wide Webin perustana olevaa HTTP-protokollaa ja eivätkä siksi tarvitse erillisiä määrityksiä esimerkiksi palomuureihin. REST-palvelukutsuja voidaan tehdä sovellusten välillä riippumatta niiden toteutukseen käytetystä ohjelmointikielestä tai ja laitteiston käyttöjärjestelmästä. REST-malli ei määrittele tietoturvaan, kuten käyttäjätunnistukseen tai tietoliikenteen salaukseen, liittyviä kysymyksiin,. Tyypillisesti ei-avoimet REST-palvelut käyttävät salauksessa HTTPS-protokollaa ja perustavat tunnistuksen käyttäjätunnukseen ja salasanaan.(elkstein, 2008) 3.6 Geolocation API Geolocation API on W3C:n standardi, joka määrittää ohjelmointirajapinnan (engl. Application Programming Interface, API) mobiililaitteen sijaintitiedon selvittämiseksi. Rajapinnan kautta webselaimessa toimiva sovellus voi kysyä mobiililaitteen sijaintia laitteen käyttöjärjestelmän tarjoamalta paikannuspalvelulta. Sijaintitieto palautetaan WGS84-järjestelmän mukaisina koordinaatteina sekä korkeustietona merenpinnasta. WGS84 (World Geodetic System 1984) on Yhdysvaltain puolustushallinnon karttalaitoksen määrittelemä koordinaattijärjestelmä ja koordinaatisto. Palautetun sijaintitiedon yhteydessä rajapinta voi myös palauttaa arvion sijainti- ja korkeustiedon tarkkuudesta. Vaikka Geolocation API ei ota kantaa paikannusmenetelmään, tarkkuustiedon avulla voidaan kuitenkin tehdä päätelmiä tiedon tarkkuudesta ja paikannusmenetelmästä. Esimerkiksi maasto-olosuhteissa alle sadan metrin paikannustarkkuuteen päästään käytännössä vain satelliittipaikannuksen avulla. Rajapinnan sijaintikyselyssä voidaan määritellä tarvitaanko laitteen sijaintiedosta mahdollisimman tarkka vai riittääkö sovellukselle karkeamman tason sijaintitieto. Karkean tason sijaintitieto voi perustua esimerkiksi matkapuhelinverkon tarjoamaan sijaintiin, joka on
LUKU 3. WEBSOVELLUSKEHITYS MOBIILIYMPÄRISTÖSSÄ 9 useimmiten palautettavissa sovellukselle nopeammin kuin satelliittipaikannukseen perustuva sijainti. Verkkopaikannusta käytettäessä sovelluksen virrankulutus jää pienemmäksi, koska laitteen satelliittipaikannustoiminnallisuutta ei tarvitse aktivoida. (Popescu ja Block, 2011) 3.7 Offline-sovellukset HTML5:n sisältämät ominaisuudet mahdollistavat sellaisten sovellusten teon, joita voidaan käyttää ilman aktiivista internetyhteyttä. Tämän tutkimuksen kannalta tärkeimmät näistä uusista ominaisuuksista ovat sovelluksen käyttämien tiedostojen ennakkolatauksen mahdollistava Application Cache API ja rakenteellisen tiedon paikallisen tallentamisen mahdollistava Web Storage API. Application Cache on websovelluksen paikallinen välimuistimekanismi, jonka avulla sovellus voi käyttää ennalta ladattuja resursseja, kuten tiedostoja, silloin kun sovellus on offline-tilassa eli käytössä ei ole aktiivista internetyhteyttä. Ladattavat resurssit määritellään erillisessä luettelotiedostossa (eng. manifest file), jossa kuvataan, mitkä resurssit ladataan ennakolta offline-tilassa käytettäväksi, mitä resursseja voidaan käyttää vain kun internetyhteys on aktiivinen ja mitkä paikalliset resurssit ladataan kun internetyhteys ei ole aktiivinen. Näitä kolmea lataustyyppiä käyttämällä voidaan toteuttaa kokonaan offline-tilassa toimivia sovelluksia sekä sovelluksia, joissa osa sisällöstä päivittyy aktiivisen internetyhteyden kautta muun sisällön tullessa sovelluksen välimuistista. (Kesteren ja Hickson, 2008) Web Storage API on W3C:n määrittelemä ohjelmointirajapintastandardi, jonka avulla websivustot voivat tallentaa rakenteellista dataa, tässä tapauksessa avain-arvo-pareja, selaimen muistiin. Rajapinnan käytöllä voidaan korvata keksien (engl. cookie) käyttö ja välttää näin keksien käytön suurimmat heikkoudet: neljän kilotavun kokorajoitus ja keksien sisällön automaattinen lähettäminen palvelimelle, mikä kasvattaa sovelluksen aiheuttamaa verkkoliikennettä. Web Storage API:n kautta tiedot tallennetaan suoraan selaimen hallitsemaan muistiin eikä verkkoyhteyttä tarvita. (Hickson, 2011b)
4 Tutkimusmenetelmät Tässä tutkimuksessa käytetään konstruktiivisen tutkimusotteen määrittelemää työtapaa, jossa aikaisempaan tutkimustietoon nojautuen kehitetään ratkaisumalli käytännössä esiintyvään ongelmaan. Ratkaisukonstruktion hyvyyttä testataan tässä tutkimuksessa pääasiassa keräämällä käyttäjätietoa eri käyttäjätutkimusmenetelmillä, muun muassa haastatteluilla ja kyselyillä. 4.1 Konstruktiivinen tutkimusote Lukka ja Tuomela (1994) ovatkäsitelleetkonstruktiivisentutkimusotteenmukaista lähestymistapaa erityisesti liiketaloudellisessa tutkimuksessa. Konstruktiivisessa tutkimuksessa tieteellisen tutkimuksen ja kohdealueen käytännön välillä on kiinteä vuorovaikutus ja siinä pyritään käytännössä toimivaan ratkaisuun. Konstruktiivisen tutkimusotteen mukaisessa tutkimuksessa lähdetään liikkeelle tosielämässä havaitusta ongelmasta ja tutkimuksella pyritään kehittämään tähän ongelmaan ratkaisukonstruktio. Tämän jälkeen kehitettyä ratkaisumallia testataan käytännössä, minkä jälkeen tulokset kytketään aikaisempaan tietämykseen samalla pohtien mallin soveltamisalueen laajuutta. Konstruktiivisen tutkimusotteen peruselementit on esitetty kuvassa 4.1. Kuva 4.1: Konstruktiivisen tutkimuksen peruselementit (Lukka ja Tuomela, 1994) Itse ratkaisukonstruktion, tässä tutkimuksessa prototyyppisovelluksen, kehittely on Lukan mukaan tutkimustavan kriittisin vaihe. Prosessissa edetään yleensä useiden iteraatioiden ja pilottikokeilujen jälkeen ratkaisun todelliseen koetteluvaiheeseen. Konstruktiivista tutkimusprosessia ei voi pitää onnistuneena, mikäli tutkimus ei etene koetteluvaiheeseen saakka. (Lukka ja Tuomela, 1994) Konstruktion toimivuuden koetteluvaiheessa testataan tutkimusprosessin yleistä onnistuneisuutta. Ratkaisukonstruktion käytännön toimivuuden keskeisiksi tunnusmerkeiksi Lukka nimeää relevanttiuden, yksinkertaisuuden ja helppokäyttöisyyden. Koetteluvaiheessa testataan sekä itse ratkaisukonstruktiota että prosessia, jolla ratkaisua sovelletaan käytäntöön.(lukka ja Tuomela, 1994) 10
LUKU 4. TUTKIMUSMENETELMÄT 11 Konstruktiivisessa tutkimusotteessa on olennaista niin sanottu pragmaattinen totuuskäsite. Sen mukaan väite on tosi, mikäli se tai sen seuraus toimii käytännössä ja tutkimusotteen tuottama "totuus"selviää käytännön markkina- ja käyttäjätesteissä. Tutkimusprosessin onnistuessa on tietämykseen liitettävissä uusi mahdollinen ratkaisumalli. Samaten ratkaisumallin käyttöönottoon liittyvät havainnot saattavat luoda uutta tietämystä aihealueesta. Toisaalta myös kehitetyn konstruktion toimimattomuus käytännössä tuo uutta tietoa ratkaisumallista ja saattaa kyseenalaistaa olemassa olevia uskomuksia tai olettamuksia. (Lukka ja Tuomela, 1994) Uuden tuotteen onnistuminen nojaa Cooperin (1999) esittelemän,alunperin Keeleyn kehittämän, tuotemallin mukaan kolmeen perustekijään: tuotteen teknisiin ominaisuuksiin, taloudelliseen elinkelpoisuuteen sekä tuotteen haluttavuuteen käyttäjän näkökulmasta. Keeleyn tuotemalli on esitetty kuvassa 4.2. Kuva 4.2: Onnistuneen tuotteen peruskomponentit (Cooper, 1999, s. 109) Teknisellä osaamisella tarkoitetaan kyvykkyyttä suunnitella tuotteeseen teknisiä ominaisuuksia ja saada tuotteen sisäiset toiminnot toimimaan tehokkaasti. Elinkelpoisuudella tarkoitetaan tuotteen tai palvelun kaupallista menestymistä sen tuottaman myynnin, liikevoiton tai muiden taloudellisten mittareiden avulla arvioituna. Keeleyn mukaan tuotteen pitempiaikaisen menestyksen mahdollistava haluttavuus syntyy suunnitteluprosessissa, jossa suunnittelijat tunnistavat, minkälainen tuote saa käyttäjät onnellisiksi ja tyytyväisiksi. Tässä tutkimuksessa tarkastellaan kehitettävää ratkaisua pääasiallisesti prototypoitavan ratkaisun teknisten ominaisuuksien sekä tuotteen hyödyllisyyden ja haluttavuuden näkökulmasta jättäen ratkaisun liiketaloudellinen tarkastelu mahdolliseen myöhempään arviointivaiheeseen. Keen et al. (2001, s.31-35)arvioimobiilisovelluksienmenestymismahdollisuuksia Braudelin säännöksi nimeämällään arviointikriteerillä, jonka taustalla on ranskalaisen taloushistorioitsija Fernand Braudelin kapitalismin ja taloudellisten rakenteiden muutosta tarkastelevat teokset. Freedom becomes value when it changes the limits of the possible in the structures of everyday live.
LUKU 4. TUTKIMUSMENETELMÄT 12 Braudelin säännön mukaan vapaus luo uutta arvoa silloin, kun se mahdollistaa arkielämän järjestämisen tavalla, joka ei aikaisemmin ole ollut mahdollista. Mobiiliteknologian avulla voidaan tarjota käyttäjille uusia palveluita, joiden käytössä on aikaisemmin käytettyjä palveluita vähemmän esimerkiksi aikaan tai paikkaan liittyviä rajoituksia. Esimerkiksi matkapuhelimien avulla ihmisillä on mahdollisuus ottaa yhteyttä toisiin miltei rajattomasti verrattuna aikaan, jolloin langattomien verkkojen palvelut eivät olleet laajasti kuluttajien saatavissa. Vapaus ei Keenin mukaan kuitenkaan itsessään luo arvoa, vaan sillä on ainoastaan välinearvoa. Braudelin säännön mukaan tuotteen tai palvelun on menestyäkseen tuotettava ihmiselle sellaista vapautta, joka mahdollistaa arjen järjestämisen aikaisempaa mielekkäämmällä tavalla. Davisin (1989) mukaan käyttäjän mieltämistä tietojärjestelmän ominaisuuksista järjestelmän käytön helppous ja hyödyllisyys ovat tärkeimmät järjestelmän omaksumista ja käyttöönottoa selittävät tekijät. Carlsson et al. (2005) lisäävät mobiilipalveluiden käyttöönottoa mallintaessaan selittävien tekijöiden joukkoon käytön tuoman nautinnon ja palvelun luomat uudet mahdollisuudet. Tämän mallin mukaiset käyttöönottoon vaikuttavat tekijät on esitetty kuvassa 4.3. Kuva 4.3: Tuotteen käyttöönottoon vaikuttavat tekijät (Carlsson et al., 2005) 4.2 Ratkaisumallin testaustavat Tässä työssä käytetään useita eri tiedonkeruumenetelmiä ratkaisumallin hyvyyden testaamiseksi. Järjestelmän kehittäjä testaa ratkaisua iteratiivisen kehitysprosessin aikana kenttätestauksella. Käyttäjien mielipiteitä ja ideoita kartoitetaan teemahaastatteluilla, kyselyllä ja ryhmäkeskusteluilla. Käyttäjien tapaa käyttää sovellusta tutkitaan käytöstä kerättyä lokitietoa analysoimalla. 4.2.1 Kenttätestaus Kenttätestauksella tarkoitetaan tässä työssä prototyyppisovelluksen järjestelmätestausta todellisia käyttötilanteita muistuttavissa olosuhteissa, käytännössä ulkona. Kenttätestauksen voidaan katsoa kuuluvan konstruktiivisen tutkimusotteen mukaisessa mallissa osittain ratkaisumallin kehittämisvaiheeseen,
LUKU 4. TUTKIMUSMENETELMÄT 13 osittain mallin koetteluvaiheeseen. Kenttätestauksella tutkitaan erityisesti sellaisia sovelluksen ominaisuuksia, joita ei voida mielekkäästi testata toimisto-olosuhteissa. Koska prototyyppisovelluksen toimintalogiikka nojasi vahvasti paikannukseen ja käyttäjän sijaintiin liittyvään kontekstiin sekä sisätiloista poikkeavaan käyttöympäristöön, joita toimisto-olosuhteissa ei voi helposti simuloida, oli maastossa ja yleensä ulkotiloissa tapahtuvalla testauksella merkittävä rooli. Kenttätestauksen käytännön toteutuksesta ja tuloksista tässä tutkimuksessa kerrotaan alaluvussa 9.1. 4.2.2 Teemahaastattelu Teemahaastattelussa haastattelija kerää haastateltavalta tietoa kysymysrunkoa seuraten, mutta samalla vastauksiin mukautuen ja tehden tarkentavia kysymyksiä. Teemahaastattelut sopivat käyttäjän toiminnan selvittämiseen tilanteessa, jossa haastattelija tietää jo jotain käyttäjän toiminnasta, muttei ole varma, tietääkö hän esimerkiksi, mikä kaikki käyttäjän toiminnassa on tuotesuunnittelun kannalta merkittävää. Kysymysten avoin muoto mahdollistaa uusien ja yllättävienkin asioiden esiintulon. Haastattelutilanne puolestaan sallii esiin tulleisiin asioihin syventymisen ja palaamisen. Teemahaastatteluja tehdään usein kaksi tai useampia kierroksia saman haastateltavan kanssa, jolloin esimerkiksi kuukauden päästä voidaan kysellä asioita, joihin ei ensimmäisessä haastattelussa osattu kiinnittää huomiota. (Hyysalo, 2009, s. 131) 4.2.3 Kysely Kysely (engl. survey) on kirjallisessa muodossa oleva haastattelu, joka voidaan esimerkiksi postittaa haastateltavalle, laittaa webiin tai käydä haastateltavan ja haastattelijan kanssa kohta kohdalta läpi. Kyselyitä käytetään yleisesti silloin, kun pyritään keräämään tietoa suurelta joukolta ihmisiä. Lomakkeiden nopean täyttämisen ja ennen kaikkea tehokkaan analysoinnin ja tilastollisten menetelmien käytön mahdollistamiseksi kyselyt ovat yleensä muodoltaan strukturoituja. Mikäli kyselyn otos on suppea, vastausprosentti jää pieneksi tai vastaajajoukko poikkeaa tavoitellusta kohderyhmästä, voi kyselyn analysointi tuottaa näennäistilastoja, joissa tulosten eksaktit lukemat eivät kuvaa tutkittavaa ilmiötä, vaan antavat liian positiivisen kuvan tutkimuksen luotettavuudesta. (Hyysalo, 2009, s. 131) Vaikka laajalla, lukuisista kysymyksistä muodostuvalla kyselyllä voidaan periaatteessa kerätä haastateltavalta enemmän tietoa kuin suppealla kyselyllä, on kyselyä suunniteltaessa muistettava, että mitä laajemmaksi kysely muodostuu, sitä harvempi haastateltava vaivautuu siihen vastaamaan. Kyselyn laajuus onkin kompromissi kysymysten määrän ja oletetun vastausprosentin välillä. (Hyysalo, 2009, s.131) 4.2.4 Ryhmäkeskustelut Ryhmäkeskustelussa (engl. focus-group) kootaan yleensä kuudesta yhdeksään henkilöä keskustelemaan noin kahdeksi tunniksi esimerkiksi uudesta tuote- tai palvelukonseptista ja tuomaan esille siihen liittyviä käsityksiä ja mielipiteitä. Keskustelun ohjaajan eli moderaattorin (engl. moderator) tehtävänä on pitää
LUKU 4. TUTKIMUSMENETELMÄT 14 keskustelu suunnitellun teeman ympärillä kuitenkin niin, että osallistujat mieltävät keskustelutilanteen suhteellisen vapaamuotoisena ja epämuodollisena. (Nielsen, 1993, s. 214) Moderaattorin lisäksi ryhmäkeskusteluissa on yleensä toinen henkilö tekemässä muistiinpanoja ja tallenteita (Hyysalo, 2009, s. 133). Ryhmäkeskustelujen avulla saadaan esille osallistujien mielikuvia, mieltymyksiä, perusteluita ja vertailuja eri tuotteista ja niiden ominaisuuksista. Suurimpana riskinä tuloksekkaalle ryhmäkeskustelulle on se, että keskustelu lähtee toistamaan asiasta vallitsevia yleisiä puhe- ja jäsennystapoja jääden löyhäksi mielipiteenvaihdoksi väljästi määritellystä aiheesta. Tätä riskiä voidaan pienentää hyvällä etukäteen laaditulla keskustelurungolla ja -ohjeella sekä tuomalla keskusteluun selkeitä kuvauksia tai malleja tuotteista, joista halutaan keskustella. (Hyysalo, 2009, s. 133) 4.2.5 Käyttölokin kerääminen Käyttäjän toimintojen tallentamista myöhempää analysointia varten kutsutaan käyttölokin keräämiseksi (engl. activity logging). Lokitietoa voidaan kerätä manuaalisesti tai automaattisesti tutkittavaan järjestelmään liitetyn tiedonkeruutoiminnon avulla. Automaattinen keräystapa aiheuttaa käyttäjälle manuaalista tapaa vähemmän häiriötä, vaikka sekin voi vaikuttaa ainakin alussa käyttäjän toimintaan, sillä käyttäjälle on tutkimuseettisistä syistä kerrottava lokitiedon keräämisestä (Faulkner, 2000, s. 41). Tässä tutkimuksessa käsitellään ainoastaan käyttölokin automaattista keräämistä. Käyttölokin avulla pystytään kirjaamaan käyttäjän toimenpiteet sellaisenaan ja käyttödataa voidaan tallentaa suureltakin käyttäjäjoukolta eri käyttötilanteissa. Lokiaineistoa analysoimalla voidaan esimerkiksi tunnistaa järjestelmän harvoin käytetyt toiminnot. Näin tunnistettuja toimintoja voidaan kehittää paremmiksi ja helpommin saavutettaviksi tai vaihtoehtoisesti karsia tarpeettomia samalla järjestelmää yksinkertaistaen. Vaikka käyttölokin avulla voidaan tehokkaasti selvittää, mitä käyttäjä on tehnyt, ei kuitenkaan sitä, miksi hän tehnyt jonkin toiminnon tai jättänyt toisen toiminnon tekemättä. Kokonaisvaltaisemman analyysin tekemiseksi käyttölokin tietoa voidaan yhdistää muilla menetelmillä, kuten haastatteluilla, kerättyyn aineistoon. (Nielsen, 1993, s. 216-220)
5 Aikaisempi tutkimus Tässä luvussa tarkastellaan luontomatkailijan käyttäjätarpeista ja mobiilikarttojen suunnittelusta tehtyä aikaisempaa tutkimustyötä sekä kuvataan eri tutkimushankkeista ja niihin liittyvistä prototyyppisovelluksista saatuja kokemuksia. 5.1 Luontomatkailijan käyttötarpeet Tässä alaluvussa käsitellään niitä tarpeita ja toiveita, joita käyttäjät asettavat mobiililaitteilla toimiville karttasovelluksille. Suurin osa esitetyistä tutkimustuloksista on saatu selvittämällä suomalaisten retkeilijöiden mobiilisovelluksen ominaisuuksiin liittyviä toiveita. Vaittinen et al. (2008) nimeävätkäyttäjienkannaltatärkeimmäksi mobiilikarttasovelluksen ominaisuudeksi oman sijainnin näyttämisen. Muita aktiivisten retkeilijöiden tärkeiksi katsomia ominaisuuksia olivat kuljetun reitin tallentaminen, oman reitin suunnittelu sekä mielenkiintoisten pisteiden lisääminen karttaan. Kartan käyttöön tottuneet aktiiviretkeilijät toivoivat myös mahdollisuutta muokata mobiilikartan näkymää valitsemalla karttatasoja (engl. layer) tilanteen ja oman mielenkiintonsa mukaan. Kuva 5.1: Tunnistetut käyttäjätarpeet yhdeksään temaattiseen ryhmään ja ajalliseen ulottuvuuteen sijoitettuna.(nivala et al., 2009) 15
LUKU 5. AIKAISEMPI TUTKIMUS 16 Nivala et al. (2009) erittelevätkäyttäjätarpeetyhdeksäänosittainpäällekkäiseen luokkaan, jotka on esitetty kuvassa 5.1. Näistä tämän tutkimuksen kannalta tärkeimpiä ovat lisätietojen tarjoaminen alueesta, retkeilijöiden sijaintiin liittyvät käyttäjätarpeet sekä kokemusten jakamiseen ja tallentamiseen liittyvät toiminnot. 5.1.1 Retken suunnittelu ja kohteen löytäminen Retkeä suunnitellessa kerätään tietoa useista eri lähteistä, kuten kirjoista, kartoista, lehdistä ja internetsivuilta. Joillekin retkeilijöille toisten alueella liikkuneiden retkeilijöiden aikaisemmat kokemukset ovat tärkeitä retkikohdetta ja reittiä suunnitellessa. Ulkoilualueen säätila ja sen retkeilyajalle kohdistuva sääennuste ovat myös osa suunnittelussa käytettyä tietoa. Päästäkseen maastoretken varsinaiseen aloituspaikkaan kävijät tarvitsevat tietoa julkisten kulkuneuvojen reiteistä ja aikatauluista. Yksityisautoilla kulkevat kaipaavat toisaalta tietoa ajoreiteistä, pysäköintipaikoista sekä etenkin talviaikaan teiden senhetkisestä kunnosta. Pidemmillä retkillä, joissa maastoonlähtöpaikka on eri kuin paluupaikka, tarvitaan usein tietoa myös paikallisista taksi- tai autonsiirtopalveluista. Itse maastossa tapahtuvan retken suunnittelun avuksi tutkimukseen osallistuneet toivoivat palvelua, joka voisi automaattisesti ehdottaa käyttäjän toiveiden perusteella valittua retkeilyreittiä. Reittien kulkukelpoisuudesta ja sopivuudesta erityisryhmille, esimerkiksi vammaisille tai lastenvaunujen kanssa kulkeville perheille, toivottiin tietoa jo retken suunnitteluvaiheessa. (Nivala et al., 2009) 5.1.2 Sijaintitieto ja turvallisuus Retkeilijän oman sijainnin tunnistaminen ja maastossa suunnistamisen tukeminen on ilmeisimpiä paikannuksen käyttötarpeita. Joissakin tapauksissa retkeilijät toivoivat saavansa tietoa myös muiden samalla alueella olevien kulkijoiden sijainnista. Enimmäkseen tätä tietoa haluttiin, jotta voitaisiin välttää ruuhkaisiksi koettuja tilanteita mökeillä, reiteillä ja pysäköintialueilla. Toisaalta hätätilanteessa muiden retkeilijöiden sijainnin tunteminen ja mahdollisuus heiltä saatavaan apuun koettiin merkittäväksi turvallisuutta lisääväksi tekijäksi. Suuressa retkeilijäryhmässä liikuttaessa mahdollisuus paikantaa muiden, mahdollisesti pienempiin ryhmiin jakautuneiden, retkeilijöiden sijainti voisi helpottaa osaltaan ryhmän sisäistä koordinointia. (Nivala et al., 2009) Tieto siitä, että poikkeustilanteessa paikannustieto voidaan välittää pelastusviranomaisille luo käyttäjille tärkeää turvallisuuden tunnetta. Kävijätutkimuksessa ehdotettiin myös matkapuhelimessa toimivaan sovellukseen yksinkertaista hälytysnappia, jonka avulla voitaisiin tehdä hälytys ja välittää senhetkinen sijaintitieto suoraan hätäkeskukseen. Lievempien ongelmatilanteiden varalta retkeilijät kokivat tärkeänä mahdollisuuden saada helposti luettavat reittiohjeet, joiden avulla he pääsisivät yksinkertaisimmin ja nopeimmin maastosta pois. (Nivala et al., 2009)
LUKU 5. AIKAISEMPI TUTKIMUS 17 5.1.3 Olosuhteiden seuraaminen Ulkoisten, lähinnä säätilaan liittyvien, olosuhteiden muutosten ennakointi on tärkeä osa retken suunnittelua ja sen kuluessa tapahtuvaa toiminnan arviointia. Myös alueen lumitilanteesta talviretkellä, auringon nousu- ja laskuajoista sekä mahdollisuuksista nähdä revontulia toivottiin tietoa retken kuluessa. (Nivala et al., 2009) Vaittisen suomalaisille retkeilijöille tekemässä käyttäjätutkimuksessa säätietojen merkitys nähtiin vähäisenä (Vaittinen et al., 2008). Ehkä maantieteellisistä olosuhteista johtuen sveitsiläisen kansallispuiston kävijät näkivät säätietojen ja muun turvallisuuteen liittyvän tiedotuksen kaikkein tärkeimpänä retkeilysovelluksen tehtävänä (Edwardes et al., 2003). 5.1.4 Kokemusten tallentaminen ja jakaminen Monet retkeilijät ottavat valokuvia ja videoita sekä kirjoittavat muistiinpanoja retken aikana. Lisäksi monet käyttäjät toivoivat mahdollisuutta tallentaa heitä kiinnostavaa kohdetietoa, kuten marja- ja sienipaikkojen sijainteja tai mielenkiintoisten luontohavaintojen tapahtumapaikkoja. Useissa paikannuslaitteissa oleva reittijälkien ja kohdepisteiden tallennustoiminto voisi toimia apuvälineenä tämän tiedon tallennuksessa. (Nivala et al., 2009) Nykyisin käyttäjät jakavat luontokokemuksensa ja -elämyksensä pääasiassa valokuvien, videoiden sekä multimedia- ja tekstiviestien avulla. Näiden tapojen lisäksi käyttäjät toivoivat myös mahdollisuutta retkikokemuksen jakamiseen muun muassa blogeissa, ääniviesteinä tai sähköpostin välityksellä. Monet käyttäjät haluavat jakaa kulkemansa reitin tiedot ystäviensä ja perheenjäsentensä kanssa. Reittitietojen jakaminen palvelee muita retkeilijöitä antamalla reittivinkkejä retken suunnitteluvaiheessa. Toisaalta retkenaikaisen reitin jakaminen perheenjäsenten kanssa nähtiin turvallisuutta ja turvallisuuden tunnetta edistävänä tekijänä. Käyttäjät eivät kuitenkaan halunneet jakaa kaikkea tietoa kaikille kontakteilleen, vaan toivoivat mahdollisuutta rajoittaa tietojensa näkyvyyttä palvelun eri käyttäjille. (Nivala et al., 2009) 5.1.5 Integroidut ja mukautuvat palvelut Palvelun käyttöliittymä karttanäkymineen voi mukautua aktiviteetin ja käyttötilanteen mukaan, niin että sovellus näyttää kyseiseen tilanteeseen soveltuvan tietosisällön. Myös käyttäjän mahdollisuudet sovelluksen käyttöön eri tilanteissa on hyvä ottaa huomioon. Esimerkiksi kylmässä talvisäässä sovellusta voitaisiin ohjata äänikomennoilla, sillä kosketusnäytön käyttö rukkaset kädessä on hankalaa ja paljain käsin pahimmillaan tuskallista.(nivala et al., 2009) 5.2 Mobiilikarttasovelluksen käyttökontekstit Mobiililaitteet, kuten älypuhelimet, ovat perinteisesti eronneet henkilökohtaiseen käyttöön tarkoitetuista tietokoneista näitä vaatimattomammilla teknisillä ominaisuuksilla. Mobiililaitteessa on tyypillisesti heikompi näytön erottelukyky
LUKU 5. AIKAISEMPI TUTKIMUS 18 (engl. resolution), näytön koko on pienempi, näytön värien määrä on suppeampi ja suorittimen teho on vähäisempi kuin henkilökohtaisissa tietokoneissa. (Hampe ja Paelke, 2005) Taulutietokoneiden(engl. tablets) yleistyminenjaälypuhelinten ominaisuuksien nopea kehittyminen ovat kuitenkin hämärtäneet mobiililaitteiden ja henkilökohtaisten tietokoneiden välistä eroa teknisissä ominaisuuksissa. Hampen ja Paelken (2005) mukaan mobiililaitteiden käyttökonteksti eroaa tyypillisestä henkilökohtaisen tietokoneen käyttökontekstista käyttötilanteen äänimaailman, visuaalisen ympäristön ja käyttäjän tarkkaavaisuustason suhteen. Mobiililaitteen käyttötilanteessa mahdollisuus äänien hyödyntämiseen voi olla rajoitettu ympäristön aiheuttaman melun takia tai mahdollisten sovellusten tuottamien äänien muille käyttäjille, esimerkiksi museoissa tai joukkoliikennevälineissä, aiheuttaman häiriön takia. Toimistoympäristössä ja kotikäytössäkin työpisteen valaistusta pystytään tyypillisesti optimoimaan ergonomisesti mielekkääksi. Sen sijaan mobiililaitteen käyttötilanteessa valaistusolosuhteet voivat vaihdella pilkkopimeästä häikäisevään auringonpaisteeseen minkä takia käyttöliittymän suunnittelussa on otettava huomioon vaihtelevat valaistusolosuhteet. Toimistoympäristössä, tyypillisessä henkilökohtaisen tietokoneen käyttötilanteessa, käyttäjällä on ainakin periaatteessa mahdollisuus keskittyä työskentelyyn käyttämänsä sovelluksen avulla. Mobiilisovelluksia sen sijaan käytetään usein samanaikaisesti käyttäjän muiden toimintojen kanssa ja käyttötilanne on alttiina ulkoisille häiriöille ja keskeytyksille. Mobiilisovellusten pitäisikin tukea käyttötilanteita, joissa käyttäjä ei pysty täysin keskittymään kyseisen sovelluksen käyttöön ja toisaalta tarjota käyttäjälle tilatietoa, jonka avulla hän voi nopeasti jatkaa sovelluksen käyttöä keskeytyksen jälkeen. Viime vuosina kosketusnäytöt ovat yleistyneet matkapuhelimien käyttöliittymäteknologiana. Ne sopivat hyvin karttatietoa näyttäviin mobiilisovelluksiin. Useimmat sovelluksen toiminnot voidaan käynnistää suoraan näyttöä koskettamalla, joten erillisiä laitteiston näppäimiä ei tarvita, vaan laitteen koosta suurin osa voidaan varata näytölle. Toiseksi kosketusnäytöt sopivat hyvin suorien komentojen antamiseen, joten varsinaista näyttötilaa ei tarvitse varata näytöllä oleviin valikoihin tai komentonappeihin. Näin koko näytön tila voidaan varata karttatiedon näyttämiseen. (Vaittinen et al., 2008) Nivalan (2007) mukaan seuraavat erilliset suunnittelutekijät tulee huomioida mobiilikarttojen suunnittelussa: visuaalinen ulkoasu, käyttöliittymä, käyttölaite, käyttäjät ja käyttökonteksti. Näiden tekijöiden vaikutukset mobiilikartan suunnitteluun on esitelty taulukossa 5.1.
LUKU 5. AIKAISEMPI TUTKIMUS 19 Taulukko 5.1: Tärkeimmät mobiilikarttojen käytettävyyteen liittyvät suunnittelutekijät (Nivala, 2007) Suunnitelutekijä Kartan visuaalinen suunnittelu Kartan graafinen käyttöliittymä Laite Käyttäjät Käyttökonteksti Kuvaus Kartografinen suunnittelu on tärkeä osa mobiilikarttojen kehitystyötä. Värien ja symbolien valinta, kartan sisältö ja tarkkuustaso pitää suunnitella mobiilikartoissa riippumatta muissa kanavista julkaistuista kartoista. Karttojen pitää olla luettavia, intuitiivisia ja esteettisesti miellyttäviä. Suunnittelutyötä voidaan myös personoida tuottamalle erilaisille kohderyhmille ja käyttötilanteisiin sopivat karttojen visuoalisoinnit.. Graafisen käyttöliittymän tulee täyttää käyttäjän tarpeet. Erään karttasuunnittelijan mukaan karttakäyttöliittymässä pitää olla mahdollisimman vähän nappeja ja käyttäjien pitää kyetä käyttämään sovellusta hansikkaat kädessä. Käyttäjän pitää myös pystyä luottamaan siihen, että hänen tekemänsä muutokset välittyvät sovelluksen tietokantaan riippumatta mahdollisista internetyhteyden katkoista. Maastossa käytettävällä mobiililaitteella on myös kyettävä kirjaamaan halutut asiat valmiiksi saakka, niin ettei tiedon päivittämistä tarvitse viimeistellä toisella laitteella maastosta tultua. Perinteiseen karttasuunnitteluun verrattuna mobiililaite asettaa suunnittelulle rajoituksia (pieni näyttökoko, rajallinen värimäärä, epävakaus, erottelukyky, akun rajallinen kesto ) tarjoten myös uusia mahdollisuuksia (dynaamisuus, vuorovaikutteisuus, sijaintitiedon hyödyntäminen). Myös edistyneemmät visualisointitavat, kuten 3-ulotteisuus, virtuaalitodellisuus ja animaatio, mahdollistavat uudentyyppisen suunnittelun. Eri käyttäjäryhmillä, esimerkiksi lapset/vanhukset, matkailijat/paikkatietoasiantuntijat jne, on omat vaatimuksensa kartoille. Myös kulttuurierot ja käyttäjien kielitaito on syytä ottaa huomioon suunniteltaessa monikulttuurisen käyttäjäjoukon käyttämiin karttoja. Käyttäjät voivat myös käyttää karttaa hyvin eri tavoin, jotkut suunnistukseen maastossa ja toisten käyttäessä sitä nähtävyyksien löytämiseen kaupunkilomallaan. Mobiilikarttoja voidaan käyttää ulkona tai sisätiloissa, suunnistettaessa maastossa tai kaupunkiympästössä. Onnistunut mobiilikarttojen suunnittelu perustuukin perusteelliseen tietoon niistä tilanteista, joista karttaa voidaan käyttää. Käyttäjävaatimusten selvittämiseksi mobiilikartan käyttökontekstia pitäisikin tutkia etukäteen sekä itse suunniteluprosessin aikana, jotta varmistettaisiin suunnitelman toimivuus käyttökontekstissa.
LUKU 5. AIKAISEMPI TUTKIMUS 20 5.3 WebPark WebPark oli vuosina 2001-2004 käynnissä ollut eurooppalainen tutkimusprojekti, joka kehitti paikkatietoon perustuvia palveluita (engl. Location-Based Service, LBS) suojelu- ja virkistysalueille (Edwardes ja Grossmann, 2008). Projektin tavoitteena oli tutkia ja kehittää mobiilipalveluiden personoituun sisältöön liittyvää teknologiaa ja liiketoimintaprosesseja ja todentaa kehitettyjen palveluiden käyttökelpoisuus käytännössä (WebPark Consortium). Tutkimussovellusta testattiin Vattimerellä olevalla Texelin saarella Hollannissa ja Sveitsin kansallispuistossa (engl. The Swiss National Park, SNP) (Edwardes ja Grossmann, 2008). Tutkimushankkeen päättymisen jälkeen ranskalainen Camineo SAS on kaupallistanut hankkeessa kehitettyjä palveluita (Camineo SAS, 2011b). 5.3.1 WebPark-tutkimushanke Sovelluksen tietosisältö koostuu kolmenlaisesta aineistosta: muiden kanavien, kuten infokioskien ja webin, kautta jo aikaisemmin tarjotusta olemassa olevasta sisällöstä, luonnontieteellisestä tutkimustiedosta sekä erikseen sovellusta varten tuotetusta sisällöstä. Dias et al. (2004) mukaan WebPark-järjestelmä voidaan yksinkertaistettuna kuvata julkaisujärjestelmäksi, jolla jaetaan tietoa paikallisista olosuhteista vierailijoille. Kehittämisen kannalta järjestelmän käyttämästä paikkatiedosta osan, kuten taustakarttojen ja väärävärikuviin perustuvan maastonluokittelun, käsittely on suoraviivaista ja vaatii lähinnä teknisiä konversioita aineiston siirtämiseksi kehitettävän palvelun käyttöön. Sen sijaan paikallisiin olosuhteisiin liittyvän useista tietolähteistä hankitun ajallisesti muuttuvan sisällön käsitteleminen on huomattavasti monitahoisempi prosessi, jonka onnistuminen vaatii puiston työntekijöiden ja muiden paikallisten sidosryhmien, kuten matkailuyrittäjien, sitoutumisen. Tällaista sisältöä on muun muassa reittien kuntotieto, kasvien kasvuvaiheista kertova tieto ja vesi- ja lumitilannetiedot sekä ajantasainen kuva- ja multimedia-aineisto. (Dias et al., 2004) Vaikka mobiilisovelluksen tekninen toteutus onnistui ja se sai jo alussa vierailijoilta innostuneen vastaanoton, Sveitsissä sovelluksen käyttöönottoa hidasti käyttöönoton alussa kansallispuiston päivittäisestä operoinnista vastaavan henkilöstön vastustus. Kansallispuiston hallinto oli mukana jo tutkimushankkeen alkuvaiheessa, mutta koska hanke annettiin puiston organisaatiossa paikkatietohallinnon vastuulle, se nähtiin ensisijaisesti teknisenä hankkeena eikä palvelun vaikutuksista käyty riittävästi keskusteluja operoinnista vastaavan henkilöstön kanssa. Tämä henkilöstö näki aluksi koko suunnitellun mobiilipalvelukonseptin vieraana ja oli huolissaan inhimillisen palvelukontaktin vähenemisestä sekä sovelluksen mahdollisesti tuoman kävijämäärän lisäyksen aiheuttamasta vaikutuksesta puiston luonnon kestokyvylle. Myös mobiilisovellukseen esitettyjen turvallisuustietojen riittävä päivitys nähtiin ongelmallisena, minkä johdosta sovelluksen ainoaksi turvallisuuteen liittyväksi toiminnoksi jäi oman sijainnin näyttäminen. (Dias et al., 2004). Webteknologioilla toteutettu tutkimussovellus toimi Windows Pocket PC2003
LUKU 5. AIKAISEMPI TUTKIMUS 21 käyttöjärjestelmää käyttävissä kämmentietokoneissa, joihin oli kytketty ulkoinen GPS-paikannin. Sovelluksen käyttämä tietosisältö tallennetaan mobiililaitteen välimuistiin, joten sovellusta voidaan käyttää myös silloin, kun käytössä ei ole aktiivista internet-yhteyttä (Dias et al., 2004). Tutkimussovelluksesta kehitetty kaupallinen versio, WebparkSNP Multimedia Guide, on vuokrattavissa kansallispuiston opastuskeskuksesta ja useista paikallisista majoitusliikkeistä viiden frangin eli noin neljän euron päivähintaan tai kolmeksi päiväksi kymmenellä frangilla (Swiss National Park, 2011). 5.3.2 iwebpark-mobiilisovellus iwebpark on ranskalaisen Camineo SAS:in kehittämä WebPark-sovelluksen sisältöön perustuva Apple ios -käyttöjärjestelmän mobiililaitteilla, kuten iphone ja ipad, toimiva mobiilisovellus, joka maksaa itunes-sovelluskaupassa noin neljä euroa (Camineo SAS, 2011a). Käynnistyksen yhteydessä sovellus pyytää käyttäjää valitsemaan kielen kolmesta sovelluksen kielivaihtoehdosta, jotka ovat saksa, ranska ja englanti, sekä pyytää lupaa käyttäjän sijaintitiedon käyttöön. Tässä tarkastelussa käydään läpi englanninkielisen version toimintoja. iwebpark sovelluksen englanninkielinen päävalikko on kuvassa 5.2. Sovelluksen tyypillinen tietonäkymä, josta näkyy esimerkki kuvassa 5.3, on jaettu yläpuolen kuvaosaan ja alapuolen selitystekstiin. Kuvan oikean yläkulman nappia painamalla kuvan saa suurennettua koko näytön kokoiseksi. Ylärivin navigaatioja toimintopainikkeilla voidaan siirtyä karttanäkymään tai käynnistää kohteeseen mahdollisesti liitetty multimediaesitys. Karttanäkymän ylävalikossa on käyttäjätoimintoina vasemmalta oikealle lueteltuna: paluu päävalikkoon, kartan suuntaus kompassisuunnan mukaan, zoomaus sekä oman sijainnin haku. Napauttamalla kartalla näkyvää POI-kohdetta näytetään kohteen kohdalla Kuva 5.2: Apple ios mobiililaitteissa toimivan iwebparksovelluksen päävalikko puhekuplamaisen kehyksen sisällä kohteen nimi, jota napauttamalla pääsee kohteen tietonäkymään. Esimerkki karttanäkymästä on kuvassa 5.4. Edellä kuvattujen kartta- ja tietonäkymien lisäksi sovelluksessa on luontoaiheisia tietokilpailukysymyksiä ja panoraamaesityksiä. Kahdeksastatoista alueen maisemakohteesta on tehty panoraamaesitys, jossa on näkyvissä kiertävä sektori 360 asteen panoraamakuvasta. Sovelluksen multimediasisältö ei tarjoa kovin paljon ainakaan englanninkielisen
LUKU 5. AIKAISEMPI TUTKIMUS Kuva 5.3: iwebpark-sovelluksen tietonäkymä 22 Kuva 5.4: iwebpark-sovelluksen karttanäkymä version käyttäjälle. Lyhyissä noin kolmenkymmennen sekunnin mittaisissa videoleikkeissä puistonvartija kertoo työstään. Video koostuu saksankielisen puheen lisäksi liikkumattoman kuvan päällä vaihtuvista englanninkielisistä käännösteksteistä. Muutenkin käyttöliittymä ja sisällön ulkoasu antaa sovelluksesta monin paikoin vanhanaikaisen ja viimeistelemättömän vaikutelman, vaikka itse sovelluksen tietosisältö vaikuttaakin tämän työn kirjoittajasta mielenkiintoiselta. 5.4 Travel MoCo Travel MoCo on Ahvenanmaalle toteutettu matkailijoille tarkoitetun mobiilipalvelun pilottijärjestelmä. Projektin kolme tutkimuskysymystä liittyivät sosiaaliseen vuorovaikutukseen, palvelun hyödyllisyyteen ja liiketoimintamalleihin. Ensinnäkin projektissa tutkittiin miten matkailijoille tarkoitetut yhteisölliset palvelut tukevat matkailijoiden keskinäistä sosiaalista vuorovaikutusta. Toiseksi tutkimuksessa tarkasteltiin toteuttaako mobiilipalvelu Braudelin säännön, joka on selostettu alaluvussa 4.1. Kolmantena tavoitteena oli kartoittaa mahdollisia liiketoimintamalleja näiden mobiilipalveluiden kehittämiseksi ja ylläpitämiseksi.(carlsson et al., 2008) Mobiilisovelluksen suunnittelun tavoitteissa korostettiin helppoa käyttöönottoa, yhteisöllisyyttä, toteutettavuutta ja laajennettavuutta. Suunnittelussa pyrittiin käytettävyyteen ja hyvään opittavuuteen niin, että sovelluksen käyttöönotto vaatii mahdollisimman vähän uusien toimintamallien opettelua, vaikka käyttäjät eivät olisivatkaan aikaisemmin käyttäneet vastaavantyyppistä matkailusovellusta. Travel MoCo -sovelluksen yhteisölliset elementit pyrkivät rohkaisemaan käyttäjiä mahdollisimman aktiiviseen sovelluksen käyttöön ja osallistumiseen. Koska projektin tavoitteena oli myös kehittää matkailusovellukseen liittyviä
LUKU 5. AIKAISEMPI TUTKIMUS 23 liiketoimintamalleja, korostuivat suunnittelussa palvelun kustannusten ja hyötyjen analyysi ja sovellus pyrittiin suunnittelemaan ja toteuttamaan niin, että se voisi olla pohjana kaupalliselle versiolle. (Carlsson et al., 2008) Travel MoCo -hankkeessa tehtiin vaiheittain kaksi prototyyppisovellusta. Ensimmäinen oli yksinkertainen älypuhelimen mikroselaimeen perustuva ja toinen prototyyppi kehittyneemmillä välineillä toteutettu. Koska projektin toteutusvaiheessa ei älypuhelimissa ollut yleisesti sisäänrakennettua GPS-paikannuslaitetta, ei sovellus käyttänyt tiedonhaussa hyväkseen käyttäjän sijaintitietoa. (Carlsson et al., 2008) Travel MoCo -tutkimuksessa todennettiin, että toteutettua sovellusta voitiin käyttää kokemusten jakamiseen, niin että matkailijat pystyivät hyödyntämään muiden tuottamaa tietoa matkan aikana sekä myös ennen ja jälkeen matkaa. Mobiilipalvelu loi myös matkailijoille uusia mahdollisuuksia tarjoamalla tietoa, jota ei virallisista tai yleisistä tietolähteistä olisi muuten ollut saatavilla. Tuloksena tunnistettiin kolme mahdollista liiketoimintamallia mobiilipalvelun toteuttamiseksi. Mobiilipalvelu voi olla kaupallinen lisäpalvelu olemassa olevan matkailuportaalin yhteydessä, matkailupalveluiden, kuten hotellien ja ravintoloiden, osittain tukema itsenäinen palvelu tai ohjelmistoyrityksen, mobiilioperaattorin tai näiden yhteenliittymän ylläpitämä kaupallinen palvelu. Projektin tuloksia arvioitaessa todettiin myös, että henkilöstön rekrytoinnin haastavuuden takia Ahvenanmaan virallinen matkailuorganisaatio ei katsonut olevansa kykenevä ottamaan mahdollista tuotantokäyttöön tulevaan mobiilipalvelua, kuten ei myöskään yleistä verkkopalveluaan, ylläpidettäväkseen, vaan sovelluksen ylläpito toivottiin voitavan ostaa kokonaispalveluna joko suomalaiselta tai ruotsalaiselta ohjelmistoyritykseltä. (Carlsson et al., 2008) Projektin tuloksena kehitettyä mobiilipalvelua ei ole siirretty alkuperäisistä suunnitelmista poiketen kaupalliseen käyttöön (Walden, 2011). 5.5 CRUMPET Matkailijoilla on yhä useammin matkalleen useampia kuin yksi tarkoitus, kuten työ, loma, viihde tai opiskelu. Etenkin näillä useasta syystä matkalle lähteneillä matkailijoilla ei ole mahdollisuutta suunnitella matka-aikatauluja tarkkaan etukäteen, vaan he tarvitsevat matkakohteessa ollessaan tietoa kohteesta odottaen yksilöllistä informaatiota ja palveluita. CRUMPET (Creation of User-friendly Mobile services Personalized for Tourism) oli vuosina 2001-2002 käynnissä ollut EU-hanke, jossa pyrittiin vastaamaan näihin tarpeisiin uuden teknologian keinoin. (Poslad et al., 2001) Tutkimussovelluksenkäyttäjälaitteenakäytettiin paikannusominaisuudella varustettuja kämmentietokoneita (engl. personal digital assistant, PDA)(Schmidt-Belz ja Poslad, 2003). Tärkeimmiksi sisällöllisiksi ominaisuuksiksi käyttäjät kokivat käyttäjän sijainnin kertovien karttojen sekä matkailunähtävyyksien näyttämisen kartalla ja tiivistetyn tiedon kohteista. Monet myös kokivat matkailukohteeseen pääsyyn ja sieltä poispääsyyn liittyvän tiedon kulkuyhteyksistä tärkeänä. Sen sijaan uutisia, säätietoja ja kuvasisältöä ei koettu kovinkaan tärkeänä. Käyttöliittymän
LUKU 5. AIKAISEMPI TUTKIMUS 24 toiminnallisuuteen käyttäjät toivoivat muun muassa yksinkertaista hakutoimintoa sovelluksen automaattisen sisältöpalvelun sijaan, karttojen automaattista suuntaamista sekä ääniohjausta ja audiomuotoisia tiedotteita. (Schmidt-Belz ja Poslad, 2003) Haastatelluista testikäyttäjistä yli 60 % oli valmis maksamaan tutkimussovelluksen kaltaisen matkailijoille tarkoitetun mobiilipalvelun käytöstä. Käyttäjistä sopivalta tuntuvan maksun suuruudessa ja sopivasta maksutavasta oli erilaisia käsityksiä. Maksutavoiksi käyttäjät ehdottivat pääasiassa tilauspohjaista, laitteen ja palvelun vuokrauksen kertamaksua ja ennakkomaksua. Myös yksittäiseen tiedonhakuun kohdistuvaa mikromaksua ehdotettiin joissain käyttäjäkommenteissa. Useimmat käyttäjät pitivät 10 euron päivämaksua sopivana sovelluksen sisältävän laitteen vuokrahintana. (Schmidt-Belz ja Poslad, 2003)
6 Suunnitteluprosessin kuvaus Tässä luvussa kuvataan ensin ISO 9241-210-standardin määrittämä iteratiivinen ihmiskeskeinen suunnitteluprosessi. Sen jälkeen tarkastellaan suunnitteluprosessin etenemistä tässä työssä. 6.1 Iteratiivinen järjestelmäkehitys ISO 9241-210 -standardi määrittää ihmiskeskeiselle suunnittelulle kehikon, jossa suunnittelu perustuu käyttäjien, tehtävien ja ympäristöjen selkeään ymmärtämiseen, joka varmistetaan muun muassa käyttäjien mukanaololla koko suunnittelu- ja kehitysprosessin ajan sekä suunnittelutiimin monialaisilla taidoilla ja näkökulmilla. Suunnitteluprosessi on luonteeltaan iteratiivinen eli suunnittelun vaihejaksoja toistetaan, kunnes saavutetaan haluttu lopputulos. Käyttäjiltä saatu palaute on koko suunnittelun ajan tärkeä tietolähde ja se ohjaa suunnitteluprosessin tulosten arviointia ja näin myös suunnitteluprosessin etenemistä. Julkaistun tuotteen käytönaikaisella käyttäjäpalautteella kerätään tietoa tulevien tuoteversioiden kehitystyötä varten. (ISO, 2010) Ihmiskeskeistä suunnittelua varten tehdään koko prosessin alussa tuotteen elinkaaren yli ulottuva suunnitelma, jossa määritellään muun muassa miten tunnistetaan eri suunnitteluaktiviteetteihin soveltuvat menetelmät, resurssit, kriittiset osaamisalueet ja käyttäjänäkökulmat. Suunnitelmassa kuvataan myös suunnitteluaktiviteettien välitavoitteet sekä eri vaiheiden, mukaanluettuna käyttäjäpalautteen johdosta tehtävien mahdollisten suunnittelumuutosten, vaikutus kokonaisaikatauluun. (ISO, 2010) Itse suunnittelutyö muodostuu neljästä suunnitteluaktiviteetistä. Käyttötilanteen ymmärtäminen ja määrittely kuvaa käyttäjien ominaisuudet, tehtävät sekä organisatorinen ja fyysinen ympäristö. Käyttäjävaatimusten määrittelyssä kuvataan muun muassa tuleva käyttötilanne, käyttäjätarpeista ja käyttötarpeista johdetut vaatimukset sekä standardeista, ohjeistuksista ja käyttötilanteista johdetut käytettävyysvaatimukset. Suunnitteluratkaisujen tuottaminen sisältää käyttäjäkokemuksen huomioivan käyttöliittymä- ja vuorovaikutussuunnittelun lisäksi suunnitteluratkaisun konkretisoinnin esimerkiksi prototyypeillä tai periaatemalleilla käyttäjille, suunnitteluratkaisujen muuttamisen käyttäjäpalautteen pohjalta sekä niiden saattamisen toteutuksesta vastaavien tietoon. Suunnitteluratkaisujen arvioinnissa hyödynnetään suoraan käyttäjiltä saatua palautetta tai muilla menetelmillä, kuten mallinnuksella tai simuloinnilla, saatuja arvioita siitä, miten käyttäjät kokisivat järjestelmän käytön. ISO 9241-210 mukainen suunnittelumalli on esitetty kuvassa 6.1. (ISO, 2010) 25
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 26 Kuva 6.1: Ihmiskeskeisen suunnittelun aktiviteettien keskinäinen riippuvuus ISO 9241-210 -standardin kuvaamana (ISO, 2010) 6.2 Kartoitusvaihe Suunnitteluprosessi aloitettiin vuoden 2011 alussa tutustumalla saatavilla olevaan aihepiiriin liittyvään paikkatietotietoaineistoon ja kartoittamalla prototyypissä mahdollisesti käytettäviä teknisiä ratkaisuja ja ohjelmistoarkkitehtuuria. Suunnitteluprosessin yleisluontoinen ajallinen eteneminen on esitetty kuvassa 6.2. Kartoitusvaiheen aikana tutustuttiin myös useisiin suomalaisiin paikkatietoa ja mobiiliteknologiaa hyödyntäviin palveluihin, joiden kehitysvaihe vaihteli tutkimushankkeen ja kaupallistamisvaiheessa olevan palvelutuotteen välillä. Näin kartoitettiin näiden palveluiden mahdollista hyödyntämistä prototyyppisovelluksen kehitystyössä. Kartoituksen tuloksena todettiin, että kyseisiä palveluita ei suoraan pystytä hyödyntämään johtuen eroista käyttötilanteissa ja tutkittujen palveluiden teknologiavalintojen aiheuttamista rajoituksista. 6.2.1 Paikkatietoaineistoihin tutustuminen OpenStreetMap (OSM) on vapaaehtoistyöhön perustuva kartoitushanke, jonka tavoitteena on tarjota koko maailman kattavaa kartta-aineistoa. OSM:n tuottama paikkatieaineisto on lisenssiehtojen mukaan käyttäjilleen maksutonta. Samoin hankkeen palveluissa käytetään avoimen lähdekoodin ohjelmistoja. Tämä mahdollistaa palvelun paikkatietoaineiston ja ohjelmistojen käyttämisen tiettyyn
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 27 Kuva 6.2: Tutkimuksen eri vaiheiden yleisluonteinen toteutumisaika viikkotasolla vuonna 2011. tarkoitukseen muokatun palvelun pohjana. Kartoitusvaiheessa tutkittiinkin mahdollisuutta kehittää palvelu hyödyntäen suoraan OSM-palveluarkkitehtuuria. Saatavilla olevaan paikkatietoaineistoon tutustuttiin siirtämällä sitä OpenStreetMapiin. Ympäristökeskuksen paikkatietoaineistoa voi ladata OIVA-palvelusta, jonka luonnon virkistyskäyttömahdollisuuksia kuvaavassa aineistossa on muun muassa liikuntapaikkoja, ulkoilureitistöjä ja virkistysalueita kuvaavaa aineistoa. Tämän aineiston käyttöehdot antavat lataajalle suhteellisen laajat käyttöoikeudet aineistoon myös osana kolmansille osapuolille tarjottavaa palvelua. (Valtion ympäristöhallinto, 2010). Koska OpenStreetMap ei ole Suomessa virallinen organisaatio ja sen kartoittajat eivät näin ollen edusta virallisesti OSM:ia, eivät OIVA-palvelussa annetut käyttöoikeudet päde siirrettäessä aineistoa OSM:n paikkatietokantaan. Tämän työn tekijä sai kuitenkin pyynnöstä Suomen ympäristökeskukselta luvan siirtää tutkimusalueilta aineistoa OSM:iin. Aineiston muuntamiseksi Syken ESRI Shapefile -muotoinen aineisto piti muuntaa OSM-sisäänlukuohjelmien tulkitsemaan XML-muotoon ja sen koordinaatit piti muuntaa Kartastokoordinaattijärjestelmästä (KKJ) WGS84-järjestelmään. Teknisen muunnoksen lisäksi aineistolle piti tehdä loogisen tason muunnos, jossa kuvattiin eri kohteiden vastaavuudet järjestelmien välillä. Tutkimuksen tekijä laati OSM-kehittäjäyhteisön käyttämälle wiki-sivustolle lähdeaineiston kuvauksen ja pyysi yhteisöltä kommentteja ja ehdotuksia kohteiden kuvaustavoista OSM-paikkatietokannassa(Rinne ja OSM-kehittäjäyhteisö, 2011). Muutama aktiivikartoittaja osallistuikin muunnosohjelmien parametroinnissa käytettyjen siirtosääntöjen täydentämiseen. Sähköisessä muodossa olevan paikkatietoaineiston lisäksi työn tekijä tutustui Metsähallituksen arkistoissa olevaan erityisesti Nuuksion aluetta koskevaan arkistomateriaaliin. Tavoitteena oli kerätä aineistoa, jota voitaisiin käyttää prototyyppisovelluksessa. Paikkasidonnaista aineistoa tässä materiaalissa oli muun
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 28 muassa alueiden luokittelu sen luontotyypin mukaan. Metsähallitukselta saatiinkin sähköisessä muodossa tutkimuksen kohdealueen jaottelu Natura-suojeluohjelman mukaisiin luontotyyppeihin. Yhdistämällä prototyyppisovelluksessa käyttäjän sijaintitieto, alueen luontotyyppi ja luontotyypin kuvaustieto käyttäjälle voitaisiin kertoa yleistietoa juuri kyseisen alueen luonnosta. Esimerkiksi lehtometsässä sovellus voisi esitellä lehtometsän kasvi-, eläin-, ja sienilajistoa. Ensimmäisen vaiheen prototyyppiin toteutettavia toiminnallisuuksia valittaessa arvioitiin, että todelliseen paikkatietoon perustuva luontotyypeistä ja niiden lajistosta tiedottaminen ei tuota riittävästi suunnittelutyötä tukevaa käyttäjäpalautetta toteuttamisen vaatimaan työmäärään nähden. Prototyyppisovelluksen käyttöliittymässä esiteltiin kuitenkin kyseistä toiminnallisuutta linkittämättä sitä käyttäjän todelliseen sijaintiin. 6.2.2 Kehitysympäristöjen arviointi OpenStreetMapin käyttäjärajapinnan sovellus on toteutettu Ruby-ohjelmointikielellä Ruby on Rails -kehitysympäristössä. OSM-hankkeen paikkatietokanta-aineiston tietovarastona käytetään PostgreSQL-tietokantaa, jonka toiminnallisuutta on täydennetty paikkatietoaineistojen käsittelyä tukevalla PostGIS-laajennuksella. Kartoitusvaiheessa asennettiin OSM-käyttäjärajapinnan toteuttavat ohjelmistot sekä maantieteellisesti rajattu otos paikkatietoaineistosta kehitysympäristönä toimivaan Mac OS X -ympäristöön. Kehitysympäristössä tehtiin OSM-vakiorajapintaan lisäyksenä prototyyppisovelluksen vaatima kohdehaku, joka palauttaa tietyn koordinaateilla määritellyn paikan ympäristössä olevat kiinnostavat kohteet (engl. Point of Interest, POI). Lisäksi Ruby on Rails kehitysympäristöä arvioitiin toteuttamalla sen avulla joitain sovellustietokannan ylläpitotoimintoja. OSM-arkkitehtuuriin tukeutumista ei kuitenkaan nähty arvioinnin jälkeen mielekkäänä vaihtoehtona sovelluksen toteuttamiseksi. Sovelluksesta haluttiin tehdä sellainen, että se ei vaadi jatkuvaa tietoliikenneyhteyttä, vaan voi toimia myös ilman aktiivista tietoliikenneyhteyttä. Toisaalta OSM-arkkitehtuuriin perustuvan toteutustavan ei sellaisenaan nähty tukevan riittävän hyvin sovelluksen käyttöliittymäkehitykselle asetettuja vaatimuksia. Koska sovelluksen logiikka arvioitiin toteutettavan suurelta osin käyttäjälaitteessa, joko selainohjelmistossa tai käyttöjärjestelmäkohtaisessa natiivisovelluksessa (engl. native application), ei nähty mahdollisuuksia hyödyntää Ruby on Rails -kehitysympäristön tarjoamia sovelluskehityksen tehokkuushyötyjä. 6.3 Ensimmäinen iterointivaihe Ensimmäinen iterointivaihe aloitettiin määrittelemällä prototyyppisovelluksen käyttötilanne ja toiminnallisuudelle asetettavat tavoitteet. Sovelluksen ytimeksi määriteltiin maastossa olevan käyttäjän lähiympäristön mielenkiintoisten kohteiden näyttäminen. Muita tavoitteita oli muun muassa yhteisöllisesti tuotetun tiedon hyödyntäminen sekä reitteihin ja luontotyyppiin liittyvän informaatiosisällön prototypointi.
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 29 Sovellukseen suunniteltiin myös turvallisuusosio, joka jätettiin toteuttamatta, koska palvelun ei haluttu antavan käyttäjälle perusteetonta turvallisuudentunnetta. Mikäli käyttäjä luottaa liikaa sovelluksen tarjoamaan apuun ongelmatilanteissa, voivat ongelmat sovelluksessa, mobiililaitteessa tai sen käytössä aiheuttaa käyttäjälle enemmän haittaa kuin hänelle syntyisi mikäli hän ei olettaisi saavansa sovellukselta lainkaan tukea turvallisuuteen, kuten suunnistukseen tai avun hälyttämiseen, liittyvissä toiminnoissa. 6.3.1 Prototyypin kohderyhmän ja palvelusisällön määrittely Outdoors Finland Etelä -hanke (OFE) on luonto- ja kulttuurimatkailuun liittyvien aktiviteettireitistöjen ja niihin liittyvän osaamisen ja yhteistyön kehittämishanke. Tämä alueellinen Kaakkois-Suomeen, Uudenmaan ja Hämeen reitistöihin keskittynyt kolmi- ja puolivuotinen hanke on käynnistetty vuoden 2011 keväällä. OFE-hanketta hallinnoi Lahden ammattikorkeakoulu ja sen käytännön toiminnasta vastaa täysipäiväinen projektipäällikkö. (Räsänen, 2011) Huhtikuussa 2011 sovittiin yhteistyöstä tämän tutkimuksen ja OFE-hankkeen välillä ja käytännön toimenpiteenä päätettiin, että tässä tutkimuksessa kehitettävälle palveluprototyypille tehdään käyttäjätestausta OFE-hankkeen strukturoituihin haastatteluihin perustuvan haastattelututkimuksen yhteydessä. Tutkimusyhteistyö nähtiin mahdollisuutena kerätä käyttäjäpalautetta mobiilipalvelun kehittämiseksi. Toisaalta konkreettisen toimivan prototyypin esittelyllä ja siitä käyttäjäkommenttien keräämisellä tavoiteltiin kattavampaa tietoa käyttäjien mobiilipalveluihin liittyvistä tarpeista ja toiveista kuin pelkillä haastatteluilla. Toteutettavan prototyyppisovelluksen kohderyhmäksi valittiin aktiviteettimatkailijat, tässä tapauksessa luonto- tai historiakohteista kiinnostuneet patikoiden, pyöräillen tai meloen liikkuvat matkailijat, jotka toteuttavat osan tai koko matkansa omatoimisesti. Prototyyppisovelluksen tarkoituksena on tukea näiden matkailijoiden retken toteutusta tarjoamalla tietoa muun muassa alueella olevista reiteistä ja mielenkiintoisista kohteista. 6.3.2 Kehitysarkkitehtuurin ja -työkalujen valinta Kehitysympäristöjen aikaisemmassa arvioinnissa päädyttiin siihen, että sovelluksen toiminnallisuus toteutetaan suurelta osin mobiililaitteessa. Tämän arvioinnin perusteella käyttöliittymän toteutusvaihtoehdoiksi nousivat HTML5-ominaisuuksia hyödyntävä websovellus sekä mobiililaitteen käyttöjärjestelmäkohtaisilla työkaluilla toteutettu natiivisovellus. Näitä vaihtoehtoja on kuvattu tarkemmin alaluvussa 3.1. Prototyyppisovellus päätettiin kehittää webteknologioihin perustuvana HTML5-sovelluksena, jotta yksittäisellä sovellusversiolla pystyttäisiin tukemaan mahdollisimman suurta käytössä olevaa laitekantaa ja käyttäjäjoukkoa. 6.3.3 Käyttöliittymän suunnittelu Prototyypin käyttöliittymä suunniteltiin yhdessä Aalto-yliopiston jatko-opiskelijan kanssa. Alussa kirjoittaja ja jatko-opiskelija hahmottelivat prototyypin
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 30 käyttöliittymään tulevia toiminnallisuuksia yhteisessä palaverissa. Tämän jälkeen jatko-opiskelija teki Balsamiq Mockups -luonnosteluohjelmalla käyttöliittymän päänäkymästä hahmotelman, jonka perusteella kirjoittaja teki käyttöliittymästä muutamien näkymien kuvauksia samalla ohjelmalla. Alkuvaiheen käyttöliittymäluonnos on kuvassa 6.3. Kun käyttöliittymän perusrakenteesta oli tuotettu riittävän tarkka suunnitelma, toteutettiin käyttöliittymästä websuunnitteluvälineillä ensimmäinen HTML-kielinen prototyyppi. Käyttöliittymän suunnittelun ja teknisen toteutuksen rajaa ei voi määritellä tarkkaan, sillä suunnittelua jatkettiin iteratiivisesti koko toteutusvaiheen ajan. Käyttöliittymän sisällöstä ja toteutustavoista suunnittelijat kävivät keskustelua pääasiallisesti sähköpostitse ja tapasivat kolme kertaa. Kuva 6.3: Alkuvaiheen luonnos käyttöliittymästä (Teräs, 2011) 6.3.4 Sovelluksen toteutus ja ylläpito Käyttöliittymän tekninen toteutus aloitettiin, kun yleissuunnitelma käyttöliittymän rakenteesta ja siihen tulevista toiminnoista oli hahmottunut. Kehitysympäristönä oli Apple Mac OS X -käyttöjärjestemällä varustettu kannettava työasema ja ohjelmointiympäristönä (engl. integrated development environment, IDE) käytettiin Aptana Studio -ohjelmistoa. Ohjelmistokoodin versiohallintana käytettiin Apache Subversion-ohjelmaa. Sovelluksen kehitystyöhön liittyvä testaus tehtiin pääasiassa kehitystyöasemassa toimivalla sovellusinstanssilla. Käyttäjähaastatteluihin liittyvää koekäyttöä varten sovellus julkaistiin ulkoiselta palveluntarjoajalta hankittuun websäilytyspalveluun (engl. web hosting), josta se
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 31 oli julkisesti käytettävissä. Sovelluksen kehitys- ja koekäyttöversiot käyttivät yhteistä tietokantaa, joka toimi palveluntarjoajan ylläpitämässä tietokantapalvelussa. Prototyyppisovelluksen palvelintoiminnallisuus, webpalvelu ja tietokanta, siirrettiin varsinaisen sovelluskehitystyövaiheen jälkeen tätä palvelua varten varattuun toiselta palveluntarjoajalta hankittuun Linux-pohjaiseen virtuaalipalvelimeen. Tällä muutoksella pyrittiin varautumaan sellaisiin palvelintoiminnallisuuden laajennuksiin, joita ei pystyttäisi toteuttamaan aikaisemmin käytetyssä jaetussa ylläpitopalvelussa (engl. shared hosting) palveluntarjoajan tietoturvasyistä asettamien teknisten rajoitusten takia. Prototyyppisovelluksen ohjelmistoarkkitehtuuri ja tärkeimmät ohjelmistokomponentit on esitelty luvussa 7 ja sen sisällöntuotanto luvussa 8. 6.3.5 Käyttöliittymän toteutusvaiheen aikainen kenttätestaus Prototyypin kehittäjä testasi käyttöliittymän toteutuksen aikana käyttöliittymän toimivuutta kenttätestauksella todellista käyttötilannetta muistuttavissa olosuhteissa. Kenttätestauksen toteutus on kuvattu alaluvussa 9.1 6.3.6 Käyttäjähaastattelut kentällä Prototyyppisovelluksen suunnitteluratkaisujen onnistumista arvioitiin usealla käyttäjätutkimusmenetelmällä, joista sovelluksen kehityksen aikaisista eniten tietoa saatiin käyttäjähaastatteluilla. Haastattelut toteutettiin pääosin vuoden 2011 heinä-elokuussa. Haastattelujen toteutus ja saadut tulokset on kuvattu tarkemmin alaluvussa 9.2. 6.3.7 Osallistuminen Apps4Finland-kilpailuun Prototyyppisovellus osallistui Suomen Verkkodemokratiaseuran ja Forum Viriumin Helsingin marras-joulukuussa järjestämään Apps4Finland 2011 -kilpailuun, jolla kannustettiin hyödyntämään avointa dataa. Kilpailuun osallistuneista 140 työstä prototyyppisovellus, josta käytettiin nimeä Retkeni, kutsuttiin yhtenä kahdeksasta sovelluksesta esiteltäväksi Maanmittauslaitoksen järjestämään paikkatietoalan ammattitapahtumaan, Paikkatietomarkkinoille. (Suomen Verkkodemokratiaseura ja Forum Virium) Kilpailuun ilmoittautumiseen liittyen sovelluksen tekijä teki sovelluksesta kolme ja puoli minuuttia kestävän videon, jossa esiteltiin sovelluksen käyttötarkoitusta, tietosisältöä ja tärkeimpiä toimintoja (Rinne, 2011). Kilpailuun osallistuvien sovellusten oli mahdollisuus koekäyttää taustakarttoina MML:n kartta-aineistoa, jonka MML avaa vapaaseen käyttöön vuoden 2012 toukokuun alussa (Maanmittauslaitos, 2011). Kilpailun tuoman julkisuuden seurauksena prototyyppisovelluksella oli kilpailun aikana merkittävästi enemmän koekäyttäjiä kuin muina koekäyttöjakson aikoina, mikä on todettavissa alaluvussa 9.4 selostetusssa käyttölokin analyysista. Kilpailuun ja paikkatietoammattilaisten messutapahtumaan osallistuminen lisäsi työn tekijän tuntemusta paikkatietoalan sovellustarjonnasta ja kilpailutilanteesta sekä myös toi yhteistyökontakteja, joita voi mahdollisesti hyödyntää sovelluksen myöhemmän kehityksen aikana.
LUKU 6. SUUNNITTELUPROSESSIN KUVAUS 32 6.3.8 Ryhmäkeskustelut OFE-hanke järjestää ryhmäkeskusteluja aktiviteettireitistöjen käyttäjien toiveiden ja mielipiteiden kartoittamiseksi. Tässä työssä kehitetyn prototyyppisovelluksen on suunniteltu olevan mukana kolmessa ryhmäkeskustelussa, joista ensimmäisen toteutuksesta ja tuloksista kerrotaan tarkemmin alaluvussa 9.5. Päävastuu ryhmäkeskustelujen käytännön toteutuksesta on OFE-hankkeen tarjouskilpailun perusteella valitsemalla tutkimusyrityksellä. 6.4 Toinen iterointivaihe Toisen iterointivaiheen aikana painotutaan käyttöliittymän kehittämiseen palvelemaan erityyppisiä käyttäjän kannalta kiinnostavia sisältöjä. Aikataulullisista ja työn laajuuteen liittyvistä syistä tämän iterointivaiheen toteutusta ja tuloksia ei raportoida tässä tutkimuksessa.
7 Prototyyppisovelluksen tekninen suunnittelu Tässä luvussa kuvataan prototyyppisovelluksen teknistä toteutusta sekä sovelluksen arkkitehtuuria ja kehitystyössä käytettyjä ohjelmistokomponentteja. 7.1 Yleisarkkitehtuuri Käyttäjän mobiililaitteen ohjelmistoarkkitehtuuri on esitetty kuvassa 7.1. Sovelluksen mobiililaitteessa oleva toiminnallisuus nojautuu laitteen HTML5-standardeja tukevaan selainohjelmaan ja JavaScript-tukikirjastoihin. Tärkeimpänä yksittäisenä HTML5-ominaisuutena voidaan pitää paikannustietoa tarjoavaa Geolocation API -ohjelmointirajapintaa. Sovelluksen karttanäkymät on toteutettu OpenLayers-kirjaston avulla. Itse sovelluskoodin tärkeimpiä komponentteja ovat HTML5-kuvauskielinen sovellusrunko, JavaScript-kielellä toteutettu dynaaminen sisältö sekä CSS-tyyliarkeilla (engl. Cascading Style Sheets) kuvattu sovelluksen ulkoasu. Kuva 7.1: Mobiililaitteessa olevan sovelluksen ohjelmistoarkkitehtuuri Sovelluksen palvelintoiminnallisuuden pääkomponentit on esitelty kuvassa 7.2. Palvelimella oleva sovelluslogiikka on toteutettu PHP-kielisiin ohjelmaskripteihin ja niissä oleviin tietokantakutsuihin. Sovellus käyttää ulkoisia palveluita taustakarttojen ja tunnistuspalveluiden tuottamisessa. 7.2 Asiakasohjelmiston tukikirjastot Prototyyppisovellus hyödyntää useiden eri JavaScript-kielisten tukikirjastojen tarjoamia toiminnallisuuksia. Sovelluksen kannalta tärkeimmät toiminnallisuudet 33
LUKU 7. PROTOTYYPPISOVELLUKSEN TEKNINEN SUUNNITTELU 34 Kuva 7.2: Sovelluksen palvelintoiminnallisuuden ohjelmistoarkkitehtuuri liittyvät dynaamisten karttojen näyttämiseen, käyttöliittymäelementtien toteutukseen sekä käyttäjätunnistukseen. Sovelluksen käyttämät HTML-ohjelmakirjastot on lueteltu taulukossa 7.1. Karttanäkymien toteuttamiseen käytettiin OpenLayers-kirjastoa, joka on avoimeen lähdekoodiin perustuva JavaScript-kirjasto (OpenLayers-kehittäjäyhteisö, 2011). Kirjasto tarjoaa toiminnallisuuden, jonka avulla muodostetaan käyttöliittymän karttanäkymät ulkoisten karttapalveluiden, kuten OpenStreetMap ja Maanmittauslaitos, tarjoamien pohjakarttojen sekä sovelluksen tietokannassa olevan vektorimuotoisen paikkatietoaineiston avulla. Kosketusnäyttöjä hyödyntävät käyttöliittymätoiminnot on sisällytetty erilliseen OpenLayers Mobile -kirjastoon. Käyttöliittymän teknisen toteutuksen alkuvaiheessa tutkittiin mahdollisuutta hyödyntää JQuery Mobile -kirjastoa kehitystyössä. JQuery Mobile on kosketusnäyttöisille älypuhelimille ja taulutietokoneille toteutettavien käyttöliittymien kehitykseen tarkoitettu ohjelmistokehityskirjasto, joka tukee muun muassa Andoid- ja Apple ios käyttöympäristöjä (JQuery Mobile -kehittäjäyhteisö, 2011). Riittävän kattavan laitepeiton saavuttamiseksi päätettiin, että tässä kehitysvaiheessa ei voida hyödyntää kyseistä kirjastoa. Kirjasto ei tue Nokia Symbian 3 -käyttöjärjestelmän puhelimia, joita oli käytössä niin prototyypin kehittäjällä kuin haastattelijoillakin. Käyttöliittymäkomponenttien toteutuksessa päädyttiin käyttämään Nokia webkehittäjille tarjoamaan Nokia Mobile Web Templates -komponenttikirjastoa, joka tarjoaa JQuery Mobile laajemman laitepeiton, mutta suppeamman toiminnallisuuden (Nokia Oyj). Tämän kirjaston avulla toteutettiin tärkeimpien käyttöliittymäkomponenttien, kuten listojen, painonappien ja kytkinten (engl. toggler) ulkoasu ja käyttöliittymätoiminnallisuus. 7.2.1 Tunnistuspalvelut Kehitettävä sovellus edellyttää, että käyttäjä on tunnistautunut voidakseen lisätä, arvioida tai kommentoida kohteita sosiaalisessa mediassa. Sovellus käytti tunnistuksessa Facebook-yhteisöpalvelun tarjoamaa ohjelmointirajapintaa (engl. Application programming interface, API). Facebookin tunnistuspalveluun nojautuminen helpotti sovelluksen kehitystyötä, koska monia käyttäjähallinnan operaatioita saatiin rajapinnan kautta palveluna eikä niitä tarvinnut toteuttaa itse
LUKU 7. PROTOTYYPPISOVELLUKSEN TEKNINEN SUUNNITTELU 35 Taulukko 7.1: Prototyyppisovelluksessa käytetyt JavaScript-kirjastot Nimi OpenLayers OpenLayers Mobile Nokia Web Templates Proj4 Facebook JavaScript SDK Käyttötarkoitus Dynaamisten karttojen toteutus webympäristöön Kosketusnäyttötoimintojen tuki OpenLayers-kirjastoon Mobiilikehitykseen tarkoitettu käyttöliittymäkomponenttikirjasto Koordinaattimuunnoksien tekoon tarkoitettu funktiokirjasto Facebook-integroinnin toteutus, mm. käyttäjätunnistus prototyyppisovellukseen. Myös niille käyttäjille, joilla on olemassa oleva Facebook-tunnus, tunnistautuminen on yksinkertaista, koska palvelua varten ei tarvinnut luoda ja muistaa erillisiä salasanoja. Toisaalta tunnistautumisratkaisu sulkee pois sellaiset käyttäjät, jotka eivät halua avata omaa Facebook-tiliä tai eivät halua käyttää sitä ulkoisten sovellusten yhteydessä. (Facebook, 2011) Facebookin API-rajapinnan kautta käyttäjillä on myös mahdollisuus kommentoida kohdetta oman Facebook-profiilinsa uutisosioon eli niin sanotulle seinälle ja tätä kautta myös muille käyttäjille. 7.3 Sovelluspalvelimen ja asiakassovelluksen kommunikaatio Sovelluspalvelimen, jossa käytetään Apache HTTP Server -palvelinohjelmistoa, ulkoinen rajapinta on toteutettu PHP-ohjelmointikielellä kirjoitetuilla rajapintaohjelmilla. PHP-kieltä käytetään erityisesti webpalvelinympäristöissä dynaamisten sivujen luontiin. Rajapintaohjelmat tarkastavat kutsuparametrien oikeellisuuden ja pääsääntöisesti muodostavat näiden parametrien avulla SQL-kielisen tietokantakutsun sovelluksen tietokantaan. PHP-ohjelma koostaa yhdestä tai useammasta tietokantakutsusta saadun tuloksen JSON-muotoon kutsuvalle asiakasohjelmalle palautettavaksi. Paikkatietojen siirrossa palvelimelta selaimelle on käytetty GeoJSON-muotoa. JSON (JavaScript Object Notation) yksinkertainen tiedonsiirtomuoto, joka on standardoitu osana JavaScript-ohjelmointikieltä. Tekstimuotoinen JSON-muoto on kuitenkiin riippumaton ohjelmointikielistä, joten sitä voidaan käyttää myös muilla kuin JavaScript-kielellä tehdyillä ohjelmilla. (JSON-kehittäjäyhteisö, 2011) GeoJSON on JSON-muotoa hyödyntävä vektorimuotoisen paikkatiedon esitystapa, jota käytetään paikkatietogeometrioiden siirtoon ja tallennukseen. GeoJSON-muodon tukemat paikkatietogeometriat on lueteltu taulukossa 7.2. Geometriatietoihin voidaan liittää joukko ominaisuuksia (engl. property), esimerkiksi kohteen nimi ja kuvaustiedot. (Butler et al., 2011) Koska GeoJSON-määrittely ei ota kantaa kohteiden ominaisuustietojen nimeämiseen tai esitysmuotoon, pitää ominaisuustietojen kohdistaminen (engl. mapping) ja
LUKU 7. PROTOTYYPPISOVELLUKSEN TEKNINEN SUUNNITTELU 36 konversio järjestelmien välillä toteuttaa tilanteeseen sopivilla konversiofunktioilla. GeoJSON-ohjeistuksessa ei myöskään määritellä paikkatietoaineiston palvelukutsun syntaksia eli sitä minkälaisella parametroinnilla valitaan palvelukutsun palauttaminen kohteiden joukko ja esitystarkkuus. Taulukko 7.2: GeoJSON-siirtomuodon tukemat paikkatietogeometriat (Butler et al., 2011; Sanastokeskus TSK ry, 2011; Virrantaus, 2001) Geometria Tyypin nimi Kuvaus Piste Point Nollaulotteinen geometrinen objekti, joka määrittää sijainnin koordinaatistossa Murtoviiva LineString Yhtenäinen käyrä, joka koostuu suorista osaviivoista eli janoista Pistejoukko MultiPoint Järjestämätön joukko pisteitä MultiLineString Monipolygoni MultiPolygon Polygoni Polygon Pintapala, jolla on tasomainen interpolointi Murtoviivajoukko Geometriakokoelma Järjestämäton joukko murtoviivoja Suljettujen käyrien muodostama joukko GeometryCollection Yksittäisen geometrian sisältämä sisäkkäinen geometriakokoelma 7.4 Sovellustietokanta Prototyyppisovelluksen tietokannan luku- ja ylläpito-operaatiot tehdään SQL-kielellä. Monimutkaisemmat tietokantaoperaatiot, kuten optimoitua etäisyyslaskentaa vaativa lähimpien kohteiden haku, on toteutettu tallennettuna proseduurina (engl. stored procedure). Tietokantaohjelmistona käytettiin palveluntarjoajan palvelimella ylläpidettyä MySQL-tietokantaa. Tietokannan kuvaus on liitteessä F. 7.5 Mediawiki Vapaamuotoista kohteiden kuvaustietoa varten sovelluksen yhteyteen asennettiin MediWiki-ohjelmisto, joka on alunperin Wikipediaa varten kehitetty ohjelmisto (Mediawiki kehittäjäyhteisö, 2011). Mediawiki-palveluun suunniteltiin julkaistavan vapaamuotoista ja tarkempaa tietoa sovelluksen paikkatietokohteista. Wiki-sivuston käyttö jäi kuitenkin vähäiseksi, koska prototyypin testaukseen liittyvässä käyttötilanteessa ei ollut mielekästä porautua yksityiskohtaiseen kohdetietoon. MediaWiki-ohjelmisto on toteutettu PHP-ohjelmointikielellä ja se käyttää tiedon tallennukseen MySQL-tietokantaa
8 Prototyyppisovelluksen sisällöntuotanto Tässä luvussa kuvataan tutkimuksessa kehitetyn prototyyppisovelluksen käyttämiä pohjakartta-aineistoja sekä julkisista lähteistä siirretyn paikkatietoaineiston teknistä käsittelyä sovelluksen käyttämään muotoon. 8.1 Kartografinen sisältö Prototyyppisovellus käyttää taustakarttoina OpenStreetMapin ja Maanmittauslaitoksen taustakartta-aineistoja, jotka sovellus lataa rasterimuodossa ulkoisista rajapintapalveluista. Taustakarttojen päällä näkyvät karttasymbolit on muokattu julkisista kuvapankeista ladatuista kuvista. 8.1.1 Taustakartat OpenStreetMap-hanke tuottaa vektorimuotoisesta paikkatietoaineistostaan neljä erilaisin visualisointisäännöin (engl. rendering rules) kuvannettua rasteriaineistoa koko maapallon pinnan alueelta. Sovelluksen karttanäkymien pohjakarttana käytettiin oletustapauksessa Mapnik-karttatasoa, joka on OSM:n vektoriaineistosta nimensä mukaisesti tuotettu Mapnik-ohjelmistolla. Visualisointisäännöillä määritellään, mitkä kohteet tulevat kartalle näkyviin ja millaisen ulkoasun, kuten väri, karttasymboli ja koko, nämä kohteet saavat kartalla. Mikäli valmiit taustakartta-aineistot eivät sovi sovelluksen käyttöön on sovelluksen kehittäjien mahdollista kuvantaa vektoriaineisto myös omilla visualisointisäännöillään, mutta tällöin visualisointi on toteutettava itse tai alihankittava siihen erikoistuneelta palveluntarjoajalta. Käytetty OSM-taustakartta-aineisto ei ollut sovelluksen ulkoasun ja käytettävyyden kannalta optimaalinen, mutta prototyyppivaiheessa ei katsottu mielekkääksi omien visualisointipalveluiden toteuttamista ja ylläpitoa. (OpenStreetMap-yhteisö) Apps4Finland-kilpailun osallistujilla oli mahdollisuus käyttää maksutta Maanmittauslaitoksen (MML) WMS-rajapinta-aineiston kautta saatavaa rasterikartta-aineistoa. Sovellukseen lisättiin mahdollisuus käyttää OpenLayers-rajapinnan suoraan tukemien OpenStreepMap-taustakarttojen lisäksi käyttää myös MML:n taustakarttoja, joiden koordinaattijärjestelmänä oli ETRS-TM35FIN. Johtuen sovelluksen alun perin käyttämien OSM-taustakarttojen ja MML:n karttojen eri koordinaattijärjestelmästä, MML:n karttojen useista erimittakaavaisista karttatasoista sekä MML:n karttojen salasanasuojauksesta jouduttiin sovellukseen tekemään useita muutoksia MML:n karttojen käyttämiseksi. Näistä merkittävimpiä olivat mittakaavatason mukaisen tausta-aineiston valitseva toiminnallisuus sekä tausta-karttojen päälle piirrettävien kohteiden koordinaattimuutosten hallintaan käytetyn proj4-kirjaston käyttöönotto. 37
LUKU 8. PROTOTYYPPISOVELLUKSEN SISÄLLÖNTUOTANTO 38 (Suomen Verkkodemokratiaseura ja Forum Virium) 8.1.2 Kohteiden karttasymbolit Kohteiden karttasymbolit haettiin valtaosin julkisista kuvapankeista, kuten Icons etc ja Clker.com. Näiden palveluiden lisenssiehdot sallivat kuvien vapaan käytön sovelluksissa (Mysitemyway Design Team, 2011; Clker.com yhteisö ja Rolera LLC, 2011). SVG-vektorimuodossa (engl. Scalable Vector Graphics) olleet symbolit muutettiin rasterimuotoon Inkscape-ohjelmalla. Rasterimuodossa olleet kohteiden kuvasymbolit muokattiin kuvankäsittelyohjelmalla mustavalkoisiksi valkotaustaisiksi png-muotoisiksi kuviksi. 8.2 POI-aineistot Ulkoisista lähteistä ladattujen aineistojen hyödyntämiseksi ladatuille paikkatietotiedostoille tehtiin teknisiä, sisällöllisiä ja koordinaattijärjestelmiin liittyviä muunnoksia. Sovelluksen tärkeimpiä POI-aineistoja ovat Suomen ympäristökeskuksen ja Museoviraston paikkatietoaineistot. Lisäksi sovellus mahdollistaa paikkatietoaineistojen yhteisöllisen lisäämisen ja kommentoinnin. 8.2.1 Tiedosto- ja koordinaattikonversiot GPS-satelliittien ratatiedot (engl. broadcats ephemerides) ovat WGS84-järjestelmässä ja GPS-paikannuksessa on käytettävä tämän kanssa yhteensopivia koordinaatistoja. Myös tässä työssä kehitetty prototyyppisovellus tallentaa kohteiden koordinaatit WGS84-muodossa. Vuonna 1999 hyväksytty EUREF-FIN on ETRS89-koordinaattijärjestelmän kansallinen realisaatio ja siten yhteensopiva WGS84-koordinaattijärjestelmän kanssa. Useat valtakunnalliset organisaatiot ovat jo siirtyneet käyttämään EUREF-FIN-järjestelmää aikaisemmin käyttämänsä KKJ:n sijaan. Muun muassa uudet maasto- ja peruskartat painetaan nykyään EUREF-FIN-koordinaatistossa. Käytöstä vähitellen poistuva vuonna 1970 käyttöönotettu KKJ-koordinaatisto ei ole yhteensopiva WGS84-järjestelmän kanssa. (Häkli et al., 2009, s.35) 8.2.2 ESRI Shapefile -muunnokset ESRI Shapefile on Environmental Systems Research Instituten (ESRI) määrittämä tilatiedon (eng. spatial) tallentamiseen tarkoitettu tiedostomuoto. Tiedostomuoto voi tallentaa piste-, viiva- ja aluetyyppisiä geometrisiä kohteita ja näiden kohteiden attribuuttitietoa. Attribuuttitiedot tallennetaan varsinaisista Shape-tiedostoista erillisiin dbase-muotoisiin tiedostoihin.(environmental Systems Research Institute, 1998) Siirrettäessä ulkoisista paikkatietolähteistä tullutta ESRI Shapefile -muotoista aineistoa prototyyppisovelluksen käyttöön muunnettiin aineisto ensin Python-kielisellä Ogr2osm-muunnosohjelmalla OpenStreepMap-projektin käyttämäksi XML-muotoiseksi.osm-tiedostoksi. Ogr2osm käyttää konversiossa GDAL-ohjelmakirjaston (Geospatial Data Abstraction Library) OGR-moduulia (OpenStreetMap-yhteisö, 2011). GDAL on Open Source Geospatial Foundationin
LUKU 8. PROTOTYYPPISOVELLUKSEN SISÄLLÖNTUOTANTO 39 julkaisema avoimeen lähdekoodiin perustuva rasterimuotoisen paikkatiedon konversioihin tarkoitettu ohjelmakirjasto (The Open Source Geospatial Foundation, 2011). Kutakin muunnosta varten luotiin oma Python-kielinen käännösfunktio, jonka avulla Shapefile-muotoisessa tiedostossa olleet geometristen kohteiden attribuutit muutettiin OpenStreetMap-muodon käyttämiksi tunniste-arvo-pareiksi (engl. key-value pair). Ogr2osm-ohjelmalla ei pystytty tekemään koordinaattimuunnoksia KKJ-järjestelmässä oleville aineistoille, vaan näiden koordinaattimuunnoksissa käytettiin erillistä tutkimuksen tekijän kirjoittamaa proj-ohjelmaa hyödyntävää apuohjelmaa. 8.2.3 Suomen ympäristökeskuksen aineistot Suomen ympäristökeskuksen Oiva-palvelun paikkatietoaineistosta siirrettiin prototyyppisovelluksen tietokantaan luonnon virkistyskäyttömahdollisuuksia kuvaavaa paikkatietoaineistoa. Tässä aineistossa on retkeilijöitä ja ulkoilijoita palvelevia pistemäisiä kohteita, kuten uimapaikkoja ja autiotupia, murtoviiva-aineistoja, kuten ulkoilu- ja retkeilyreittejä sekä monipolygoni-aineistoja, kuten kansallispuistot ja virkistysalueet. Prototyyppisovellukseen siirrettiin pääsääntöisesti vain pistemäisiä kohteita. Aineistoa ei päivitetä säännöllisesti ja tarkasteluhetkellä 11.10.2011 aineiston joidenkin osien päivityksestä olikin miltei 3 vuotta. Aineiston koordinaattijärjestelmänä on KKJ ja tallennusmuotona ESRI Shapefile. Ogr2osm-muunnosohjelma ei kyennyt konvertoimaan Shapefile-tiedoston konvertoinnin yhteydessä siirtotiedostossa olleiden kohteiden KKJ-muodossa olleita koordinaatteja WGS84-järjestelmään. Tätä koordinaattimuunnosta varten työn tekijä kehitti Java-ohjelmointikielellä apuohjelman, jolla KKJ-muotoiset koordinaattien arvot luettiin XML-muotoisesta tiedostosta ja konvertoitiin WGS84-muotoon käyttäen hyväksi Proj.4-kirjastossa olevaa proj-ohjelmaa lukupuskurin täytyttyä. Proj.4-kirjasto on Yhdysvaltain geologisen tutkimuslaitoksen (engl U.S. Geological Survey) ylläpitämä kartografisiin projektiomuunnoksiin tarkoitettu ohjelmakirjasto (Proj.4-kehittäjäyhteisö, 2011). Koordinaattimuunnoksen jälkeen ohjelma kirjoittaa tulokset toiseen.osm-muotoiseen XML-tiedostoon. Tämän jälkeen XML-muotoinen tiedosto avattiin Microsoft Excel -taulukkolaskentaohjelmalla. Taulukkolaskentaohjelmassa poistettiin XML-notaatiossa käytetyt merkinnät ja muokattiin tiedoston datasarakkeiden arvoja prototyypin tietokantakuvauksen mukaisiksi. Kohdetiedoista muodostettiin taulukkolaskentaohjelman funktioilla SQL-lauseita, jotka suorittamalla tiedot lisättiin prototyyppisovelluksen MySQL-tietokantaan. 8.2.4 Museoviraston muinaisjäännösrekisteri Museoviraston muinaisjäännösrekisterin tiedot ladattiin tutkimus- ja opetuskäyttöön tarkoitetusta Paituli-palvelusta (CSC - Tieteen tietotekniikan keskus, 2011). Lähdetiedot olivat Shapefile -muodossa ja koordinaattijärjestelmänä aineistossa käytettiin ETRS-TM35FIN-koordinaatistoa. Ogr2oms-ohjelma tunnisti aineiston koordinaattijärjestelmän ja teki muunnoksen automaattisesti WGS84-järjestelmään. XML-muotoinen tulostiedostosta muokattiin
LUKU 8. PROTOTYYPPISOVELLUKSEN SISÄLLÖNTUOTANTO 40 taulukkolaskentaohjelmalla siirtotiedosto, joka luettiin sovelluksen tietokantaan MySQL-järjestelmän load data -komennolla. 8.2.5 Natura-luontotyyppiaineistot Natura-luontotyyppiaineistossa alue, esimerkiksi kansallispuisto, on jaettu pieniin lohkoihin, joiden luontotyyppi eli biotooppitieto on kuvattu lohkon ominaisuustiedoissa. Natura-luontotyyppejä ovat esimerkiksi pikkujoet ja purot, karut kirkasvetiset järvet sekä lehdot. Metsähallitukselta saatiin lupa tutkimusalueen, Nuuksion kansallispuisto ja Pallas-Yllästunturin kansallispuisto, biotooppiaineiston käyttöön. Aineisto saatiin Metsähallitukselta ESRI Shapefile -muodossa. Saatu aineisto muunnettiin konvertointiohjelmilla.osm-muotoisiin XML-tiedostoihin. Prototyyppitestauksen kannalta aineisto arvioitiin kuitenkin sellaiseksi, että vain hyvin harva käyttäjä olisi pystynyt arvioimaan sen mielekkyyttä lyhyen haastattelun aikana. Tämän takia aineistoa ei viety varsinaiseen prototyyppiin. 8.3 Yhteisöllinen sisältö Prototyyppisovellus mahdollistaa palvelun käyttäjille yhteisöllisen sisällön tuottamisen. Yhteisöllisen sisällön lisäyksiin käyttäjän pitää olla tunnistautunut Facebook-tunnuksillaan. Käytännössä tämä sisältö voi olla uusia POI-kohteita sekä olemassa olevien kohteiden kommentointia ja arvostelua. Uuden kohteen lisäyksessä käyttäjä valitsee kohteen luokittelutiedon annetuista vaihtoehdoista sekä tallentaa kohteen nimen sekä valinnaisesti tarkemman kuvauksen ja lisätietoja kohteesta kertovan webosoitteen. Sovellus esitäyttää POI-kohteen koordinaatit käyttäjän sijainnin perusteella, mikäli laite kykenee määrittämään sijainnin riittävällä tarkkuudella. Käyttäjä voi syöttää sijainnin myös manuaalisesti. Näyttökopio uuden kohteen lisäyksestä matkapuhelimen näytöllä on kuvassa 8.1. POI-kohteen ominaisuusnäytöllä käyttäjä voi kirjoittaa kohteista kommentteja, joita kutsutaan vieraskirjamerkinnöiksi autiotupien vieraskirjojen mukaan. Kohteita voi myös arvostella antamalla niille yhdestä viiteen Kuva 8.1: Uuden kohteen lisäys tähteä. Arvostelluista kohteista näytetään käyttäjälle kohteen arvostelujen keskiarvo. Käyttäjien tekemät lisäykset ja muutokset näkyvät sovelluksen Yhteisö-osion uutislistalla, joka on otsikoitu termillä Jutut. Juttulistan jutun valitsemalla käyttäjälle avautuu kyseisen POI-kohteen ominaisuusnäyttö.
LUKU 8. PROTOTYYPPISOVELLUKSEN SISÄLLÖNTUOTANTO 41 8.4 Linkitetty sisältö Sovellus voi näyttää POI-kohteen tietojen yhteydessä websivuun upotetussa kehyksessä (engl. frame) kohteen tai sen tyyppiin liittyvän websivun. Esimerkiksi Nuuksion alueella POI-kohteena olevan linja-autopysäkin aikataulutieto voidaan näyttää linkittämällä POI-kohde Helsingin seudun liikenteen (HSL) aikataulupalvelun pysäkkiaikatauluihin. Näyttökopio aikataulutiedoista kohdetiedoissa on kuvassa 8.2. Sienipaikkojen tietoja näytettäessä kohteen tietojen yhteydessä näytetään kyseisen sienilajin kuvaustiedot Wikipediassa. Kuva 8.2: Linja-aikataulut POIkohdetiedoissa.
9 Käyttäjätutkimuksen toteutus ja tulokset Tässä luvussa käsitellään prototyyppisovelluksen avulla toteutettua käyttäjätiedon keruuta eri tutkimusmenetelmillä sekä näin saatuja tuloksia. Tutkimusmenetelminä käytettiin kehittäjän maastossa tekemää kenttätestausta, käyttäjähaastatteluja, sovellukseen liitettyä kyselyä, käyttölokin keruuta sekä ryhmäkeskusteluja. 9.1 Kenttätestaus Kuva 9.1: Kenttätestausta Nuuksion kansallispuistossa Kehitysvaiheessa sovellusta testattiin toimistossa Mac OS X ja Windows-ympäristöissä toimivilla selainohjelmilla sekä Android ja Apple ios -mobiililaitesimulaattoreilla. Sisätiloissa ei kuitenkaan pystytty simuloimaan todellista maastossa tapahtuvaa käyttötilannetta erityisesti käyttäjän sijaintiin tiiviisti liittyvän sovelluslogiikan osalta. Tämän takia sovellukselle tehtiin kenttätestausta ulkona käyttäen useita eri puhelin- ja taulutietokonemalleja. Käytetyt mobiililaitemallit on lueteltu taulukossa 9.1. Tässä työssä kenttätestausta teki pääasiassa tutkimuksen tekijä, joka oli myös prototyyppisovelluksen kehittäjä. Kenttätestausta tehtiin pääosin Nuuksion kansallispuistossa sekä puistoissa Helsingissä. Maastossa tapahtuneessa kenttätestauksessa havaittiin, että tarkkaan paikannukseen tarvittavan GPS-paikannussignaalin saanti kesti usein useita minuutteja ja joissain paikoissa signaalia ei saatu lainkaan edes viidessä minuutissa. Maastotestauksessa havaittiin myös, että siirryttäessä paikasta toiseen sovellus myös menetti usein GPS-paikannussignaalin ja siirtyi käyttämään mobiiliverkon tukiasemaan perustuvaa paikannusta. Tämän testaaja oletti 42
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 43 Taulukko 9.1: Kenttätestauksissa käytetyt mobiiliympäristöt Laite Käyttöjärjestelmä Selain Nokia E7-00 älypuhelin Symbian 3 Opera Mobile v. 11.1 1 Apple ipad 1 taulutietokone ios v 4.x Safari Mobile 2 Apple iphone 4 älypuhelin ios v 4.x Safari Mobile 2 Samsung i5800 älypuhelin Android 2.2 Android 2.2 2 1 erikseen asennettu selainohjelma 2 käyttöjärjestelmän vakioselainohjelma ensisijaisesti johtuvan kulkureitin ympäristössä olevan kasvillisuuden aiheuttamasta katveesta. Verkkoperustaisen paikannuksen antaman sijaintitiedon todettiin olevan huomattavan epätarkka poiketen eräässä testitilanteessa Nuuksiossa noin kilometrin todellisesta sijainnista. Sovellukseen kehitettiin paikannustiedon luotettavuutta parantava algoritmi, jotta satelliittipaikannuksen aikaisemmin saamaa kohtuullisen tarkkaan sijaintitietoa pystyttäisiin hyödyntämään myös silloin, kun GPS-signaalin vastaanotto on tilapäisesti katkennut. Sovelluksen saamassa sijaintitiedossa oli mukana arvio sen tarkkuudesta. Sovellus otti uuden sijaintitiedon käyttöön ainoastaan, mikäli se oli aikaisempaa sijaintitietoa tarkempaa. Käytössä olevan sijaintitiedon tarkkuusarvoa muutettiin ajan funktiona eli mitä vanhempi sijaintitieto oli, sitä huonommaksi sen tarkkuus arvioitiin. Tarkkuuden aikariippuvana heikkenemänä käytettiin arviota tyypillisestä kävelynopeudesta. Jos esimerkiksi alkuperäinen sijaintitiedon tarkkuus oli 20 metriä, niin 5 minuutin kuluttua tiedon tarkkuutena pidettiin 270 metriä käytettäessä kävelynopeutena 3 km tunnissa eli 250 metriä 5 minuutissa. Algoritmin käytön todettiin parantavan käyttäjälle annettavaa sijainti-informaatiota silloin, kun GPS-paikannuksen saanti oli epäluotettavaa. Algoritmin käyttökelpoisuus riippuu osaltaan siitä, miten hyvin parametrina asetettava etenemisnopeus vastaa retkeilijän todellista nopeutta. GPS paikannussignaalin tarkkuuden ja saantinopeuden todettiin myös vaihtelevan käytettävästä mobiililaitteesta riippuen. Esimerkiksi Apple ipad 1 ios 4.3 -laitteella paikannussignaalin saanti sovelluksen käyttöön todettiin epäluotettavaksi jopa avoimilla paikoilla. Käytettäessä laitteen uudempaa versiota (ipad 2 ios 5) paikannussignaalin tarkkuus ja saantinopeus olivat merkittävästi parempia. Mahdollisia syitä heikolle paikannettavuudelle on useita. Syy voi liittyä mobiililaitteen laitteiston ominaisuuksiin: laitteiston heikko kyky vastaanottaa GPS-signaalia, joka johtuu esimerkiksi huonosta antennien suunnittelusta tai laitteen metallikuoren aiheuttavasta radiosignaalin vaimennuksesta. On myös mahdollista, että selaimen paikannustietoa tarjoava W3C Geolocation API-rajapinta ei pysty täysin hyödyntämään laitteiston paikannusominaisuuksia. Tästä saatiin viitteitä ipad-taulutietokoneella tehdyissä testeissä. Kun laitteeseen käynnistettiin samanaikaisesti prototyyppisovelluksen kanssa erillinen GPS-paikannustietoa hyödyntävä natiivisovellus, näytti myös prototyyppisovellus
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 44 saavan tarkan paikannustiedon käyttöönsä nopeammin kuin ilman toisen sovelluksen käynnistystä olisi tapahtunut. Paikannustiedon tarkkuusongelmat voivat johtua osittain myös prototyyppisovelluksesta. Selaimen paikannuspalvelujen virheellinen kutsuminen tai ongelmat saadun sijaintitiedon käsittelyssä ovat voineet estää parhaan mahdollisen paikannustiedon saannin. Kenttätestauksessa havaittiin, että Opera Mobile v.11.1 -selaimella karttanäkymän zoomausnapit eivät reagoineet käyttäjän painalluksiin. Tämän takia sovellusta muutettiin niin, että se ei näyttänyt kyseisiä nappeja karttanäkymässä käytettäessä sovellusta tällä selainversiolla. Uudemmalla selainversiolla, versio 11.5, käytettäessä ongelmaa ei esiintynyt ja ehdollinen nappien näkyvyyden eliminoiminen poistettiin sovelluksesta. 9.2 Haastattelut Prototyyppisovelluksen käyttäjähaastatteluja oli tekemässä yhteensä kolme henkilöä, joista kaksi haastattelijaa oli OFE-hankkeen kesätyöntekijöitä. Näiden lisäksi tämän tutkimuksen tekijä kävi tekemässä haastatteluja Nuuksion kansallispuistossa yhden kerran. Tämän työn tekijä ja ohjaaja suunnittelivat yhdessä alustavan haastattelurungon, jota muokattiin myöhemmin tekijän ja OFE-hankkeen projektipäällikön ja haastattelijoiden suunnittelupalavereissa. Haastattelurunko on liitteessä I. Heinäkuun alussa julkaistiin prototyyppisovelluksen ensimmäinen versio. Haastatteluja prototyypin käytöstä tehtiin heinäkuun aikana vain muutama. Syyksi tähän haastattelijat näkivät sen, että prototyypin käyttäjähaastattelut olivat vain osa heidän haastattelutehtäväänsä ja vakiohaastattelua pidempikestoisempi. Tämän takia kävijöille tehtiin useimmiten vain vakiohaastattelu. Elokuussa haastattelijat varasivat erikseen aikaa prototyypin käyttäjähaastattelujen tekemiseen eli tekivät joillakin haastattelukerroilla vain prototyypin käyttöön liittyviä haastatteluja, jolloin haastattelutuloksia saatiin huomattavasti aikaisempaa enemmän. Haastatteluista ei saatu haastateltavien demografisia tietoja, kuten sukupuolta, ikäryhmää tai koulutukseen ja ammattiin liittyviä tietoja, mikä vähensi osittain saatujen haastattelutulosten käyttöarvoa. Vastausten perusteella käyttäjät kokivat sovelluksen yleisesti helposti opittavana, mutta kartan zoomaus ja karttanäkymän käsittely yleensä tuotti ongelmia ainakin joillekin käyttäjille. Koska sovellus toimi yhdellä websivulla, aiheutti selaimen paluunapin painallus välittömästi sovelluksesta poistumisen. Paluu-nappi olikin selkeästi näkyvillä ainakin yleisimmässä testiselaimessa Opera Mobilessa. Useille käyttäjille erheellinen paluu-napin painaminen olikin aiheuttanut sovelluksesta poistumisen, vaikka tarkoituksena olikin ilmeisesti vain edelliseen sovellusnäkymään palaaminen. Vaikka ulkoasua pidettiin useissa kommenteissa selkeänä, ainakin jotkut käyttäjät kokivat ylävalikon sekavana. Sovelluksen värimaailman toivottiin joissakin kommenteissa olevan rikkaampi. Haastateltavien mukaan prototypoitava palvelu sopii erityisesti nuoremmalle, sosiaaliseen mediaan tottuneelle sukupolvelle. Vastaajien demografiatietojen puutteellisuus tosin vaikeuttaa näiden kommenttien tulkintaa. Palvelua ehdotettiin
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 45 sovellettavan muun muassa ympäristökasvatukseen ja omatoimimatkailijoille. Haastattelujen perusteella tehtiin sovellukseen muutoksia käytettävyyden parantamiseksi. Haastattelujakson alussa sovelluksen käynnistymisaika koettiin hyvin pitkäksi niin haastateltavilta saatujen kommenttien kuin kenttätestauksenkin perusteella. Sovelluksen tekemiä palvelinpyyntöjä tehostamalla ja karttanäkymien alustuksen siirtämisellä myöhemmäksi saatiin sovelluksen käynnistysaikaa lyhennettyä merkittävästi. Haastateltavien toiveiden perusteella sovellukseen lisättiin myös POI-kohteiden vapaa tekstihaku sekä POI-listan rajaaminen oletuksena kahteenkymmeneen kohteeseen. Haastatteluista saadut käyttäjäkommentit ovat kokonaisuudessaan liitteessä J. 9.3 Kysely System Usability Scale (SUS) on vuonna 1986 kehitetty kymmeneen kysymykseen perustuva arviointimenetelmä. SUS-menetelmästä on tullut varsin suosittu arviointimenetelmä, sillä sitä pidetään varsin tehokkaana tapana saada yleiskuva järjestelmän käytettävyydestä. Menetelmän avulla voidaan arvioida kolmea ISO 9241-11 -käytettävyysstandardissa olevaa käytettävyyden osa-aluetta: käyttäjän kyky suoriutua tehtävästä järjestelmän avulla, järjestelmän avulla toteutettavien toimintojen vaatimat resurssit sekä subjektiivinen käyttäjätyytyväisyys. (Borsci et al., 2009) Tämän tutkimuksen käytettävyyskyselyä kehitettiin SUS-arviointimallia pohjana käyttäen. Käytettävyyden lisäksi kyselyssä tiedusteltiin käyttäjiltä heidän kiinnostustaan kuuteen eri paikkatietosisältöön sekä niiden täydentämiseen. Kuva kyselystä mobiililaitteen näytöllä on kuvassa 9.2 ja kysymyslomake kokonaisuudessaan on liitteessä D. Tutkimuksen käyttäjäkysely toteutettiin prototyyppisovellukseen lomakkeella, jonka toteutuksessa tavoiteltiin yksinkertaisuutta ja helppokäyttöisyyttä myös mobiililaitteilla käytettäessä. Käyttäjäkyselyn käytettävyysosio koostui seitsemästä väittämästä, joihin kuhunkin pyydettiin vastaamaan arvoilla yhdestä viiteen sen mukaan miten paljon käyttäjä oli samaa mieltä esitetyn väittämän kanssa. Esitetyt väittämät olivat: Opin sovelluksen käytön nopeasti. Sovellus toimii loogisesti. Sovelluksen ulkoasu on selkeä. Sovellus toimii nopeasti ja luotettavasti. Löysin hakemani tiedon helposti. Käytin sovellusta luottavaisin mielin. Tietoa on riittävästi retken toteuttamiseksi.
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 46 Syyskuun 2011 alussa lähetettiin sähköpostitse noin sadalle OFE-hankkeen yhteistyötaholle pyyntö osallistua prototyypin testaukseen sekä vastaamaan käyttäjäkyselyyn. Lisäksi sovellukseen lisättiin toiminto, joka muistutti käyttäjää ponnahdusikkunalla kyselyyn osallistumisesta. Potentiaalisille koekäyttäjille lähetetty sähköpostiviesti on liitteenä C. Kyselystä saatiin vastauksia varsin vähän, yhteensä vain kolme kappaletta. Viikon kuluessa sähköpostien lähettämisestä saatiin ainoastaan yksi vastaus käyttäjäkyselyyn. Tämän lisäksi kyselyyn saatiin kaksi vastausta marraskuussa sovelluksen osallistuessa avoimen datan sovelluksille tarkoitettuun Apps4Finland-kilpailuun. Näin pienestä vastausmäärästä ei voi tehdä juurikaan johtopäätöksiä sovelluksen käytettävyydestä. Kyselyssä esitettyjä paikkatietosisältöjä pidettiin yleisesti mielenkiintoisina. Sovellusta pidettiin myös helposti opittavana ja loogisena, mutta sovelluksen nopeutta ja teknistä luotettavuutta ei pidetty erityisen hyvänä. Tietoa retken toteuttamiseksi kokonaisuudessaan ei myöskään koettu Kuva 9.2: Käyttäjäkysely matkapuhelimen näytöllä. saatavan riittävästi sovelluksen kautta, mikä ei ollut prototyyppisovelluksen tavoitteenakaan. Vastaajat eivät antaneet vapaamuotoista palautetta tai kehitysideoita. Vastaukset on koostettu liitteeseen E. 9.4 Käyttöloki Sovelluksessa on käyttöloki, joka kirjaa käyttäjän tekemiä toimintoja. Luettelo kirjattavista toiminnoista on liitteessä A. Käyttäjän aktivoimista tapahtumista, kuten toimintojen käynnistämiseen valikosta tai kohteen valitsemiseen kohdelistasta, tallennetaan sovellukseen tapahtuman koodi, tapahtuma-aika sekä mahdolliset tarkentavat lisätiedot sovelluksen puskurimuistiin. Sovellus lähettää uudet lokitiedot järjestelmän tietokantaan tallennettavaksi 15 sekunnin välein sekä käyttäjän lopettaessa sovelluksen käytön. Sovellus tunnistaa käytön lopetuksen selaimen window.onunload() -tapahtumasta. Mikäli selain ei lähetä kyseistä tapahtumaa sovellukselle käytön lopetuksen yhteydessä, voivat sillä hetkellä
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 47 puskurimuistissa olevat lokitapahtumat jäädä kirjaamatta tietokantaan. Heti ensimmäisen kyselypyynnön jälkeen huomattiin, että käyttölokin analysoimiseksi tarvitaan myös tietoa eri käyttäjien tunnistamiseksi, jotta pystyttäisiin tunnistamaan montako kertaa kukin käyttäjä on käyttänyt sovellusta. Tämän takia sovellukseen lisättiin päätelaitteen yksilöivä tunniste, joka talletetaan päätelaitteen selaimen evästeeseen (engl. cookie). Tarkasteltavaksi otettiin vain sellaiset istunnot, jotka oli lisätty tämän toiminnon lisäyksen jälkeen. Käyttölokista suodatettiin ennen analysointia pois sellaiset istunnot, jotka tiedettiin liittyvän sovelluksen kehitystyöhön. Suodatuksessa käytettiin istunnosta kirjattua ip-osoitetta, selaintunnistetta (engl. user agent) ja Facebook-käyttäjätunnusta. Analysoitavat istunnot ovat noin kahden ja puoleen kuukauden ajalta 12.9-30.11.2011. Kaikista istunnoista kaksi kolmasosaa ajoittui viikoille 43-45, jolloin sovellus oli arvioitavana Apps4Finland -kilpailussa (Suomen Verkkodemokratiaseura ja Forum Virium)sekä esiteltävänä Paikkatietomarkkinoilla. Istuntojen viikottainen jakauma näkyy kuviossa 9.3, punaisella viivalla on kuvattu kaikkien istuntojen lukumäärä viikottain ja vihreällä viivalla mobiililaitteilla tehtyjen istuntojen lukumäärä. '!!" &!"!"#$%&''()*%+&,-&./0$%%"".* %!" $!",-.//." 012..3." #!"!" ()" (&" (*" $!" $'" $#" $(" $$" $+" $%" $)" $&" Kuva 9.3: Käyttölokin istuntojen jakauma viikkotasolla Aineistosta tarkasteltiin kolmea otosta: kaikki istunnot, mobiililaitteilla tehdyt istunnot sekä mobiililaitteilla tehdyt istunnot, joiden aikana oli tehty vähintään viisi kirjattavaa käyttäjäoperaatiota. Yhteensä analysoitavia istuntoja oli 252, joista 62 eli 25 % oli tehty mobiililaitteilla. Mobiililaitteilla tehdyistä istunnoista 22 eli 26 % oli sellaisia, joissa käyttäjä oli tehnyt vähintään viisi operaatiota. Tarkemmat tiedot lokitiedon analysoinnista on nähtävissä liitteessä B. Mobiililaitteilla tehdyistä istunnoista noin 50% oli tehty Android-käyttöjärjestelmää käyttävillä laitteilla ja 37 % Applen iphone ja ipad -laitteilla. Lopuissa istunnoissa käytettiin Opera-selainohjemistoa tai Symbian mobiilikäyttöjärjestemän vakioselainta. Istuntojen selainjakauma näkyy kuviossa 9.4, jossa vasemmanpuoleisessa kuviossa näkyvät kaikki selaimet ja oikeanpuoleisessa eriteltynä mobiiliselainten jakauma. Android- ja Apple-laitteita käyttäneiltä noin 60 %:lta saatiin tieto käyttäjän sijainnista loppujen kieltäessä sijaintitiedon lähettäminen joko yleisesti tai erikseen tältä sovellukselta. Symbian ja Opera-selaimilta tehdyistä istunnoista sijaintitietoa ei saatu joko käyttäjän kieltäessä tiedon lähettämisen tai selaimen teknisen rajoittuneisuuden takia.
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 48!"#$%&'$($)*$+%,-)&&.%/$%&+ +,%,#"( -.(*( /01$#0$#( 2'34&#$#( 56(*( 7881($"9:&;""4"( <(*( /?+@"A,>B"AC&0$D( E(*( :&;""4"G$4,":$1( -<(*( =0>#&">( 5-(*( 7881(:&;""4"( F(*(!"#$%&'( ))(*( Kuva 9.4: Käyttölokin istuntojen jakauma selainohjelmiston mukaan Käyttölokiin liittyvästä käyttäjän sijaintitiedosta puuttui tieto sijaintitiedon tarkkuudesta. Tämän takia ei pystytty selvittämään, onko tieto sijaintitiedon lähteenä yleisesti epätarkan sijaintitiedon antava matkapuhelinverkkoon tai laitteen ip-osoitteeseen perustuva paikannus vai tarkempi sijaintitiedon lähde, kuten GPS- tai lähiverkkopaikannus. Pistokokeenomaisesti sijaintitietoa tarkasteltuna suurin osa käytöstä näytti tapahtuneen kaupunkiympäristössä ja maastokäyttö muodosti vain pienen osan käyttötilanteista. Mahdollisissa myöhemmissä kehitysvaiheissa käyttöloki-toimintoa hyödynnettäessä on perusteltua lisätä sijaintitiedon tarkkuus lokiin tallennettavaan tietoon. Tarkastelujaksolla käyttäjä ei ollut kirjautunut yhdessäkään analysoitavassa istunnossa palveluun Facebook-tunnuksilla, eikä näin ollen myöskään käyttänyt vieraskirja- tai kohteen lisäys -toimintoja. Tässä kehitysvaiheessa ja pienellä otoskoolla ei katsottu mielekkääksi lähteä tunnistamaan lokiaineistosta tyypillisiä käyttöpolkuja. Lokiaineiston käyttökelpoisuuden arvioimiseksi haettiin kuitenkin sellaisista istunnoista, joissa oli vähintään neljä käyttäjäoperaatiota yleisimpiä lopetuspisteitä eli sellaisia toimintoja, joiden jälkeen käyttäjä lopetti istunnon käytön. Yleisimpiä istunnon viimeisimmäksi tallennettuja käyttäjäoperaatioita olivat kohteen valitseminen aluenäkymästä, alueen valitseminen päänavigaatiosta sekä alueen valitseminen aloitusnäytöstä. 9.5 Ryhmäkeskustelut 9.5.1 Suunnittelu ja toteutus Sovelluksen on suunniteltu osallistuvan yhteensä kolmeen OFE-hankkeen ryhmäkeskusteluun, mutta aikataulusyistä tähän työhön voidaan raportoida vain yksi ryhmäkeskustelu. Kuhunkin keskusteluryhmään pyritään saamaan edustajia
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 49 seuraavista ryhmistä: kuluttajat työnsä puolesta kartoista ja matkailusovelluksista kiinnostuneet retkeilyn ja ulkoilun ammattilaiset ja opiskelijat, kuten eräoppaat Päävastuu ryhmäkeskustelujen toteuttamisesta on tutkimusyrityksellä, joka valittiin OFE-hankkeen tekemän julkisen tarjouskilpailun perusteella. Ensimmäinen vuoden 2011 elokuussa tehty tarjouskilpailu jouduttiin uusimaan, sillä siinä ei saatu yhtään muodollisesti tarjouspyynnön täyttävää tarjousta. Tarjouskilpailun uusiminen viivytti osaltaan ryhmäkeskustelujen toteutusta. Ryhmäkeskustelujen tavoite oli määritelty hankkeen tarjouspyyntöasiakirjoissa ja tarjoavia yrityksiä pyydettiin antamaan omat ehdotuksensa haastattelujen toteutustavoista ja käytetyistä menetelmistä. Tarjouskilpailussa tutkimuksen toteuttajaksi valittiin parhaiten tarjouspyynnössä määritellyt kriteerit täyttänyt yritys. Kun tutkimusyritys oli valittu, ryhmäkeskustelujen käytännön suunnittelu aloitettiin tutkimusyrityksen ja OFE-hankkeen välillä. Myös tämän työn kirjoittaja oli mukana haastattelujen suunnittelussa ja toteutuksessa, muun muassa tutkimusyrityksen ja OFE-hankkeen väliseen suunnittelupalaveriin osallistumalla sekä itse ryhmäkeskustelussa tarkkailijana ja teknisenä fasilitaattorina. Raportoivassa keskusteluryhmässä oli kahdeksan osallistujaa ja ryhmässä oli yhtä paljon naisia ja miehiä. Ryhmä edusti kuluttajia ja sen jäsenet oli rekrytoitu tutkimusyrityksen paneelista. Valituille paneelin jäsenille lähetettiin kutsu osallistua aktiviteettireitistöjä kehittävän hankkeen ryhmäkeskusteluun. Koska keskustelun aihe oli kerrottu kutsun yhteydessä ja osallistuminen perustuu vapaaehtoisuuteen, voidaan olettaa, että osallistujiksi valikoitui ihmisiä, joilla oli keskimääräistä kuluttajaa enemmän kiinnostusta tutkittavaan aihepiiriin. Osallistujille annettiin palkkioksi lahjakortti. Keskustelu järjestettiin tutkimusyrityksen tiloissa, joissa keskustelijoilla oli käytössä kuusi kannettavaa tietokonetta, taulutietokone ja kaksi älypuhelinta. Tutkimusyrityksestä olevalla tutkimuksen vetäjällä eli moderaattorilla oli käytössään tietokoneeseen liitetty videoprojektori, jota hän käytti tutkimuksen ja tutkittavien sovellusten esittelyssä sekä nauhuri, jolla hän nauhoitti keskustelun myöhempää purkua varten. Ryhmäkeskusteluiden tuloksena julkaistaan tutkimusyrityksen tekemä julkinen tutkimusraportti. Ryhmäkeskustelun alussa moderaattori esitteli lyhyesti tutkimuksen teeman, tutkimusyrityksen ja kertoi tutkimuksen luottamuksellisuudesta. Luottamuksellisuus tarkoittaa tässä tutkimuksessa, ettei osallistuneiden henkilöllisyyttä paljasteta tutkimusraportissa eikä henkilöiden antamia vastauksia ja kommentteja voi yhdistää raportin perusteella henkilöön. Moderaattori myös kannusti osallistujia vapaaseen kommentointiin. Ryhmäkeskustelussa keskusteltiin neljästä eri verkkopalvelusta tai sovelluksesta, kustakin vajaa puoli tuntia. Kolme muuta keskustelun aiheena ollutta sovellusta olivat Pohjois-Savon retkeilykartta (http://www.infokartta.fi/psavo/), Sveitsin pyöräilykartasto Veloland
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 50 (http://www.veloland.ch/) ja Helsingin seudun liikenteen kevyenliikenteen reittisovellus (http://pk.hsl.fi/). Tässä työssä tehty Retkeni.fi-prototyyppisovellus esiteltiin ryhmälle sovelluksista viimeisenä. Sovelluskohtaisten keskustelujen jälkeen käytiin lyhyt loppukeskustelu. 9.5.2 Käyttäjäkommentit sovelluksesta Toiminnallisuuteen ja sisältöön liittyvissä kommenteissa pidettiin yhteisöllisyyden ideaa hauskana ja mainittiin, että Facebookia voisi käyttää myös vaellusporukan kokoamiseen, sillä vaeltamaan ei ole hyvä lähteä yksinään. Reiteistä toivottiin suunnitteluvaiheessa tietoa arvioidusta ajallisesta kestosta sekä retkellä ollessa kuljetusta ja jäljellä olevasta matkasta. Yksi keskustelija totesi Sports Tracker -sovelluksen muistuttavan tätä sovellusta ja hän piti keskusteltavan sovelluksen ideaa hyvänä. Käytettävyyteen ja ulkoasuun liittyvissä kommenteissa nousi esiin muun muassa se, että ainakin yksi käyttäjä koki ylävalikoissa olevan alue-termin ja valikkorakenteen yleensä sekavana. Sovelluksen ulkoasuun toivottiin myös enemmän värejä. Yksi käyttäjä totesi Pallas-Yllästunturin kansallispuiston alueen historiakohteista, että listassa on liian paljon kohteita, joiden nimet eivät kerro käyttäjälle mitään. Hän toivoi kohteiden ryhmittelyä. Yksi käyttäjä totesi myös, että sovelluksesta huomaa, ettei se ole vielä valmis. Yksi käyttäjä koki kartan sotkuiseksi etenkin zoomatessa ja totesi Nokian puhelinten vektorikarttojen olevan selkeämpiä. Keskustelun aikana keskustelua seurannut tämän työn tekijä huomasi, että sovelluksen kohdenäytöllä ollut linkki johdatti kaksi käyttäjää Kansalaisen karttapaikka -sivustolle, josta he eivät päässeet helposti takaisin sovellukseen, vaan jäivät käyttämään sitä mieltäen sen osaksi testattavaa kokonaisuutta. Linkki poistettiin sovelluksesta ensimmäisen ryhmäkeskustelun jälkeen. 9.5.3 Käyttäjäkommentit loppukeskustelussa Kaksituntisen ryhmäkeskustelun lopussa käytiin lyhyt loppukeskustelu, jossa vedettiin yhteen esitellyistä sovelluksista esille tulleita ajatuksia. Sveitsiläistä Velolandia pidettiin hyvänä retkensuunnittelupalveluna ja sen visuaalisuutta ja monipuolista tietosisältöä arvostettiin. Muiden sovellusten ulkoasua pidettiinkin tylsänä. Toisaalta Velolandin käyttöliittymä sai pientä kritiikkiä sekavuudesta, jonka katsottiin johtuvan liian suuresta pienten kuvaelementtien käytöstä. Webpohjaisessa palvelussa suunniteltujen reittien siirtoa mobiilipalveluun käytettäväksi varsinaisen retken aikana nähtiin tärkeänä ominaisuutena. Mobiilisovelluksilta yleisesti toivottiin erityisen hyvää käytettävyyttä, sillä tietoa maastossa ei haluta etsiä kauan. Hyödylliseksi mobiilisovelluksen ominaisuudeksi mainittiin muun muassa se, että käyttöliittymä pystyy hakutoiminnoissa näyttämään vastauksia jo lyhyenkin hakuvihjeen perusteella, ettei koko hakusanaa tarvitse kirjoittaa haun toteuttamiseksi. Mobiilikartalla toivottiin näkyvän sijainnin paikallistamista helpottamaan symboleja tärkeistä maamerkeistä ja tienviitoista. Mobiilikarttojen mahdollisuuksiin maasto-olosuhteissa ei kuitenkaan
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 51 varauksetta luotettu, vaan ainakin yksi keskustelija kertoi luottavansa enemmän paperikarttoihin, jotka eivät ole riippuvaisia akun lataustasosta, tuntemattomilla alueilla. Toisaalta keskustelijoilla oli myös positiivisia käytännön kokemuksia mobiilikartan käytöstä maastossa. 9.6 Tutkimusaineiston tarkastelu Tässä alaluvussa tarkastellaan kerätyn tutkimustiedon luotettavuutta, oikeellisuutta, otoksen edustavuutta sekä eri menetelmillä saatujen tulosten mahdollista keskinäistä tukea tai ristiriitaa. 9.6.1 Kenttätestaus Kenttätestauksessa, jossa sovelluksen kehittäjä kokeili sovellusta maastossa, päästiin nopeasti havainnoimaan ja korjaamaan tekniseen toimivuuteen liittyviä asioita, kuten paikannuksen toimivuutta. Kenttätestauksessa sovelluksen kehittäjän on kuitenkin vaikea samaistua käyttäjän rooliin, vaan hän pureutuu yksittäisten teknisten ongelmien ratkaisuun. Ainakin sovelluksen myöhemmissä kehitysvaiheissa on perusteltua käyttää kenttätestauksessa myös henkilöitä, jota eivät ole olleet tekemässä sovelluksen suunnittelu tai kehitystyötä. 9.6.2 Haastattelut Käyttäjähaastattelut toivat esille useita käyttöön liittyviä ongelmia, kuten käynnistyksen hitausongelman, ja käyttöliittymän ominaisuuksiin liittyviä toiveita. Vaikka osa näistä kehittämistarpeista tunnistettiin jo kehittäjän tekemässä kenttätestauksessa, oli haastatteluista saadulla palautteella hyötyä erityisesti esille tulleiden tarpeiden priorisoinnissa, sillä sovelluksen kehittäjän on monesti vaikea arvioida yksittäisen ongelmakohdan merkitystä järjestelmän käyttäjälle. Retkeilyreittien varrella tehdyt haastattelut mahdollistavat prototyyppisovellusta kokeileville käyttäjille hyvin pitkälle todellista käyttötilannetta muistuttavat olosuhteet, minkä voi olettaa nostavan esille sellaisia kehitystoiveita ja painotuksia, joita ei esimerkiksi sisätiloissa tehdyissä haastatteluissa havaittaisi. Haastateltavien taustatietojen puuttuminen vaikeuttaa kuitenkin otoksen edustavuuden arviointia. Haastattelutilanteen ja siinä käytettävien lomakkeiden parempi ennakkosuunnittelu sekä raportoinnin ohjeistus olisivatkin voineet parantaa muun muassa haastatteluista saatuja demografiatietoja. 9.6.3 Käyttöloki Käyttölokista saatu tieto osoittautui mielenkiintoiseksi, mutta tässä vaiheessa protypointia se ei tuottanut juurikaan lisätietoa, sillä valtaosa käytöstä ei tapahtunut käyttötilanteessa, johon sovellus on tarkoitettu. Myöhemmässä vaiheessa, kun käyttöliittymä on vakiintunut ja käyttötilanteet vastaavat paremmin todellista käyttötilannetta, voidaan olemassa olevaan käyttöloki-toiminnallisuutta hyödyntää olettaen, että siitä saada kehitystyötä konkreettisesti hyödyntävää käyttäjätietoa.
LUKU 9. KÄYTTÄJÄTUTKIMUKSEN TOTEUTUS JA TULOKSET 52 9.6.4 Kysely Kokonaisuudessaan kyselystä ei saatu käyttäjiltä tutkimuksen kannalta merkityksellistä uutta tietoa vastausmäärän jäädessä varsin vaatimattomaksi. Tässä tutkimuksessa saatujen tulosten perusteella on oletettavaa, ettei vastaavantyyppisellä kyselyllä ei voida kerätä mahdollisissa sovelluksen myöhemmissäkään kehitysvaiheissa kehitystyön kannalta merkityksellistä palautetta eikä tutkimustapaa voi pitää mielekkäänä. 9.6.5 Ryhmäkeskustelu Yhden ryhmähaastattelun perusteella ei saa kattavaa kuvaa toiminnallisuuteen tai sisältöön liittyvistä toiveista, mutta jo yksittäisten kommenttien avulla voidaan tunnistaa käytettävyyden ongelmakohtia. Tämän keskustelun perusteella todettiin muun muassa valikkorakenne sekä kohteiden nimeäminen ja ryhmittely tarkempaa tarkastelua vaativiksi käyttöliittymän mahdollisiksi kehityskohteiksi. Myös käyttäjien toimintaa havainnoimalla todettu käyttäjien ajautuminen toiseen sovellukseen tuli esille uutena, joskin varsin helposti korjattavana, käytettävyysongelmana. Myös muiden samassa tilaisuudessa tutkittujen palveluiden ryhmähaastatteluja seuraamalla sai paljon tietoa käyttäjien toiveista ja mielipiteistä. 9.6.6 Eri tutkimustapojen tuottamien tulosten vertailu Haastatteluissa ja ensimmäisessä ryhmäkeskustelussa saadut käyttäjäkommentit olivat hyvin samansuuntaisia. Molempien tutkimustapojen kautta havaittiin muun muassa mahdollisia käytettävyysongelmia ylävalikossa sekä yhteneviä kommentteja sovelluksen ulkoasusta sekä samantyyppisiä ideoita sovelluksen käyttöpotentiaalista. Tämän tutkimuksen perusteella voidaankin arvioida haastattelujen ja ryhmäkeskustelujen tulosten tukeneen toisiaan ja arvioida näiden menetelmien olevan mahdollisesti myös vaihtoehtoisia. Sinällään varsin vähäisen vastausmäärän saaneen kyselyn tuloksien voidaan nähdä myös pikemminkin tukevan kuin kyseenalaistavan edellämainituilla menetelmillä saatuja tuloksia. Koska käyttölokin keruulla saatiin tietoa varsinaisesta käytöstä muiden tutkimustapojen tuottaessa tietoa käyttäjien mielipiteistä, käyttölokin keruulla saatuja tuloksia ei voi varsinaisesti pitää muita tutkimustuloksia tukevana, vaan pikemminkin käyttölokin keruu tuo mahdollisesti sellaista täydentävää tietoa, jota muilla käytetyillä menetelmillä ei voi saada.
10 Johtopäätökset Tässä luvussa vedetään yhteen toteutetun tutkimuksen tuloksia niin sovelluksen toteutusteknologian, sisällön kuin käyttäjälähtöisen kehitysprosessinkin kannalta. 10.1 Teknologiset ratkaisut Tutkimuksessa todennettiin, että viimeisimmät webteknologiaan perustuvat standardit ja ohjelmistokehitysympäristöt mahdollistavat jo tutkimushetkellä käyttöliittymältään rikkaiden ja käytettävyydeltään korkealaatuisten mobiililaitteilla käytettävien paikkatietoa hyödyntävien sovellusten kehittämisen. Uusimmat mobiililaitteet, etenkin Android- ja Apple ios -pohjaiset älypuhelimet ja taulutietokoneet tukevat hyvin webteknologioihin perustuvia mobiilisovelluksia. Standardointityön keskeneräisyys ja kehitystyökalujen, kuten ohjelmakirjastojen, nopea kehitys ja vakiintumattomuus asettaa tosin haasteita käytettävien työkalujen valintaan. Vaikka sovelluksen tietoliikennettä optimoimalla voidaan nopeuttaa sen toimintaa ja tätä kautta parantaa käyttäjäkokemusta, voi tietoliikenneyhteyden hitaus kuitenkin olla käytettävyyttä rajoittava tekijä, mikäli sovellus vaatii tietojen hakuun ja päivitykseen aktiivisen tietoliikenneyhteyden. Toisaalta ulkomaalaisille käyttäjille tietoliikennekustannukset voivat nousta hyvinkin korkeiksi verkkovierailusta (engl. roaming) laskutettujen korkeiden maksujen takia. Näiden syiden takia ainakin oleellisimman sovelluksen käyttämän tiedon, esimerkiksi taustakartat ja POI-kohteet, lataamisen mahdollistaminen esimerkiksi langattoman lähiverkon kautta ennen maastoon lähtöä on perusteltua. Prototyypin kehitystyön aikana testattiin alaluvussa 3.7 kuvattuja ohjelmistokirjastoja offline-ominaisuuksien toteuttamiseksi ja todettiin, että näiden ominaisuuksien toteuttaminen on mahdollista käytössä olleilla kehitysvälineillä, vaikkei ominaisuus ollutkaan käytössä käyttäjätesteissä olleissa versioissa. 10.2 Sisältö Tutkimuksessa havaittiin, että paikkatiedon kerääminen palvelun käyttöön eri lähteistä voi vaatia huomattavia ponnisteluja niin teknisten, sisällöllisten kuin hallinnollisten kysymysten ratkaisemiseksi. Aineistojen tehokas siirto ja etenkin niiden muuntaminen järjestelmien välillä edellyttää ainakin jonkintasoista paikkatietokäsitteistön hallintaa ja työkaluohjelmistojen tuntemusta. Koska tietojen kuvaustapa poikkeaa eri järjestelmissä voi lähdeaineistojen kuvaaminen lopullisen palvelun käyttämään muotoon vaatia merkittävän työpanoksen etenkin, jos samantyyppistä tietoa kerätään useista järjestelmistä. Työn aikana kertyneen osaamisen avulla kuvatun kaltainen paikkatietoaineistojen tekninen siirto ja muokkaus pystyttäisiin toteuttamaan huomattavasti tehokkaammin kuin tutkimuksen aikana, jolloin käsitteistö ja työkalut olivat tämän työn tekijälle uusia. 53
11 Pohdinta Tässä luvussa tarkastellaan tutkimuksen kautta erityisesti sen tekijälle kertynyttä uutta tietoa ja kokemusta sekä pohditaan prototypoidun palvelun jatkokehitysmahdollisuuksia ja jatkokehityksen suuntaamista. 11.1 Tutkimuksen kautta tullut kokemus Tämän työn kautta saatiin kokemusta niin uusimpien webteknologioiden soveltamisesta paikkatietoa hyödyntävän mobiilisovelluksen toteutuksessa kuin käyttäjätiedon keräämisestä ja hyödyntämisestä osana suunnitteluprosessia. Näiden lisäksi paikkatiedon hankkiminen eri lähteistä ja sen muokkaaminen prototyyppisovelluksen hyödyntämäksi sisällöksi toi kokemusta niin paikkatiedon hallintaan liittyvistä ohjelmistoratkaisuista kuin yleisesti aihealueen käsitteistöstä ja problematiikastakin. 11.1.1 Paikkatietoaineistojen hallinta ja julkisen datan käyttö Vaikka julkisen tiedon avaamisesta kansalaisten käyttöön käydään tällä hetkellä vilkasta keskustelua, rajoittavat useimpien tässä tutkimuksessa käytettyjen aineistojen käyttöehdot ratkaisevasti tietojen hyödyntämistä. Julkisten organisaatioiden toisistaan poikkevat tietojen luovutusta ja käyttöä rajoittavat käyttöehdot on laadittu aikanaan täysin erilaisiin sopimustyyppeihin ja liiketoimintamalleihin. Esimerkiksi Museoviraston aineiston maksuton käyttö on sallittu vain opiskeluun tai tutkimukseen liittyvässä yhteydessä ja Metsähallituksen aineiston käyttöehdot kieltävät aineiston luovutuksen kolmannelle osapuolelle, mikä rajoittaa merkittävästi aineiston tarjoamista esimerkiksi yhteistyökumppaneille osaksi heidän tuottamiaan palvelukokonaisuuksia. Etenkin pienille palveluntuottajille jo julkisten tiedontuottajien käyttöehtoihin tutustuminen ja pyrkimys sopimusehtojen neuvottelemiseksi mielekkään liiketoiminnan mahdollistaviksi voi olla käytännössä muodostaa tiedon hyödyntämisen estävän kynnyksen. Maanmittauslaitos on avaamassa suuren osan tuottamastaan paikkatietoaineistosta, kuten sähköisiä karttoja ja vektorimuotoisia aineistoja, maksutta 1.5.2012 alkaen suomalaisittain poikkeuksellisen vapain käyttöehdoin (Maanmittauslaitos, 2011). Aineistojen hyödyntäjän kannalta on toivottavaa, että myös muut julkisen tiedon tuottajat avaisivat omia tietovarantojaan, niin etteivät käyttöehdot ja mahdolliset käyttökorvaukset estäisi käytännössä datan hyödyntämistä erilaisin liiketoimintamallein rahoitetuissa sovelluksissa. Alaluvussa 5.3 kuvatussa WebPark-tutkimuksessa todettiin, että julkisista paikkatietolähteistä saatava karttatieto on vain osa matkailijalle tarjottavaa sisältöä ja kiinnostavin aineisto on usein kohteessa toimivien paikallisten ihmisten tai muiden matkailijoiden yhteisöllisesti tuottamaa. Vaikka julkisten 54
LUKU 11. POHDINTA 55 paikkatietoaineistojen avaaminen ja toisaalta sisällön lataaminen yhteisöpalveluista julkisten ohjelmointirajapintojen kautta mahdollistaisi matkailijoille tarjotun tietosisällön kasvattamisen helposti, on palveluita kehitettäessä syytä huomioita käyttäjien kannalta kiinnostavimman tiedon tuottajat jo suunnitteluvaiheessa. 11.1.2 Paikkatietoa hyödyntävä mobiiliwebteknologia Koska työssä tutkittiin sekä teknisten ratkaisujen soveltuvuutta että käyttäjiltä saatua tietoa, pyrittiin prototypoinnissa löytämään mielekäs tasapaino näiden tavoitteiden välillä. Teknisissä ratkaisuissa pyrittiin syventymään niihin osa-alueisiin, jotka tarjoavat eniten uutta tietoa prototypoinnin kohteena olevasta sovellusalueesta. Tällaisia osa-alueita olivat erityisesti paikannusteknologian hyödyntäminen webteknologian avulla moderneille mobiilialustoille toteutetussa sovelluksessa sekä paikkatiedon keräämiseen ja konvertointiin liittyvät kysymykset. Tutkimuksen tekijä tutustui työn aikana myös moniin ohjelmistokehitysympäristöihin ja ohjelmointikieliin, kuten Ruby on Rails ja Python. 11.1.3 Käyttäjätiedon hankinta osana suunnitteluprosessia Tässä tutkimuksessa käytössä olleilla tiedonkeruumenetelmillä saatiin tietoa käyttäjien toiveista ja näin tuettiin prototyyppisovelluksen suunnittelua. Kokemukset käyttäjätiedon keruun menetelmistä ja niiden soveltamisesta osoittautuivat kuitenkin vähintään yhtä tärkeiksi kuin itse prototyyppisovelluksesta kerätty käyttäjäpalaute. Eri menetelmien käyttökelpoisuudessa tämänkaltaisessa kehitystyössä todettiin selkeitä eroja. Haastattelut, ryhmäkeskustelut ja kenttätestaus osoittautuivat tärkeiksi käyttäjätiedon lähteiksi prototyypin suunnittelulle. Suunnittelun myöhemmässä vaiheessa, kun palvelun käyttöliittymä sisältöineen on vakiintunut ja käyttötilanteet muistuttavat riittävästi palvelun suunniteltua käyttöä, käyttölokin keruun arvioitiin tuovan lisätietoa palvelun jatkokehittämisen tueksi. 11.1.4 Käyttäjätarpeiden toteutuminen Prototyyppisovelluksella keskityttiin vastaamaan alaluvussa 5.1 kuvatuista Nivalan tunnistamista käyttäjätarpeista niihin, jotka liittyivät retken aikaiseen käyttöön. Sovelluksella on tosin mahdollista selata alueen kohteita ja käyttäjien kokemuksia ennen retkeä ja sen jälkeen, mutta nämä retken vaiheet eivät painottuneet sovelluksen suunnittelussa ja myös käyttäjät kokivat sovelluksen ensisijaisesti retken aikaiseksi palveluksi. Retken aikaisista palveluista sovelluksessa ja sen käyttäjätutkimusten tiedonkeruussa painotuttiin käyttäjän sijainnin ja sen lähiympäristön kohteiden näyttämiseen. Näistä toiminnoista saatiin runsaasti käyttäjäpalautetta, jota hyödynnettiin jo sovelluksen kehitystyössä. Retken dokumentointi ja yhteisöllisinä elementteinä kokemusten ja sijainnin jakaminen olivat myös osa sovelluksen toiminnallisuutta. Näiden toimintojen esittely nosti esiin muun muassa yhteisölliseen retkeilyyn liittyviä käyttäjäkommentteja, vaikkeivät käyttäjät juurikaan tuottaneet omaa sisältöä palveluun sovellusta kokeillessaan. Sovelluksella ei pyritty vastaamaan muuttuvista olosuhteista, kuten
LUKU 11. POHDINTA 56 säätilasta, tiedottamiseen koska tätä ei nähty keskeisinä käyttäjän kannalta. Sovellukseen ei myöskään toteutettu turvallisuuteen palveluita, koska palvelun ei haluttu antavan käyttäjälle perusteetonta turvallisuudentunnetta. 11.1.5 Tutkimuksen yleistettävyys Tutkimuksen tulokset voidaan yleistää koskemaan luonto- ja historiamatkailun lisäksi myös muita paikkatietoon perustuvia mobiilipalveluita, joiden kehittämisessä nousevat esille tämän työn aihepiirin liittyvät kysymykset. Näitä kysymyksiä ovat erityisesti sovelluskehityksen ohjelmistotekniset ratkaisut, käyttöliittymän sisältö ja sen tuottaminen sekä käyttäjätiedon keruu ja käsittely. Teknisiin ratkaisuihin ja käyttäjätiedon keruuseen liittyviä tuloksia voidaan yleistää yleisesti mobiilisovellusten ihmiskeskeiseen kehittämiseen. 11.2 Jatkokehitys Tässä tutkimuksessa kuvatulla HTML5-standardiin pohjautuvalla websovelluskehitymallilla voidaan kehittää prototyyppisovelluksesta kaupallinen palvelu ja niin sanotuilla hybridisovelluksilla (engl. hybrid applications) lisätä palveluun mobiililaitteen laitteistoresursseja hyödyntäviä ominaisuuksia (Christ, 2011). Taloudellisesti toteuttamiskelpoisen palvelun kehittäminen ja ylläpito vaatii kuitenkin jatkotutkimusta palvelun kohderyhmien ja niitä kiinnostavan sisällön tunnistamiseksi sekä kohderyhmille tarjottavan kokonaispalvelun ja siihen liittyvän liiketoimintamallin kehittämistä. 11.2.1 Tekninen jatkokehitys Alaluvussa 3.1 käsiteltiin mobiilisovelluksen vaihtoehtoista kehittämistä joko HTML5-standardiin perustuvana mobiiliwebsovelluksena tai käyttöjärjestelmäkohtaisilla työkaluilla toteutettuna natiivisovelluksena. Viime aikoina julkaistut hybridisovellusten kehittämiseen tarkoitetut ohjelmistokehitysvälineet yhdistävät HTML5- ja natiivisovelluskehityksen hyviä puolia. Useissa mobiilikäyttöjärjestelmissä toimivan hybridisovelluksen ohjelmointiin voidaan käyttää JavaScript-ohjelmointikieltä kehitysympäristön rajapintafunktioiden tarjotessa sovellukselle mahdollisuuden hyödyntää sellaisia laitteiston ominaisuuksia, kuten kamera ja kompassi, joiden käyttämiseen HTML5-standardin määrittämät rajapinnat eivät tarjoa mahdollisuuksia. Hybridisovellusten kehittämiseen tarkoitettuja ohjelmointiympäristöjä ovat muun muassa nykyisin Adoben omistaman Nitobin kehittämä PhoneGap ja Appceleratorin kehittämä Titanium. Hybridisovelluskehitystä tukevia ohjelmointiympäristöjä voidaankin hyödyntää prototyyppisovelluksen mahdollisessa jatkokehityksessä.(christ, 2011) 11.2.2 Käyttöliittymän kehittäminen Vaikka palvelun käyttöliittymään liittyvät käyttäjätarpeet voivat vaihdella eri käyttäjäryhmien välillä, ovat käyttöliittymän yksinkertainen käyttöönotto, helppokäyttöisyys ja käytön tarjoama välitön positiviinen hyöty tai muu
LUKU 11. POHDINTA 57 positiivinen palaute tärkeitä ominaisuuksia käyttäjäryhmästä riippumatta. Mikäli palvelun tuottamiseen liittyvä liiketoiminta on suoraan riippuvainen sovelluksen käytön ja käyttäjien määrästä, on palvelun tuettava sen käytöstä syntyneiden positiivisten kokemusten välittämistä toisille palvelun käyttäjille tai potentiaalisille käyttäjille sosiaalisen median kautta. Onnistuessaan tällaisella käyttäjien välittämiin viesteihin perustuvalla viraalimarkkinoinnilla voi olla ratkaiseva merkitys palvelun tunnettavuuden luomisessa. Toisaalta palvelun sisällön ja toiminallisuuden on houkuteltava sovellukseen tutustuneen käyttäjän käyttämään sovellusta myös ensimmäisen käyttökerran jälkeen. Tässä työssä ja työn lähteinä käytetyissä tutkimuksissa pidetään paperikartasta jalostettua sähköistä karttaa ensisijaisena käyttöliittymän maastotietonäkymänä. POI-kohteita voidaan kuitenkin näyttää esimerkiksi niin sanotuissa lisätyn todellisuuden sovelluksissa (engl. augmented reality, AR), joissa tietokoneen tuottamia virtuaalisia kohteita näytetään ajantasaisesti käyttöliittymässä reaalimaailmasta tuotetun näkymän, esimerkiksi videokameralla otetun kuvan, yhteydessä(azuma et al., 2001). Lisättyyn todellisuuteen liittyvä toiminnallisuus voidaan toteuttaa joko mobiilisovellukseen, kuten on tehty Helsingin yliopistolla toteutetussa Apps4Finland-kilpailuun osallistuneessa Ihana Helsinki! - sovelluksessa, tai paikkatietokohteet voidaan näyttää erityisesti lisätyn todellisuuden kohteiden selailuun tarkoitetun selainsovelluksen (engl. augmented reality browser) avulla (Ihana Helsinki! -työryhmä, 2012). Tämän työn tekijä testasi prototyyppisovelluksen kohdetiedon näyttämistä lisätyn todellisuuden Layar-palvelussa, joka lukee paikkatietokohteet sovelluksen tarjoamasta palvelurajapinnasta GeoJSON-muodossa (Layar B.V., 2012). Tässä teknisiä valmiuksia kartoittavassa testissä todettiin, että Layar-selaimen määritteleminen hyödyntämään prototyyppisovelluksen kohdetietoa oli yksinkertaista, mutta testi ei antanut lisätietoa lisätyn todellisuuden käyttöliittöliittymän käytettävyydestä tai sisällön mielekkyydestä käyttäjän kannalta. Kuvassa 11.1 on esimerkkinäkymä prototyyppisovelluksen kohdetiedoista lisätyn todellisuuden Layar-selaimella toteutettuna. 11.2.3 Palvelusisällön kehittäminen Tämän tutkimuksen käyttäjätutkimuksissa kerättiin tietoa sisällön kiinnostavuudesta pääasiallisesti retkeilyä harrastavilta suomalaisilta. Mikäli palvelun kohderyhmäksi valitaan esimerkiksi tietyistä maista tulevat ulkomaiset matkailijat tai ympäristökasvatukseen liittyen koululaiset, pitää sisällön kiinnostavuutta tutkia erikseen valituilla kohderyhmillä. Luonto- tai historiakohteessa vierailijan kävijä- ja oppimuskokemusta voidaan nimetä tulkinnaksi tai interpretaatioksi (engl. interpretation). Käsitteenä interpretaatio määritellään alunperin Freeman Tildenin vuonna 1957 julkaisemassa teoksessa Interpreting Our Heritage, jossa kansallispuistojen arvoa korostanut Tilden tähdentää kokonaiskuvan muodostamista kävijälle merkityksellisistä asioista sekä kävijän omakohtaisen kokemuksen tärkeyttä ympäristökasvatuksessa pelkän tiedonjaon sijaan.(tilden ja Craig, 2007) Matkailijaa tai retkeilijää palveleva mobiilisovellus voi luoda uusia tapoja kohteen kokonaisvaltaiseen
LUKU 11. POHDINTA 58 Kuva 11.1: Prototyyppisovelluksen kohdetietoja ipad-taulutietokoneessa toimivassa Layar-sovelluksessa kokemiseen esimerksi käyttäjää aktivoivan tarinan tai pelin avulla. Mobiilipalvelun kiinnostavuutta voidaan parantaa lisäämällä siihen vaikkapa geokätköilysssä (engl. geocaching) tai roolipelaamisesssa käytettyjä pelillisiä elementtejä. Esimerkiksi suomalaisen Grey Arean kehittämässä iphone- ja ipad-laitteilla toimivassa Shadow Cities -roolipelissä yhdistetään roolipelaaminen paikkatiedon ja pelin graafisen ulkoasun mukainen karttavisualisointi(grey Area Oy, 2012).
Lähteet R. Azuma, Y. Baillot, R. Behringer, S. Feiner, S. Julier ja B. MacIntyre. Recent advances in augmented reality. Computer Graphics and Applications, IEEE, 21 (6):34 47, 2001. R. Bajaj, S.L. Ranaweera ja D.P. Agrawal. Gps: Location-tracking technology. Computer, 35(4):92 94,2002.ISSN0018-9162. S. Borsci, S. Federici ja M. Lauriola. On the dimensionality of the System Usability Scale: a test of alternative measurement models. Cognitive processing, 10(3):193 197, 2009. G. Bryanski. Swedish firm starts using Russian satnav, 2011. URL http://www.reuters.com/article/2011/04/11/ us-russia-sweden-glonass-idustre73a1s320110411. H. Butler, M. Daly, A. Doyle, S. Gillies, T. Schaub ja C. Schmidt. The GeoJSON Format Specification, 2011. URL http://geojson.org/geojson-spec.html. Camineo SAS. iwebpark ios-käyttöjärjestelmän laitteille, 2011a. URL http://itunes.apple.com/en/app/iwebpark/id368746620. Camineo SAS. Camineo-yrityssivusto, 2011b. URL http://www.camineo.com/. C. Carlsson, K. Hyvönen, P. Repo ja P. Walden. Adoption of mobile services across different technologies. Proceedings of the 18th Bled econference-eintegration in Action, Bled, 2005. C. Carlsson, P. Walden ja F. Yang. Travel MoCo A Mobile Community Service for Tourists. Mobile Business, 2008. ICMB 08. 7th International Conference on, sivut 49 58. IEEE, 2008. A. Charland ja B. Leroux. Mobile application development: Web vs. Native. Communications of the ACM, 54(5):49 53,2011. A.M. Christ. Bridging the Mobile App Gap. Connectivity and the User Experience, sivu27,2011. Clker.com yhteisö ja Rolera LLC. Clker.com - The online royalty free public domain clip art, 2011. URL http://www.clker.com/. Viitattu17.10.2011. 59
LÄHTEET 60 S. Cojocaru, E. Birsan, G. Batrinca ja P. Arsenie. GPS-GLONASS-Galileo: a dynamical comparison. The Journal of Navigation, 62(01):135 150, 2009. ISSN 0373-4633. A. Cooper. Nörttien valtakunta - miksi korkeateknologiatuotteet saavat meidät sekaisin ja kuinka palauttaa järki. SuomenAtk-kustannusOy,1999. CSC - Tieteen tietotekniikan keskus. PaITuli - Paikkatietoja tutkimukseen ja opetukseen, 2011. URL https://sui.csc.fi/applications/paituli/paituli/. Viitattu9.10.2011. F.D. Davis, R.P. Bagozzi ja P.R. Warshaw. User acceptance of computer technology: a comparison of two theoretical models. Management science, sivut 982 1003, 1989. P.B. de Selding. Galileo assessment pulls no punches, 2011. URL http: //www.spacenews.com/civil/110120-galileo-assessment-punches.html. E. Dias, C. Rhin, R. Haller ja H. Scholten. Adding value and improving processes using location-based services in protected areas: The webpark experience. e-environment: Progress and Challenge Special edition on e-environment Instituto Politécnico Nacional Mexico, Mexico City, sivut291 302,2004. E. Ecma. 262: ECMAScript Language Specification. ECMA (European Association for Standardizing Information and Communication Systems), pub-ecma: adr, third edition, December, 1999. A. Edwardes ja T. Grossmann. WebPark: LBS in Action. 2008. A. Edwardes, D. Burghardt ja R. Weibel. WebPark - Location based services for species search in recreation area. 2003. M. Elkstein. Learn REST: A Tutorial, 02 2008. URL http://rest.elkstein.org/. Inc. Environmental Systems Research Institute. ESRI Shapefile Technical Description, 1998. URL http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf. Viitattu 9.10.2011. Facebook. Facebookin kehittäjädokumentaatio, 2011. URL http://developers.facebook.com/docs/. Viitattu16.10.2011. X. Faulkner. Usability engineering. Palgrave, 2000. R. Fielding. Representational state transfer (REST). Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, sivu 120, 2000. G. Gao ja G. Lachapelle. INS-Assisted high sensitivity GPS receivers for degraded signal navigation. Library and Archives Canada= Bibliothèque et Archives Canada, 2007. ISBN 0494257008.
LÄHTEET 61 J.J. Garrett et al. Ajax: A New Approach to Web Applications. 2005. URL http://www.robertspahr.com/teaching/nmp/ajax_web_applications.pdf. Grey Area Oy. Shadow Cities -pelin esittelysivu, 2012. URL http://www.shadowcities.com/. P. Häkli, J. Puupponen, H. Koivula ja M. Poutanen. Suomen geodeettiset koordinaatistot ja niiden väliset muunnokset. Suomen Geodeettisen laitoksen tiedote, sivu126,2009.saatavissa: http://www.fgi.fi/julkaisut/pdf/gltiedote30.pdf. M. Hampe ja V. Paelke. Adaptive maps for mobile applications. Mobile maps 2005 interactivity and usability of map-based mobile services, 2005. G. Hartmann. HTML5 for mobiles: fact or fiction?, 03 2011. URL http://www.triballabs.net/2011/03/ html5-on-mobile-browsers-what-can-you-do-today/. I. Hickson. HTML5-standardi, 2011a. URL http://dev.w3.org/html5/spec/. I. Hickson. Web Storage -standardi, 2011b. URL http://dev.w3.org/html5/webstorage/. SHyysalo.Käyttäjä tuotekehityksessä - Tieto, tutkimus ja menetelmät. Taideteollinen korkeakoulu, 2009. Saatavissa sähköisenä: https://www.taik.fi/kirjakauppa. Ihana Helsinki! -työryhmä. Ihana Helsinki! -sovelluksen esittely, 2012. URL http://www.cs.helsinki.fi/group/ihana/. Interfax. Russia restores its orbital GLONASS group, 2011. URL http://english.ruvr.ru/2011/10/03/58065478.html. International Organization for Standardization ISO. 9241-210: 2010: Ihmisen ja järjestelmän vuorovaikutuksen ergonomia-osa 210: Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelu. International Organization for Standardization (ISO). Switzerland, 2010. JQuery Mobile -kehittäjäyhteisö. jquery Mobile: Touch-Optimized Web Framework for Smartphones & Tablets, 2011. URL http://jquerymobile.com/. JSON-kehittäjäyhteisö. JSON-tiedonsiirtomuodon esittelysivu, 2011. URL http://www.json.org/. Viitattu27.10.2011. E. Kaasinen. User needs for location-aware mobile services. Personal and Ubiquitous Computing, 7(1):70 79,2003. P.G. Keen, R. Mackintosh ja M. Foreword By-Heikkonen. The Freedom Economy: Gaining the Mcommerce Edge in the Era of the Wireless Internet. McGraw-Hill Professional, 2001.
LÄHTEET 62 A.V. Kesteren ja I. Hickson. Offline Web Applications, 2008. URL http://www.w3.org/tr/offline-webapps/. O. Koivula, E. ja Saastamonen. Näkökulmia luontomatkailuun ja sen tulevaisuuteen. Tiedonantoja, 165, 2010. A. LaMarca, Y. Chawathe, S. Consolvo, J. Hightower, I. Smith, J. Scott, T. Sohn, J. Howard, J. Hughes, F. Potter et al. Place lab: Device positioning using radio beacons in the wild. Pervasive Computing, sivut116 133,2005. Layar B.V. Layar-sovelluksen esittely, 2012. URL http://www.layar.com/. K. Lukka ja T.S. Tuomela. Testattuja ratkaisuja liikkeenjohdollisiin ongelmiin: konstruktiivinen tutkimusote. Yritystalous, 4:23 29, 1994. Maanmittauslaitos. Maanmittauslaitos avaa maastotiedot 1.5.2012, 2011. URL http://www.maanmittauslaitos.fi/tiedotteet/2011/12/ maanmittauslaitos-avaa-maastotiedot-152012. M. Marshall. How HTML5 will kill the native app, 2011. URL http: //venturebeat.com/2011/04/07/how-html5-will-kill-the-native-app/. Mediawiki kehittäjäyhteisö. MediaWiki-ohjelmiston esittelysivusto, 2011. URL http://www.mediawiki.org/wiki/mediawiki. Viitattu16.10.2011. Mysitemyway Design Team. ICONS etc. - Royalty Free Icons and Clipart Stock Images, 2011. URL http://icons.mysitemyway.com/. Viitattu16.10.2011. J. Nielsen. Usability Engineering. Morgan Kaufmann, 1993. A.M. Nivala. Usability perspectives for the design of interactive maps. Suomen Geodeettisen laitoksen julkaisuja, 2007. Saatavissa: http://lib.tkk.fi/diss/2007/isbn9789512289431. A.M. Nivala, T. Sarjakoski, K. Laakso, J. Itäranta ja P. Kettunen. User Requirements for Location-Based Services to Support Hiking Activities. Location Based Services and TeleCartography II, sivut167 184,2009. Nokia Oyj. Nokia mobile web templates. Viitattu 16.10.2011. OpenLayers-kehittäjäyhteisö. OpenLayers: Free Maps for the Web, 2011. URL http://openlayers.org/. OpenStreetMap-yhteisö. Ogr2osm-muunnosohjelman esittely, 2011. URL http://wiki.openstreetmap.org/wiki/ogr2osm. Viitattu9.10.2011. OpenStreetMap-yhteisö. Slippy Map. URL http://wiki.openstreetmap.org/wiki/slippy_map. Viitattu16.10.2010. A. Popescu ja S. Block. Geolocation API Specification Level 2, 2011. URL http://dev.w3.org/geo/api/spec-source-v2.
LÄHTEET 63 S. Poslad, H. Laamanen, R. Malaka, A. Nick, P. Buckle ja A. Zipf. Crumpet: Creation of user-friendly mobile services personalised for tourism. IEE Conference Publication, sivut 28 32. Citeseer, 2001. Proj.4-kehittäjäyhteisö. Proj.4-ohjelmakirjaston esittely, 2011. URL http://trac.osgeo.org/proj/. Viitattu9.10.2011. P. Räsänen. Outdoors Finland Eteläisen Suomen aktiviteettien kehittämisohjelma 2011 2014 - Hankesuunnitelma, 2011. O. Rinne. Retkeni.fi-mobiiliprototyyppisovelluksen esittelyvideo, 2011. URL http://www.youtube.com/watch?v=y3xvjflflva. O. Rinne ja OSM-kehittäjäyhteisö. Ympäristökeskuksen aineiston siirto OpenStreetMapiin, 2011. URL http://wiki.openstreetmap.org/wiki/finland:syke. Sanastokeskus TSK ry. Geoinformatiikan sanasto, 2011. URL http://www.tsk.fi/tiedostot/pdf/geoinformatiikansanasto.pdf. B. Schmidt-Belz ja S. Poslad. User validation of a mobile tourism service. Workshop HCI mobile Guides, Udine (Italy),2003. S. Segan. Smartphone GPS Just Got A Whole Lot Better, And Russian, 2011. URL http://www.pcmag.com/article2/0,2817,2392569,00.asp. ST-Ericsson. ST-Ericsson Unveils Faster and Sharper Mobile Positioning, 2011. URL http://www.stericsson.com/press_releases/cg1950.jsp. Suomen Verkkodemokratiaseura ja Forum Virium. Apps4Finland-kilpailun esittelysivu. URL http://apps4finland.fi/fi. Viitattu22.9.2010. Swiss National Park. Sveitsin kansallispuiston esittelysivu, 2011. URL http://www.nationalpark.ch/go/en/. S. Teräs. Ensimmäinen käyttöliittymäluonnos, 6 2011. The Open Geospatial Consortium. The Open Geospatial Consortium, yleiskuvaus, 2010. URL http://www.opengeospatial.org/. Viitattu25.10.2010. The Open Source Geospatial Foundation. GDAL-ohjelmakirjaston esittely, 2011. URL http://www.gdal.org/. Viitattu9.10.2011. F. Tilden ja R.B. Craig. Interpreting our heritage. The University of North Carolina Press, 2007. T. Vaittinen, K. Laakso ja J. Itäranta. Kuukkeli: design and evaluation of location-based service with touch UI for hikers. Proceedings of the 5th Nordic conference on Human-computer interaction: building bridges, sivut373 382. ACM, 2008.
LÄHTEET 64 Valtion ympäristöhallinto. OIVA - Ympäristö- ja paikkatietopalvelu asiantuntijoille, 2010. URL http://wwwp2.ymparisto.fi/scripts/oiva.asp. Viitattu 14.11.2010. Vaatii rekisteröitymisen. H. Vehkaperä. Mitä ovat WMS, WFS, WCS ja mihin niitä tarvitaan? Positio, (2):24 25, 2009. Saatavissa: http://tinyurl.com/3637ojb, Viitattu 13.10.2010. K. Virrantaus. Kartan suunnittelu, digitaaliset karttatietokannat ja tiedon esittämisen standardit, 10 2001. URL http://www.cs.hut.fi/opinnot/t-106.850/pmrg/s2001/kartat.ppt. W3C. Document Object Model (DOM), 2011. URL http://www.w3.org/dom/. P. Walden. Pirkko Waldenin sähköpostihaastattelu 1.11.2011, 11 2011. WebPark Consortium. Geographically relevant information for mobile users in protected areas. URL http://www.ist-world.org/projectdetails.aspx? ProjectId=0e115042fee24307b03b0fea2fc8cee6. N.C. Zakas. Professional JavaScript for web developers. Wrox,2011.
65
LIITE A. KÄYTTÖLOKIIN KIRJATTAVAT TOIMINNOT 66 A Käyttölokiin kirjattavat toiminnot!"#$%!"#$&!"#$' $()*""!+$,+#-"!!*+.//!!+ 0$$1+!$!)/!/#!""#$%& '(&$ ) #)*$ +!""#$%&,-.$/01 ) #)23 +!""#$%&./$.34' ) #)/% +!""#$%& (35/% ) #)(/ +!""#$%& (353&. #)(3 '(&$ '(&$(/0.' '(&$6(/0.'0.' *$0./* *)0)* + '(&$ '(&$(/0.' 3#'6'(&$6)67'8..'9'(/%.' *)0)3:%*# + '(&$ '(&$(/0.' 7'8..' 9'(/.0$63#'6'(&$ 7338*/%''./.; *)0)#)* + '(&$ '(&$!'(&&6'(&$9'(/%.''% *)*)8$. + '(&$ '(&$ 9'(/%%'.)(/%77/ ) *)*)</ + '(&$ '(&$ -'7&$-*3.!"/9/." *)*)</)&!* + '(&$ '(&$ -'7&$-*3..'7'/0/%,($#!/='($#!/ *)*)</)8$. + '(&$ '(&$ -'7&$-*3. 0&3*'.&0 3%=3<<>6733*/ *)*)</).35 + '(&$ '(&$ &&0/6!3/ ) *)*)%$:! + '(&$ '(&$ 9'(/.0$6!3/!3//* *)*)0$(! + '(&$ '(&$ (''4$%%'68$/./. *)*)$+!8 '(&$ '(&$ (''4$%%'6(&3%.3.,,!/. *)*)$+!?. '(&$ '(&$ 7'8..'#33*//% *)*)##'! + '(&$ '(&$ 7'8..' /%<3#33*//% *)*)#/%<3 + '(&$ '(&$ 7'8..' 9'(/.0$6!3/!3//* *)*)#'!)0$(! + '(&$ '(&$ 7'8..' 9'(/.0$6!3/!3//* *)*)#'!)0$(!)2'% + '(&$!3/!'(&&6'(&$$0$$% *)!)8$. + '(&$!3/ 7'8..'#33*//% *)!)##'! + '(&$!3/ 7'8..' /%<3#33*//% *)!)#/%<3 + '(&$!3/ 7'8..' 9'(/.0$6!3/!3//* *)!)#'!)0$(! @ '(&$!3/ 7/84'&*&6<? *)!)(/ + '(&$!3/ 7/843/.'69/$8'07/84''% *)!):85? + '(&$!3/ 4''6<?A00" *)!)0-<? + '(&$!3/ 4''6<?A00" *)!)0-<?)37 + '(&$!3/ 4''6<?A00" *)!)0-<?)2'% + '(&$6!3/ 73-*$6$/63($6%,6'(&$$(('B *)!)0-!)37 + '(&$6!3/ 73-*$6$/63($6%,6'(&$$(('B *)!)0-!)2'% + '(&$ &&0/6!3/!'(&&6'(&$$0$$% *)%!)8$. + '(&$ &&0/6!3/!'/7'%%' *)%!)(32 + '(&$ &&0/6!3/ (/0""6!3/ *)%!)'! + '(&$ &&0/6!3/ 7/84'&*&6<? *)%!)(/ + (35/% 7/84'&*&6<? (35/%)(/ +,-.$/01 9'(/.0$6&&./%$%!3//* 2)0$(% +,-.$/01 (''4$%%'67'9$8/(/0.' 2)$+!< +./$.34' 9'(/.0$6,($/0." /)'?3&. +./$.34' 9'(/.0$63-4$ /)-$(! +./$.34' 9'(/.0$67,0$(, /)C&$0. +./$.34' 7,0$(, ("-$."67,0$(, /)C&$0.)0 + '(7&&% 5)?3<!'5$ +./$.34'6039$((&70$0.' 5)'!!(/%<3 + 7'8.'%60//8.364'6D33#'&0
B Käyttölokin tutkimustulokset 133) A3) +(?-%,""@A:%0,)&,6$8-%%((6: 23) <3) %&'((') N#6''7')?3) 3) :;) :A) :F) <3) <1) <?) <:) <<) <B) <2) <;) <A)!"#$%&'$($)*$ +(,%-%,"",,%!"#$ %&'((')'$"*++#"!"#$ %&'((')'$"*++#",-').//""0'"/ 123 4''((# (&'((' 5#6''7' 807&'+ '$"*+"#9& #$**$ :; 13 < =>-#50 <?)@ :A 1B? C'-0D#E A< ::)@ :F <? G,?B 13)@ <3 : 3!.0-& F <)@ <1 2 3 8&D&-' 2A?;)@ <? A B H+I-#'I :3 1?)@ <: <A 1: G!8J'K&IL'K>#+0M?: F)@ << A2?B!.0-&N#6'70 B?)@ <B :< < 8O56'&+ <?)@ <2 1 3./,""&01 232 133)@ <; :? ; <A B 3./,""&01 232 42 567%%#%8"%9*67%%#%!"#$ %&'((')'$"*++#",-').//""0'"/ 123 POO..' '$"*+"#9& #$**$ 0'Q5#6''7' 1F3 ;B)@ 5#6''7' 2??B)@./,""&01 232 133)@ 567%%#%9%0,)&,6'"&:0"#$%&'$($)*$!"#$ N#6''7'Q'$"*++#",-').//""0'"/ :?.&'(&++*$"'0"#)(/O"R$$/ 807&'+ (.7 #$**$ (.7 #$**$ H+I-#'I :3 <A)@ 1A 23)@ G!8J'K&IL'K>#+0M?: :;)@ 1: B;)@!.0-&N#6'70 B A)@ 3 3)@ 8O56'&+ < 2)@ 3 3)@./,""&01 42 ;<<:= >; 3<:= 67
LIITE B. KÄYTTÖLOKIN TUTKIMUSTULOKSET 68!"#$$%$&$'()*("+,*-+./.)0.-(,1(2+,*-/32((3+3"4,5..($"$6,*-0)/..*!"#$ %#&''(')'$"*++#",-'./00""1'"0 23 #/1-44"'#'"4 '$"*+"#54 #$**$ 61$"#.61$6'7.8$9 : ; <=.> : <? <2.> : 3 ; <=.> 3@ 2 << <?.> 3A B 2 =.> @= = 2 =.> A@ A < 3.> A2 @? <2.>?:? 2 =.> <:: ; < 3.> 3?: <: < 3.> <2< << 2 =.> 3@@ <3 < 3.> @< <2 < 3.> <=? 21(,,*'3 78 9::-; << =%,$'$003(-$'()**"*->$$0,$',(-/32((3+3"4,5..($"(!"#$ %#&''(')'$"*++#".8339C.5#'$$4.D0E'+"00+.=.60F""050#/1-44"'#"4,-'./00""1'"0 <; '$"*+"#54 #$**$ 6##G' $1('"F$ = 32.> G)G)$1(/ D4('"$1./#'.4(*1+06F70$$0 B <?.> 7)G1 D4('"$1.4(*1./00+4D'H44"'#$"4 B <?.> G)$)G D4('"$1.4(*1.('$"4$"4 3 ;.> 7)I# D4('"$1.FE"1'$J./00+4D'H44"'#$"4 < =.> G)$)#K+G7 D4('"$1.#74.4(*1.4(*1('$"4$"4 < =.> I)1L/M +0F"0.64D1-'".FE"1'$J+06F70$$0 < =.> G)G)774/ 64-""4+06F700+.4(*1('$"4$"4 < =.> G)G)-1" "464'$'+.4(*1('$"44+.4(*1+06F70$"0 < =.> I)$1(+ D4('"$1./#'.FE"1'$J+06F70$$0 < =.> G)G)74/)$1(/)I4+ /4'+1""*.64-"4$$4.6#E"44C.5#$$4.1'./#'"4 < =.> G)/)774/ "16$"'7*#"#'$1$"4./#')+06F70$"0.64-""47##G''+ 88 9::-;
C Ohjeistus prototyypin koekäyttöön - sähköposti Osallistu luontomatkailijan mobiilisovellustutkimukseen Hei kaikille Olemme koko kesän haastatelleet kuluttajia pyöräily- ja vaellusreiteillä erilaisten karttapalveluiden (painetut, internet, navigaattori ja älypuhelin -pohjaiset) ja reittien käytöstä ja niiden sisällöstä ja toimivuudesta. Jatkamme testaamalla mobiilisovelluksia sekä internet -pohjaisia reittisuunnittelupalveluita syksyn aikana monin eri tavoin. Alla on linkki yhden mobiilisovelluksen testiympäristöön, johon toivoisimme teidän perehtyvän ja antavan kommenttejanne meille. Tutkimuksen teknisestä puolesta, itse sovelluksesta antaa tietoja Olli Rinne, email. olli@feelthenature.fi ja tutkimuskokonaisuudesta allekirjoittanut. Voitte halutessanne välittää viestiä eteenpäin. Kiitos jo etukäteen. Pirjo Räsänen projektipäällikkö Outdoors Finland Etelä -hanke Päijät-Hämeen koulutuskonserni-kuntayhtymä Lahden ammattikorkeakoulu, Matkailun ala Kirkkokatu 27 15140 LAHTI Puhelin 044 708 1242 Lyhytvalinta: 881978 pirjo.rasanen@lamk.fi Olemme kehittäneet prototyypin luontomatkailijaa palvelevasta mobiilipalvelusta, jolla kävijä voi tutustua alueen kiinnostaviin kohteisiin ja palveluihin, kommentoida ja lisätä kohteita sekä jakaa kokemuksensa sosiaalisessa mediassa. Prototyypin tarkoituksena on kerätä kokemuksia käyttäjiltä ja testata teknisiä ratkaisuja. Sovellus on kehitetty osana Olli Rinteen Aalto-yliopistoon tekemää diplomityötä. Sovellukseen on viety pohjaksi tietoa mm. retkeilypalveluista ja sitä on kehitetty käyttäjiltä saadun palautteen pohjalta. Huomioithan kuitenkin, että prototyyppiluonteensa vuoksi sen toiminnallisuutta, ulkoasua, käyttöliittymää ja sisältöä ei ole testattu kaupalliselta sovellukselta vaadittavalla tavalla. Prototyyppisovellus toimii osoitteessa http://retkeni.fi. Sovelluksen käyttöliittymä on optimoitu käytettäväksi kosketusnäytöllisten 69
LIITE C. OHJEISTUS PROTOTYYPIN KOEKÄYTTÖÖN - SÄHKÖPOSTI 70 mobiililaitteiden internetselaimilla, sillä sovellus on ensisijaisesti tarkoitettu käytettäväksi matkan aikana. Siihen voit kuitenkin tutustua myös työasemakoneen selaimella (ei IE). Sovellus toimii parhaiten ohjelmistojen tuoreimmilla versioilla. Suositeltuja käyttöympäristöjä mobiiliympäristössä ovat: - Apple iphone ja ipad -Android2.2+ - Nokia Symbian puhelimilla käytä Opera Mobile 11.1+ selainta (ei toimi Symbianin vakioselaimella) Työasemilla (Windows,Mac,Linux) voit käyttää Firefox-, Chrome- tai Safari-selainten tuoreimpia versioita. Tätä versiota ei ole optimoitu Microsoft Internet Explorer selaimelle. Toivomme, että osallistut tutkimukseemme myös vastaamalla sovelluksessa olevaan lyhyeen käyttäjäkyselyymme (kohta Tietoja/Kysely). Myös kaikki muu palaute ja kommentit ovat erittäin tervetulleita. Terveisin, Olli Rinne, olli@feelthenature.fi, +358 40 900 5556 Olli Rinne puh. (09) 4241 4750, matkapuh. 040 900 5556, Skype: feelthenature.fi http://feelthenature.fi, http://www.facebook.com/feelthenature, http://twitter.com/feelthenature
D Kyselylomake FeelTheNature.mobi Palaute http://ftnmobi.dyndns.org/proto/?sdsdj Sisältö Miten tärkeinä pidät seuraavia sisältöjä tällaisessa palvelussa. Vastaa vaihtoehdoin 0-3. Valitse myös vaihtoehto A, mikäli olisit valmis tuottamaan tätä sisältöä itse. 0 - ei vastausta 1 - vähän tai ei lainkaan kiinnostavaa 2 - melko kiinnostavaa 3 - erittäin kiinnostavaa A - tuottaisin myös sisältöä itse Reitit ja reittiehdotukset Retkeilypalvelut (esim. käymälät, tulipaikat) Ympäristön matkailupalvelut (esim. majoitus, välinevuokraus) Reittien alku- ja loppupisteiden saavutettavuus (aikataulut) Kuvat ja päiväkirjamerkinnät (blogi) reitin varrelta Sieni- ja marjapaikat 0 1 2 3 A Sovelluksen toiminta Mitä mieltä olet näistä sovellukseen käyttöön liittyvistä väittämistä. 0 - ei vastausta 1 - täysin eri mieltä 2 - hieman eri mieltä 3 - vaikea sanoa 4 - jokseenkin samaa mieltä 5 - täysin samaa mieltä Opin sovelluksen käytön nopeasti Sovellus toimii loogisesti Sovelluksen ulkoasu on selkeä Sovellus toimii nopeasti ja luotettavasti Löysin hakemani tiedon helposti Käytin sovellusta luottavaisin mielin Tietoa on riittävästi retken toteuttamiseksi 0 1 2 3 4 5 Muu palaute ja kehitysideat Lähetä Alkuun 2 of 3 1.12.2011 14.38 71
E Kyselyn tulokset!"#$%&'(&)'(*+$,)-).//"/( 0(1'2$3$%&'(&)'(&!"#$%&' 4#(*+$(/"-*#+/$5#6/($'*)"&&%#&$'#'/,(78/$(/,,&#'*''&$5&,%*,)''&9$:&'(&&$%&#;(1*;61#+$<=39 :&,#('*$.>7'$%&#;(1*;(1$?@$.#-/,#$1,#'#($%&,.#'$()1((&.&&+$(/(/$'#'/,(7/$#('*9 <$=$*#$%&'(&)'(& A$=$%/;/+$(&#$*#$,&#+-&&+$-##++1'(&%&& B$=$.*,-1$-##++1'(&%&& 3$=$*"#((/#+$-##++1'(&%&&?$=$()1((&#'#+$.>7'$'#'/,(7/$#('*!"#$%&' ( ) * +, ()"&"&*+,*-)"&&".)/01&23#)&* = = = 3 B ()&3)"%45,%6)%2&*7)#"89*3$48$%$&:*&2%"5,"3,&;* = = = 3 = <85$-"#&'=*8,&3,"%2.5,%6)%2&*7)#"89*8,+1"&2#:*6$%"=)6213-,2#;* = = = 3 = ()"&&")=*,%32.*+,*%1552.5"#&)"0)=*#,,62.&)&.&,622#*7,"3,&,2%2&;* = A = B = >26,&*+,*5$"6$.3"-+,.8)-3"==$&*7?%1@";*-)"&"=*6,--)%&,* = = = 3 B!")=".*+,*8,-+,.5,"3,& A = = B B!16)%%23#)=*&1"8"=&, 4#(/$.#*,(/$1,*($+/#'(/$'1%*,,)-'**+$-/>((77+$,##((>%#'(/$%/#((/.#'(/9 <$=$*#$%&'(&)'(& A$=$(/>'#+$*"#$.#*,(/ B$=$;#*.&+$*"#$.#*,(/ 3$=$%&#-*&$'&+1& C$=$81-'**+-#+$'&.&&$.#*,(/ D$=$(/>'#+$'&.&&$.#*,(/ -$"&&$.$ ( ) * + / 0 A5"=*#16)%%23#)=*3$4&'=*=15),#&"* = = = = = 3!16)%%2#*&1"8""*%11@"#)#&"* = = = = A B!16)%%23#)=*2%31,#2*1=*#)%3)$* = = = A = B!16)%%2#*&1"8""*=15),#&"*+,*%21&)&&,6,#&"* = = = B A = B'4#"=*/,3)8,="*&")01=*/)%51#&"* = = = = A B >$4&"=*#16)%%2#&,*%21&&,6,"#"=*8")%"=* = = = A = B C")&1,*1=*-""&&$6$#&"*-)&3)=*&1&)2&&,8"#)3#" = = A B = = D22*5,%,2&)*+,*3)/"&4#"0),&!#$%&'(&)-'#& 72
FTietokannankuvaus 73
G Käyttöliittymän rakennekaavio 74
H Näyttökopiot käyttöliittymästä Allaolevat näyttökopiot käyttöliittymän tärkeimmistä näkymistä on otettu ipad-taulutietokoneen Safari-selaimella. Luvussa 8 on lisäksi kuva 8.1 uuden POI-kohteen lisäämisestä ja kuva 8.2 POI-kohteen tietonäkymästä. Kuva H.1: Aluevalintanäkymä Kuva H.2: Alueen karttanäkymä 75
LIITE H. NÄYTTÖKOPIOT KÄYTTÖLIITTYMÄSTÄ 76 Kuva H.3: Aluenäkymä kategoriavalinta avattuna Kuva H.4: Aluenäkymän alaosa; POIkohteet, reitit ja luontotyypit Kuva H.5: Yhteisönäkymä Kuva H.6: Sovelluksen yleistietonäkymä