ja kulttuurimatkailua tukevan mobiilipalvelun prototypointi Olli Rinne

Transcription

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:
Pääaine:
Valvoja:
Ohjaaja:
30. tammikuuta 2012
Sivumäärä: 12 + 90
Ohjelmistotuotanto ja -liiketoiminta
prof. Matti Hämäläinen
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:
Professorship:
Supervisor:
Instructor:
January 30, 2012
Pages: 12 + 90
Software Engineering and Business
Professor Matti Hämäläinen
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
a potential method to be used in the later phases of the design process. 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
2.2
Paikannusteknologia . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Matkapuhelinverkkoon perustuva paikannus . . . . . . . . . .
3
2.1.2
Satelliittipaikannus . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3
Muita paikannusteknologioita . . . . . . . . . . . . . . . . . .
5
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
6.2
Kartoitusvaihe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3
6.4
. . . . . . . . . . . . . . . . . . . . . 27
6.2.1
Paikkatietoaineistoihin tutustuminen . . . . . . . . . . . . . . 28
6.2.2
Kehitysympäristöjen arviointi . . . . . . . . . . . . . . . . . . 30
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
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
8.1
8.2
39
Kartografinen sisältö . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.1
Taustakartat
. . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.2
Kohteiden karttasymbolit . . . . . . . . . . . . . . . . . . . . 40
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.6
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
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
87
Haastattelurunko
J Haastattelujen tuloksia
89
1 Johdanto
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ä.
2 Paikkatietoon liittyvä 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ää
Kuva 2.2: Rajapintastandardit
palveluntarjoajan paikkatietoaineistoa. Web
käyttäjän sovelluksen ja paikkaCoverage Service -määrittely (WCS) kuvaa
tietoaineistojen välisessä kommuhilamuotoisen paikkatietoaineiston, kuten
nikaatiossa.(Vehkaperä, 2009)
korkeusmallien, tiedonsiirrossa käytettävät
tekniset rajapinnat. Kaaviokuvassa 2.2
on kuvattu erilaisten paikkatietoaineistojen
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)
3.4
8
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
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) ovat käsitelleet konstruktiivisen tutkimusotteen mukaista
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) arvioi mobiilisovelluksien menestymismahdollisuuksia
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.
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,
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ää
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ät käyttäjien kannalta tä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ät käyttäjätarpeet yhdeksään osittain pää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)
5.1.3
17
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
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) yleistyminen ja ä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.
19
Taulukko 5.1: Tärkeimmät mobiilikarttojen käytettävyyteen liittyvät suunnittelutekijät (Nivala, 2007)
Suunnitelutekijä
Kuvaus
Kartan visuaalinen suunnittelu
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..
Kartan graafi- Graafisen käyttöliittymän tulee täyttää käyttäjän tarpeet.
nen käyttöliitty- Erään karttasuunnittelijan mukaan karttakäyttöliittymäsmä
sä 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.
Laite
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.
Käyttäjät
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.
Käyttökonteksti
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.
5.3
20
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
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.
Kuva 5.2: Apple iOS mobiiKarttanäkymän ylävalikossa
lilaitteissa toimivan iWebparkon käyttäjätoimintoina vasemmalta oikealle
sovelluksen päävalikko
lueteltuna: paluu päävalikkoon, kartan suuntaus
kompassisuunnan mukaan, zoomaus sekä oman
sijainnin haku. Napauttamalla kartalla näkyvää
POI-kohdetta näytetään kohteen kohdalla
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
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ä
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) Tutkimussovelluksen käyttäjälaitteena kä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
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
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
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.
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
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
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.
6.3.8
32
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
35
Taulukko 7.1: Prototyyppisovelluksessa käytetyt JavaScript-kirjastot
Nimi
Käyttötarkoitus
OpenLayers
Dynaamisten karttojen toteutus webympäristöön
OpenLayers Mobile
Kosketusnäyttötoimintojen tuki OpenLayers-kirjastoon
Nokia Web Templates
Mobiilikehitykseen tarkoitettu
käyttöliittymäkomponenttikirjasto
Proj4
Koordinaattimuunnoksien tekoon tarkoitettu
funktiokirjasto
Facebook JavaScript
SDK
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
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
Polygoni
Polygon
Pintapala, jolla on tasomainen interpolointi
Pistejoukko
MultiPoint
Järjestämätön joukko pisteitä
Murtoviivajoukko
MultiLineString
Järjestämäton joukko murtoviivoja
Monipolygoni MultiPolygon
Geometriakokoelma
7.4
Suljettujen käyrien muodostama joukko
GeometryCollection Yksittäisen geometrian sisältämä sisäkkäinen geometriakokoelma
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
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
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ö.
8.4
41
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.11
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
1
2
2
erikseen asennettu selainohjelma
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
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
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.
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,
Kuva 9.2: Käyttäjäkysely matkapuhelimutta sovelluksen nopeutta ja teknistä
men näytöllä.
luotettavuutta ei pidetty erityisen
hyvänä. Tietoa retken toteuttamiseksi
kokonaisuudessaan ei myöskään koettu
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ä
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.
48
!"#$%&'$($)*$+%,-)&&.%/$%&+
7881($"9:&;""4"(
<(*(
/01$#0$#(
2'34&#$#(
56(*(
+,%,#"(
-.(*(
/?+@"A,>B"AC&0$D(
E(*(
:&;""4"G$4,":$1(
-<(*(
7881(:&;""4"(
F(*(
=0>#&">(
5-(*(
!"#$%&'(
))(*(
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
9.5.1
Ryhmäkeskustelut
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
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
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
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.
9.6.4
52
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. ISSN 0018-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, sivu 27, 2011.
Clker.com yhteisö ja Rolera LLC. Clker.com - The online royalty free public
domain clip art, 2011. URL http://www.clker.com/. Viitattu 17.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. Suomen Atk-kustannus Oy, 1999.
CSC - Tieteen tietotekniikan keskus. PaITuli - Paikkatietoja tutkimukseen ja
opetukseen, 2011. URL
https://sui.csc.fi/applications/paituli/PaITuli/. Viitattu 9.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, sivut 291–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/. Viitattu 16.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, sivu 126, 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/.
S Hyysalo. 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/. Viitattu 27.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, sivut 116–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. Viitattu 16.10.2011.
Mysitemyway Design Team. ICONS etc. - Royalty Free Icons and Clipart Stock
Images, 2011. URL http://icons.mysitemyway.com/. Viitattu 16.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, sivut 167–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. Viitattu 9.10.2011.
OpenStreetMap-yhteisö. Slippy Map. URL
http://wiki.openstreetmap.org/wiki/Slippy_Map. Viitattu 16.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/. Viitattu 9.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. Viitattu 22.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/. Viitattu 25.10.2010.
The Open Source Geospatial Foundation. GDAL-ohjelmakirjaston esittely, 2011.
URL http://www.gdal.org/. Viitattu 9.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, sivut 373–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
!"#$%
!""#$%&
!""#$%&
!""#$%&
!""#$%&
!""#$%&
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$6
'(&$6
'(&$
'(&$
'(&$
'(&$
(35/%
,-.$/01
,-.$/01
./$.34'
./$.34'
./$.34'
./$.34'
!"#$&
'(&$(/0.'
'(&$(/0.'
'(&$(/0.'
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
'(&$
!3/
!3/
!3/
!3/
!3/
!3/
!3/
!3/
!3/
!3/
!3/
&&0/6!3/
&&0/6!3/
&&0/6!3/
&&0/6!3/
7,0$(,
!"#$'
7'8..'
-'7&$-*3.
-'7&$-*3.
-'7&$-*3.
7'8..'
7'8..'
7'8..'
7'8..'
7'8..'
$()*""!+$
,+#-"!!*+.//!!+
'(&$
)
,-.$/01
)
./$.34'
)
(35/%
)
(353&.
'(&$6(/0.'0.'
*$0./*
3#'6'(&$6)67'8..'9'(/%.'
9'(/.0$63#'6'(&$
7338*/%''./.;
!'(&&6'(&$9'(/%.''%
9'(/%%'.)(/%77/
)
!"/9/."
.'7'/0/%
,($#!/='($#!/
0&3*'.&0
3%=3<<>6733*/
&&0/6!3/
)
9'(/.0$6!3/
!3//*
(''4$%%'68$/./.
(''4$%%'6(&3%.3.,,!/.
7'8..'#33*//%
/%<3#33*//%
9'(/.0$6!3/
!3//*
9'(/.0$6!3/
!3//*
!'(&&6'(&$$0$$%
7'8..'#33*//%
/%<3#33*//%
9'(/.0$6!3/
!3//*
7/84'&*&6<?
7/843/.'69/$8'07/84''%
4''6<?A00"
4''6<?A00"
4''6<?A00"
73-*$6$/63($6%,6'(&$$(('B
73-*$6$/63($6%,6'(&$$(('B
!'(&&6'(&$$0$$%
!'/7'%%'
(/0""6!3/
7/84'&*&6<?
7/84'&*&6<?
9'(/.0$6&&./%$%
!3//*
(''4$%%'67'9$8/(/0.'
9'(/.0$6,($/0."
9'(/.0$63-4$
9'(/.0$67,0$(,
("-$."67,0$(,
'(7&&%
./$.34'6039$((&70$0.'
7'8.'%60//8.364'6D33#'&0
0$$1+
#)*$
#)23
#)/%
#)(/
#)(3
*)0)*
*)0)3:%*#
*)0)#)*
*)*)8$.
*)*)</
*)*)</)&!*
*)*)</)8$.
*)*)</).35
*)*)%$:!
*)*)0$(!
*)*)$+!8
*)*)$+!?.
*)*)##'!
*)*)#/%<3
*)*)#'!)0$(!
*)*)#'!)0$(!)2'%
*)!)8$.
*)!)##'!
*)!)#/%<3
*)!)#'!)0$(!
*)!)(/
*)!):85?
*)!)0-<?
*)!)0-<?)37
*)!)0-<?)2'%
*)!)0-!)37
*)!)0-!)2'%
*)%!)8$.
*)%!)(32
*)%!)'!
*)%!)(/
(35/%)(/
2)0$(%
2)$+!<
/)'?3&.
/)-$(!
/)C&$0.
/)C&$0.)0
5)?3<!'5$
5)'!!(/%<3
!$!)/!/#
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
B Käyttölokin tutkimustulokset
133)
+(?-%,""@A:%0,)&,6$8-%%((6:
A3)
23)
%&'((')
<3)
N#6''7')
?3)
3)
:;)
:A)
:F)
<3)
<1)
<?)
<:)
<<)
<B)
<2)
<;)
<A)
!"#$%&'$($)*$
+(,%-%,"",,%
!"#$
,-').//""0'"/
!"#$
%&'((')'$"*++#"
123
%&'((')'$"*++#"
4''((#
807&'+
'$"*+"#9&
#$**$
=>-#50
<
?)@
C'-0D#E
A<
::)@
G,
?B
13)@
!.0-&
F
<)@
8&D&-'
2A
?;)@
H+I-#'I
:3
1?)@
G!8J'K&IL'K>#+0M
?:
F)@
!.0-&N#6'70
B
?)@
8O56'&+
<
?)@
./,""&01
232
133)@
./,""&01
567%%#%8"%9*67%%#%
!"#$
,-').//""0'"/
%&'((')'$"*++#"
123
POO..'
0'Q5#6''7'
5#6''7'
./,""&01
'$"*+"#9&
#$**$
1F3
;B)@
2?
?B)@
232
133)@
567%%#%9%0,)&,6'"&:0"#$%&'$($)*$
!"#$
,-').//""0'"/
N#6''7'Q'$"*++#"
:?
807&'+
(.7
H+I-#'I
G!8J'K&IL'K>#+0M
!.0-&N#6'70
8O56'&+
./,""&01
#$**$
:3
?:
B
<
42
<A)@
:;)@
A)@
2)@
;<<:=
(&'(('
:;
:A
:F
<3
<1
<?
<:
<<
<B
<2
<;
<A
.&'(&++*$"'0"#)(/O"R$$/
(.7
#$**$
1A
23)@
1:
B;)@
3
3)@
3
3)@
>;
3<:=
67
5#6''7'
13
1B
<
:
2
A
<A
A2
:<
1
:?
B
232
<
?
?
3
3
B
1:
?B
<
3
;
3
42
LIITE B. KÄYTTÖLOKIN TUTKIMUSTULOKSET
!"#$$%$&$'()*("+,*-+./.)0.-(,1(2+,*-/32((3+3"4,5..($"$6,*-0)/..*
!"#$
,-'./00""1'"0
%#&''(')'$"*++#"
23
#/1-44"'#'"4
'$"*+"#54
:
<
3
2
B
=
A
@
?
;
<:
<<
<3
<2
#$**$
;
?
;
<<
2
2
<
?
2
<
<
2
<
<
78
21(,,*'3
<=.>
<2.>
<=.>
<?.>
=.>
=.>
3.>
<2.>
=.>
3.>
3.>
=.>
3.>
3.>
9::-;
61$"#.61$6'7.8$9
:
:
3@
3A
@=
A@
A2
?:
<::
3?:
<2<
3@@
@<
<=?
<<
=%,$'$003(-$'()**"*->$$0,$',(-/32((3+3"4,5..($"(
!"#$
,-'./00""1'"0
%#&''(')'$"*++#".8339C.5#'$$4.D0E'+"00+.=.60F""050#/1-44"'#"4
<;
'$"*+"#54
#$**$
=
B
B
3
<
<
<
<
<
<
<
88
32.>
<?.>
<?.>
;.>
=.>
=.>
=.>
=.>
=.>
=.>
=.>
9::-;
6##G'
$1('"F$
G)G)$1(/
D4('"$1./#'.4(*1+06F70$$0
7)G1
D4('"$1.4(*1./00+4D'H44"'#$"4
G)$)G
D4('"$1.4(*1.('$"4$"4
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''+
68
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.
[email protected] 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
[email protected]
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
- Android 2.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, [email protected], +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
0
1
2
3
A
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
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ä
0
1
2
3
4
5
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
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)"%45,%6)%2&*7)#"89*3$48$%$&:*&2%"5,"3,&;*
<85$-"#&'=*8,&3,"%2.5,%6)%2&*7)#"89*8,+1"&2#:*6$%"=)6213-,2#;*
()"&&")=*,%32.*+,*%1552.5"#&)"0)=*#,,62.&)&.&,622#*7,"3,&,2%2&;*
>26,&*+,*5$"6$.3"-+,.8)-3"==$&*7?%1@";*-)"&"=*6,--)%&,*
!")=".*+,*8,-+,.5,"3,&
(
=
=
=
=
=
A
)
=
=
=
A
=
=
*
=
=
=
=
=
=
+
3
3
3
B
3
B
,
B
=
=
=
B
B
(
=
=
=
=
=
=
=
)
=
=
=
=
=
=
=
*
=
=
=
=
=
=
A
+
=
=
A
B
=
A
B
/
=
A
=
A
A
=
=
!16)%%23#)=*&1"8"=&,
4#(/$.#*,(/$1,*($+/#'(/$'1%*,,)-'**+$-/>((77+$,##((>%#'(/$%/#((/.#'(/9
<$=$*#$%&'(&)'(&
A$=$(/>'#+$*"#$.#*,(/
B$=$;#*.&+$*"#$.#*,(/
3$=$%&#-*&$'&+1&
C$=$81-'**+-#+$'&.&&$.#*,(/
D$=$(/>'#+$'&.&&$.#*,(/
-$"&&$.$
A5"=*#16)%%23#)=*3$4&'=*=15),#&"*
!16)%%2#*&1"8""*%11@"#)#&"*
!16)%%23#)=*2%31,#2*1=*#)%3)$*
!16)%%2#*&1"8""*=15),#&"*+,*%21&)&&,6,#&"*
B'4#"=*/,3)8,="*&")01=*/)%51#&"*
>$4&"=*#16)%%2#&,*%21&&,6,"#"=*8")%"=*
C")&1,*1=*-""&&$6$#&"*-)&3)=*&1&)2&&,8"#)3#"
D22*5,%,2&)*+,*3)/"&4#"0),&
!#$%&'(&)-'#&
72
0
3
B
B
=
B
B
=
F Tietokannan kuvaus
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ä
I Haastattelurunko
1. Helppotoimisuus (kuinka oppii käyttämään?)
2. Layout, ilme, ulkoasu
3. Kenelle palvelu on mielestänne suunnattu?
4. Hyödyllisyys erilaisissa aktiviteeteissa (missä voisi käyttää)?
5. Hyvät / huonot puolet?
6. Yleisarvio
7. Taustatiedot
Sukupuoli: ! nainen
Ikä ! <20
!
20-29
!
Haastattelija:
!
! mies
! 30-44 ! 45-59 !
>60
Haastattelupaikka:
77
Päivä-/aika:
J Haastattelujen tuloksia
!"#
$%%&' ()*++%
,*##-.''/
012324100
0 $-566*'*/#/&))& #-5+*7.*6-%&'/7688&--79:"855-7+).7"%/.7%5*/''%%7&*"-55)+&-.7;86588#/&-.
012324100
0 $-566*'*/#/&))& </=%&75%'%%#%%.7%5)+&/77>7&/''-.7'*/#//7.*6-%&'/
012324100
0 $-566*'*/#/&))& +%;'%.7?5//+)''-5)@7"8<8.7<%.+%5%%7&%#*/.7+).7&-.7A**#%)&
012324100
0 $-566*'*/#/&))& 6%/.*/.7#*.'%7+-;'%%7"88;8&'87+*<=%&'%79%79*)=)/.7%/.%76*/&7&/")5'%
012324100
0 $-566*'*/#/&))& <-566*7+8:''88
012324100
0 $-566*'*/#/&))& !%/++*9-.7"%5/..%'B7"*/&/+*7#))''%%7&/'-.C7-''87<%+)+-.''88.7"*/&/7/'&-7+/;9*/''%%7-&/#27
?#%9*/')&@79*55*/.75/&'%/&/7"%/.7<%5)')'76%/+%'27D5/&/7<-56*#6/7+)/.7.:+:/.-.7*.7'%/7*EE76%5++/-.7
6%/.-5)
4F2324100
0 $-566*'*/#/&))& *6/.7+8:''8#88.7'*=-55%7.*6-%&'/
4G2324100
H $-566*'*/#/&))& ,*<'))55/&-.7<-56*&'/C7'-&'%'')7&-+87/!%=/55%C7-''87I*+/%7JGB55%7K0L
4G2324100
H $-566*'*/#/&))& <-566*7K4L
4G2324100
H $-566*'*/#/&))& +%;''%.8+:#87"*/&/7*55%7-.&/&/9%/.-.7K4C7#/-&L
4M2324100
0 $-566*'*/#/&))& <-566*7N7*6/.7+8:''8#88.7.*6-%&'/7"%/++%7#/.)55%7-/7*5-785:6)<-5/.'%
4M2324100
0 $-566*'*/#/&))& -.7*&%..)'7+8:''887+%;''%%7-.+87*/+-/.7&%%.)'7&//'87&-5"88
4G2324100
H $-566*'*/#/&))& &-5%/#-.7O%P+>.%66/7"-/76*/&7&*"-55)+&-&'%7K0L
H2324100
0 $)*.*%
</=%&7K9*<')/7'/-'':7.-'/&'87#)''%7'*+/7"%/+)''%%7+8:''898+*+-#)+&--.L
012324100
0 $)*.*%
,%/+/&'%76%/+*/&'%79%7;-/'-/&'87-/7*5-7'/-'*9%
0Q2324100
0 $)*.*%
+%;'%.7'*/#/"))=-&&%7*.R-5#/%C7'%;+-.'%#/.-.7<%.+%5%%
4F2324100
0 $)*.*%
-/7'/-'*9%7+%/+/&&%7+*<=/&&%C7-&/#27S-);%&%%;/7T75)*.'*'::66/7*5/7':<98
4F2324100
0 $)*.*%
9)#/'')/75%'%%#%%.7))''%7&/")%76%;/7+-;'%%C7#))'-.7'*/#/7.*6-%&'/
4F2324100
0 $)*.*%
5%'%&/7+%;''%%7#-5+*76/'+88.7
4F2324100
0 $)*.*%
+%;'%.75//+)''-5-#/.-.79%7&));-.'%#/.-.U6/-.-.'8#/.-.7*5/7#-5+*7</=%&'%
4G2324100
H $)*.*%
+%;''%&:#O*5/'7K4L
4G2324100
H $)*.*%
6/-.-'7.8668/#-'7:58"%5/+*&&%7K4L
012324100
0 $:"88
(8</%5)--&/7N7&/")7*.7'*=-55%7<:V=:55/.-.79%7&/-5'875V:'::7#/-5-.+//.'*/&/%76%/++*9%
0Q2324100
0 $:"88
65)&&%%7&-5+-/&'87+)"/&'%79%7&:#O*5-/&'%
4F2324100
0 $:"88
'*/#//7.*6-%&'/
4F2324100
0 $:"88
W*=-55%7<:"87/=-%
012324100
0 $:"88
!%59*.76*'-.'/%%5/%X7Y=-%.%7'*=-55%7<:"827!%5"-5/&/7-&/#27+%)6).+/5%/&'%7;-'+-/5/98879*+%7&%/&/7
&*"-55)+&-&'%7"/;')%%5/&-.7*66%%.
012324100
0 $:V=:55/&::&
<%)&+%75/&87;-'+-5587+).7<%5)%%7"8<8.7?-+&';%6))<%%@79%79%+%%7+*+-#)+&/%7&%#%.<-.+/&/55-7
+%"-;-/55-7K68/"/':+&-'C79)')'C75)*+/')&79.-L
012324100
0 $:V=:55/&::&
<:V=:55/.-.7+).7<%5)%%75V:'8876/-./8C7-;/+*/&-#6/%76%/++*9%79*/'%7-/7+%;'%&&%7.8:
012324100
0 $:V=:55/&::&
');"%55/&))=-.7')..-7N7"*/&/7.8<=87+-'87*.758</&'V55827Z6)%7<8'8'/5%.'-/&&%
4G2324100
H $:V=:55/&::&
"*/&/7%.'%%7"%;)&'-*<9-/'%7-&/#27+-.R/&'87-'-.+/.7)5+*#%%5%/&/55-7K0C7.%/.-.L
4G2324100
H $:V=:55/&::&
*#/%7;-/''-987"*/&/79%+%%7:<'-/&V55/&-&'/
012324100
0 ,-.-55?7*5-.75//%.7"%.<%7+8:''8#88.7'855%/&/%@7
012324100
0 ,-.-55*#%'*/#/&-'7;-'+-/5/98'
012324100
0 ,-.-55'-+.//+%&'%7+//..*&').--'7N7'*'').--'7+8:''8#88.75%/''-/'%79%7&*"-55)+&/%
012324100
0 ,-.-55&-55%/&-'79*'+%7#))'-.+/.7%+'//"/&-&'/7+8:''8"8'7%5:6)<-5/#-.&%7&*"-55)+&/%79%76-5%%"%'7&/5587
012324100
0 ,-.-55.)*;-'
012324100
0 ,-.-55"*/&/7*55%7<:V':87#:V&7*6-')&#/-5-&&87K5%9/'/-'*)&B75/..)'C7&/-.-'C7+%&"/'79.-L7[%7#:V&7
6%/+%55/&</&'*;/%%
0Q2324100
0 ,-.-55\7<%;;%&'%.79*+&--.+/.7"8<8.75)*.'*;-'+-/5:8C7#)''%7-'-.+/.7))'--.76%/++%%.7#-..-&&87"*/&/.7
<:"/.7+8:''887'855%/&'%76%5"-5)%X\
4F2324100
0 ,-.-55<:"87&/-./O*.R%;-/554F2324100
0 ,-.-55&-5"8&'/7&))..%'')7@]%P-O**+>&)+)6*5"-55-@79*/55-7&*&/%%5/.-.7#-=/%7'8;+-887#:V&7
5)*.'*;-'+-/5:&&8
4F2324100
0 ,-.-55"*/&/7*55%7<:"87%6)7+*+-#%''*#%55-7;-'+-/5/9855-7N7%)''%/&/7*5-#%%.7-+&:#8''8C75%9/-.7
')../&'%#/.-.C76%/++*9-.7K!DYB'L7<-56*&'/75V:'8#/.-.79%7');"%55/&))&
4F2324100
0 ,-.-55<:"87.)*;/55-79%7#)/55-79*'+%7*"%'7+*+-#%''*#/%75)+-#%%.76-;/.'-/&/87+%;''*9%79%7
&))../&'%#%%.7.//=-.7%")55%
4F2324100
0 ,-.-55'8#87"*/&/7*55%7<:"87%6)"85/.-7*6-')&#/-5-&&8C7-&/#275-/;/+*)5)'27^*/&/+*<%.7'8<8.75/&8'87
9*.+/.5%/&/%77@'-<'8"/8@7-&/#-;+/+&/75%9/-.7')../&')&'%C7&))../&')&'%C7-;8<-.+/&/87'-<'8"/879.-277
4F2324100
0 ,-.-55W8#8.'::66/&-'7&*"-55)+&-'7"*/&/"%'7%)''%%7.)*;/%+/.7/..*&')#%%.75)*..*&&%75//++)#/&-&'%
4G2324100
H ,-.-55#%'+%/5/9*/55-79%7"/;+/&':&+8:''VV.7K4L
4M2324100
0 ,-.-559*&7;-'+-/5/&/.7-.-##8.7+8:''8/&/.7'8'875))5'%"%&'/
4F2324100
0 ,-.-55"*/&/+*<%.7'855%/&'%76%5"-5)%7+8:''8879*55%/.7'%"%55%7<:V=:+&/7#-'&8&'89/55-_7W%/7%/.%+/.7'8#8.7
+%)''%7"*/&/7/5#*/''%%7#)/55-7;-'+-/5/9V/55-79*&79*55%/.758</%5)--55%7*.79%<'/7+8:../&&879.-2
4G2324100
H D#/.%/&))&'*/"- *5/&/7+/"%7.8<=87-&/#27')5/6%/+%&'%7+)"%77K0L
4G2324100
H D#/.%/&))&'*/"- -&/#27)/#%6%/+%'79*/</.7"*/76)5%<'%%7K&//&7&*6/"%'7;%..%'75%##/55%7>7-/7"/;%55/&-'7)/#%6%/+%'7K0C7
.%/.-.L
78
LIITE J. HAASTATTELUJEN TULOKSIA
!"#$#!%&&
&S#$#!%&&
' ()*+,*-..-/0*12 32/42+5-..++*//26.7,6126.8595,++,57,:,)2/:*+;540/0+,<52-*)#54)#);;:;<5)*/;5=,6.,*-*5/2=>;5
?@:*66,.-5/.6*7,*4,66,##A5B,5:2*/*+51,,/*).-/,-054./2+5:*++24,:/0*--,5?&A
! ()*+,*-..-/0*12 +C4C*-2+5-*B,*++*+56*-;4-*506*-*5=C1;5+;4C;5)CD-54;C//;B;+5=,6.,),+50-0*//22+56;=*C)7;:*-/D+5
,4/*1**/22/*/5B,540=/22/5?2-*)#5B0-5062+5)2+0--,5B0++24*+5B,5=,6.,+52/.4;/22+5/,:4*-/,,5)*/;5
/242)*-/;56;=*-/D66;50+A
' ()*+,*-..-/0*12 :,B,.4-**+56*-;4-*5)CD-5E,10*+542+//;E<5B066,54;C//;B;510*5=,42,5)*2622+-;5B.06,=/,+.//,5,-*,,5
?2-*)#5B0-5=,6.,+52/-*;5).-/*40*/,<510*-*5=,4.42+//;;+54*:B0*//,,5E).-/*44,E5B,5/.604-2+,5+;4C*-*5
2:*6,*-*,5).-/*44,,+56**//C1*;5,-*0*/,A
& ()*+,*-..-/0*12 7CD:;*6*BD*662510*-*542=*//;;5:2*//*-.0-*/.4-*,<2-*)#7,:*+5406)2+7;*1;+5:2/42/5
70*8+22+<),B0*/.-2=>0/.4-*+22+5B+2#
& ()*+,*-..-/0*12 C=/2*-D66*-CC>2-/;810*-*542=*//;;5F,G2H004),*-2)7,,+5-..+/,,+I26*52//;510*-*56.0>,50),+5
7:0F**6*+54,*44*+25/*2/0*+22+5B+2#
& ()*+,*-..-/0*12 J/.-*1.66,510*-*5066,56C=C2-/*542::0//.5)*-/;50+54C-2
' ()*+,*-..-/0*12 70*+56*-;C4-2--;<51,*44,5-*2+*7,*44,5/,*562*:*7,*44,<510*-*5:,B,/,542+26625+;4CC54.+5F,G2H004*--,
' ()*+,*-..-/0*12 :2/4*7;*1;4*:B,+5?)*--;54;C+C/5)*660*+4*+A5B.64,*-2)*+2+5
& ()*+,*-..-/0*12 7,*440B2+5B,54;C/;++D+51*+44*2+5B,4,)*+2+5:2,,6*,B,--,506*-*5/0>266,5=CD>C66*-/;
& ()*+,*-..-/0*12 L;=;+510*-*5)CD-56,>,/,57CD:;:2*//2B;51;=;+5-,),,+5/,7,,+54.*+5F*66,:*-/*/95-*1.-/066,
& ()*+,*-..-/0*12 M*-;;5*+F0,54,*1,//,*-**+<52-*)#56,,1.B2+5400-/,<57;*1*/C-/;5+**>2+51,:,.-/*6,+/22-/,<57,6126.*>2+5
,.4*060,B0*-/,5B+25B+2#5
' ()*+,*-..-/0*12 =2*,=2*,#G0)9/CC77*+2+5:,70:/0*+/*5)CD-56.0+/0:2/42-/;510*-*54**++0-/,5)0+*,<50+5,*+,4*+5
/:2+>*5952*5/0-*+5*++0-/,5=2+4*6D40=/,*-2-/*5?&<5)*2-A
& N640,-.
4.1*,5B,51;:2B;510*-*5066,56*-;;
& N640,-.
=C1;/<5-2642;/5/24-/*/5-24;5@:,F**44,
& N640,-.
O(P5Q57*-/22/5+;C//;1;/5-24,1,6/,54,:/,66,5Q5)*/2+5+25-,*-*5+;4C);;+5-2642;))*+R
& N640,-.
1*-.,,6*-2-/*5-2642;54040+,*-..' N640,-.
40=>26*-/,50+57*/4;<5S4)57;;--;50621,55N:B,+5TG52*54**+0-/,<510*-5066,51,*+56;=*));/5?&A
' N640,-.
C6;1,6*440510*-*5-2.:,/,5-G:066,/2--,5?&A
' N640,-.
-2642;<5C4-*+42:/,*+2+50+5=C1;5?&A
' N640,-.
+;C//;;572:.--01266.4-26/,<52*50),,5*6)2//;5?&A
' N640,-.
H:;+>;C-5?2-*)51;:*66;A5?&A
' N640,-.
7*2+2/5+,7*/5C6;1,6*40--,5?*O,>A<51,*42,52:0//,,5/0*-*-/,,+<510*-*5066,5-..:2)7*,5?!A
& N640,-.
-2642;+5060*+2+54040+,*-..& N640,-.
)26405-2642;5.640,-.
& V62*-/;
4;C/;+5,*+,57,72:*-*,54,://0B,5/,*54.6B2+51**//0B2+5).4,,+5Q57*>;+572:*+/2*-2))*-/;57,6126.*-/,
K V62*-/;
7,6,.//22+5,+/,)*+2+57,*4,-/,5/.6225066,5),=>066*-*)),+5=26770,<52//;5-*/;5B,4-,,5/2=>;
& V62*-/;
V=/2*-D66*-2+5:2/42*6C+5,B,/.-50+54**++0-/,1,#5L0*-,,6/,54,*44*,57,*440B,5/,*54042).4-*,52*5=,6.,5
B,4,,5).*>2+54,+--,5
& V62*-/;
W*1.-/0+57;*1*//;)*+2+5Q54.*+4,5.-2*+5/,7,=/..R5X0*4057,*440B,Y/*2/0B,5*/-24*+57;*1*//;;R
& V62*-/;
..>2+5/24+060@*,+57,:,-50)*+,*-..-5?2-*)#5*O=0+25B,5)../5;6C7.=26*)2/A50+5),=>066*-..-5
-,,>,5,B,+40=/,*-/,Y,B,+/,-,66,50621,,5/*2/0,5:2*/2*-/;<5,.4*060,B0*-/,5B,57,6126.*-/,
& V62*-/;
C=/2*-D66*-CC>2--;57,:=,,+,5),=>066*-../2+,5+;2+54;C/;++D+51*+44*2+51,*=/,)*-2+YB,4,)*-2+
&S#$#!%&&
!K#$#!%&&
& V62*-/;
& V62*-/;
!K#$#!%&&
& V62*-/;
!K#$#!%&&
& V62*-/;
!"#$#!%&&
' V62*-/;
!"#$#!%&&
' V62*-/;
!"#$#!%&&
' V62*-/;
!"#$#!%&&
!U#$#!%&&
!U#$#!%&&
!U#$#!%&&
!U#$#!%&&
'
&
&
&
&
!U#$#!%&&
!U#$#!%&&
& V62*-/;
& V62*-/;
&!#"#!%&&
&!#"#!%&&
'#$#!%&&
'#$#!%&&
&%#$#!%&&
!"#$#!%&&
!"#$#!%&&
!K#$#!%&&
!K#$#!%&&
!K#$#!%&&
!"#$#!%&&
&%#$#!%&&
&%#$#!%&&
&%#$#!%&&
!K#$#!%&&
!"#$#!%&&
!"#$#!%&&
!"#$#!%&&
!"#$#!%&&
!"#$#!%&&
!"#$#!%&&
!U#$#!%&&
!U#$#!%&&
!K#$#!%&&
&!#"#!%&&
&%#$#!%&&
&%#$#!%&&
&S#$#!%&&
V62*-/;
V62*-/;
V62*-/;
V62*-/;
V62*-/;
10*-*+54;C//;;57,6126.,5-*66;5-250+5=267705B,5-2642;
)../2+5=C1;5*>2,<5).//,52+5C622+-;5B..:*54;C/;5:2/42*662--;5;6C7.=26*)2+5-01266.4-*,540-4,5
-2+5,44.56077..5+**+5+072,-/*
4;C//;*-*+5:2/42*662--;+*5)*+.6625,*1,+5..>2--,57,*4,--,I5C622+-;5:2/42*62+5/./.--,5C)7;:*-/D--;5
B0660*+52+5/,:1*/-252>2-54,://,,
2+5=*:12;-/*57*>;5C=/2*-D66*-CC>2-/;YB,4,)*-2-/,5/;);+5/CC77*-266;5-01266.4-266,51,,+5=,6.,*-*+5
:2/42*66;5C4-*+54,*42--,5:,.=,--,
=,6.,*-*+5*/-25=,+44*,5-01266.4-2+<5/0*)*1,-/,5-01266.4-2-/,5),4-,*-*+5K<UU5Z..4-*0+5:2/42-/;<5
),4-,)*-2+506/,1,5=26770,5?&A
10*-*+5),4-,,5)../,),+52.:0+<5).//,540-4,54,://,),/2:*,,6*4*+5*6),*-/,5+**+52+57,6B0+5?!<5
)*2-A
,+-,*+/,60@**44,85),*+0+/,52*5/0>2++;4D*-2-/*50++*-/.<54.4,,+52*5=,6.,56.42,5M,--*+5:2/4*,*/,+5
),*+04-*,5?&A
(6*-*5-CC/;542:/0,<52//;57:0/0--,54,*44*540))2+/*/5+;4C1;/54,*4*6625?!<5)*2-A
=C1;52-*)2:4*4-*51,26/,2--,5Q5B0-5/,.407,*4,/54./2+56,,1./50+5)2:4*//C56.0/2//,1,-/*
10*-*405/;);+5,1.66,5)CD-5+,1*@0*>,540=/22-22+R
4;C/;+5)*26..))*+5/,1,66*-/,54,://,,5B,540)7,--*,
C=/2*-D66*-CC-5Q5,B,/.-50+54**++0-/,1,#5X0*-*+5),=>066*-2-/*5*/-24*+5/.0//,,5B0/,*+5-*-;6/D;54./2+5
4.1*,5B,51*+442B;
/;);+54,.//,510*-*5-,,>,5=C1*;54;C/;++D+51*+442B;
,*0+5/2-/,/,57,6126.,5B,/40--,4*+
79

ja kulttuurimatkailua tukevan mobiilipalvelun prototypointi Olli Rinne

Transcription

Similar documents

Ratkaisuja Pratsam Reader -sovelluksen ongelmiin

joonas kiiskinen virhetilanteiden havaitseminen pakkauskoneesta

Avaa tiedosto

Uusi älypuhelinsovellus, joka helpottaa yrittäjien kuittirumbaa.

Älykoru - Muistisairaille ja vähän muillekin

KIOSKI 2.0 esite - Kulttuuriymparisto.fi / Tmi Hilla Tarjanne

Saunalahti Mobiiliturvan asennus- ja käyttöohje Symbian

Lataa käyttöopas - Lappeenrannan teknillinen yliopisto

£fntiji£in^0-a ivlaIili(fiviiTU V

FACEBOOK

LATAA Lunarex - etäohjaussovelluksen ohjekirja (pdf)

Nokia DT-601 langaton laturi -käyttöohje

Verkkokokousjärjestelmien testaus

KÄYTETTÄVYYS