Source: http://docplayer.fi/1597728-Palautekooste-jhs-129-julkisten-verkkopalvelujen-suunnittelu-ja-kehittaminen.html
Timestamp: 2016-12-10 05:01:22+00:00
Document Index: 6179694

Matched Legal Cases: ['kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ']

⭐Palautekooste: JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen
Palautekooste: JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen
Download "Palautekooste: JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen"
1 Palautekooste: JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen 1. Organisaatio Vastaajien määrä: 24 - Köyliön kunta - Yksityishenkilö - Yksityishenkilö - Yksityishenkilö - Tike, maa- ja metsätalousministeriön tietopalvelukeskus - Yksityishenkilö - Espoon kaupunki - Arkistolaitos / kansallisarkisto - Helsingin kaupunki - oikeusministeriö - liikenne- ja viestintäministeriö - LVM - liikenne- ja viestintäministeriö - Tulli - Kuuloliitto ry - Oulun kaupunki - Aalto yliopisto - Eduskunta - NÄKÖVAMMAISTEN KESKUSLIITTO RY - Aalto yliopisto - TEM ja hallinnonalan toimijat - Suomen Kuntaliitto - Kehitysvammaliitto ry - Valtioneuvoston kanslia - oikeusministeriö 2. Yhteyshenkilön tiedot Vastaajien määrä: Yleiskommentit Vastaajien määrä: 16 - Kommentoin tässä vain liitettä 1 - Ihan hyvää työtä, mutta sisältää rankan rajauksen: "Verkkopalvelulla ei tarkoiteta tässä yhteydessä esimerkiksi palvelimen verkkoon tarjoamia palveluita (network services)". Eikö valtaosa nykypäivän verkkopalveluista tuoteta tällä network services-periaatteella? Kehottaisin huolellisesti lukemaan komission asetuksen: "N:o 976/2009, annettu 19 päivänä lokakuuta 2009, Euroopan parlamentin ja neuvoston direktiivin 2007/2/EY täytäntöönpanosta verkkopalvelujen osalta" ja arvioimaan, mitä vaikutuksia sillä on mahdollisesti tähän suositukseen. Komission asetus on sellaisenaan voimassa olevaa lainsäädäntöä myös Suomessa. [Huom. Tätä asetusta on täydennetty myöhemmin asetuksella COMMISSION REGULATION (EU) No 1088/2010 of 23 November 2010 ja vielä lisää lienee tulossa tietyiltä osa-alueilta.] Ehkä suosituksessa voisi myös ottaa kantaa joihinkin melko yleisiin teknisiin toteutuksiin, joihin sisältyy tietoturvaan (tai vastaaviin seikkoihin) liittyvää problematiikkaa. Esimerkkinä vaikkapa tämä KUUMA-kuntien viritelmä: Se herättää turhaa hämmennystä, jos käyttäjä ei ole perillä java-sovelmien teknologiasta ja sudenkuopista. - Suositus on selkeä ja kattava verkkopalveluiden suunnittelun ja kehittämisen ohjeistus. Suosituksesta saa käsityksen, että laatijat ovat perehtyneet sekä kansainvälisiin että kotimaisiin ohjeistoihin ja parhaisiin käytäntöihin. - Suositusluonnos on laaja kokonaisuus verkkopalveluiden suunnitteluun sekä kehittämiseen liittyviä näkökulmia sekä yksityiskohtia, joka ei kuitenkaan jäsentynyt loogiseksi kokonaisuudeksi. Sähköisen asioinnin viitearkkitehtuuri (SAVI) jää suosituksessa vain maininnan asteelle. SAVI-arkkitehtuuri osaltaan tarjoaa viitekehyksen sähköisen palveluiden kehittämisen tueksi, minkä vuoksi nyt kommentoitavana olevan JHS suosituksen sekä SAVI-viitearkkitehtuurin välinen suhde ja käyttötarkoitus olisi hyvä tuoda esille.2 - Hyvä ja kattava suositus. Lainsäädäntöluettelo on hyvä, koska vastaavaa ei ole saatavissa muualta. - Ohje olisi mainio paikka ottaa kantaa verkkopalvelun tietosisältöjen lisensointiin esim. standardisoiduin sisällön lisensointiehdoin (esim. Creative Commons). Sisällön osalta ohjeessa voitaisiin kannustaa huomioimaan ja selvittämään aiheesta muiden organisaatioiden toimesta tuotetut sisällöt. Olisi tärkeää virtaviivaistaa sisällöntuotantoprosesseja ja hyödyntää mahdollisimman laajasti valtionhallinnon yhteisiä verkkopalveluita (mm. Julha, Otakantaa, Suomi.fi, Finlex) joko syvempien integraatioiden tai linkitysten avulla. Ohje voisi ottaa jollain tavalla kantaa myös kevyempiin verkkopalveluihin ja viitoittaa esim. sitä miten blogialustoja (wordpress.com, blogger.com) voi hallitusti hyödyntää osana organisaation verkkopalvelukokonaisuutta. Ohjeessa tulisi huomioida valtion yhteisen julkaisujärjestelmän esitutkimushankeessa (VM057:00/2011) tehty työ. Seuraavassa kohdassa pyydetty hyväksyminen oheisilla muutosehdotuksilla ei ole oikein toimiva tapa. Toimitan muutosehdotukset, mutta ohje on sen verran keskeneräinen, että hyväksymiseen organisaation puolesta on mahdoton ottaa kantaa. - Ohje olisi mainio paikka ottaa kantaa verkkopalvelun tietosisältöjen lisensointiin esim. standardisoiduin sisällön lisensointiehdoin (esim. Creative Commons). Sisällön osalta ohjeessa voitaisiin kannustaa huomioimaan ja selvittämään aiheesta muiden organisaatioiden toimesta tuotetut sisällöt. Olisi tärkeää virtaviivaistaa sisällöntuotantoprosesseja ja hyödyntää mahdollisimman laajasti valtionhallinnon yhteisiä verkkopalveluita (mm. Julha, Otakantaa, Suomi.fi, Finlex) joko syvempien integraatioiden tai linkitysten avulla. Ohje voisi ottaa jollain tavalla kantaa myös kevyempiin verkkopalveluihin ja viitoittaa esim. sitä miten blogialustoja (wordpress.com, blogger.com) voi hallitusti hyödyntää osana organisaation verkkopalvelukokonaisuutta. Seuraavassa kohdassa pyydetty hyväksyminen oheisilla muutosehdotuksilla ei ole oikein toimiva tapa. Toimitan muutosehdotukset, mutta ohje on sen verran keskeneräinen, että hyväksymiseen organisaation puolesta on mahdoton ottaa kantaa. - Hyödyllinen dokumentti, jossa etenkin lainsäädäntölistaus nähdään tarpeellisena. Luettavuus ja sitä kautta suosituksen käytettävyys sitä soveltaville julkisen hallinnon toimijoille ei ole paras mahdollinen. Eri prioriteettitasojen tai tarkkuustasojen asioita esitetään samoissa kokonaisuuksissa, ja niiden poimiminen on siksi hieman hankalaa Esitystavassa hyvää ja lukijaa huomioivaa on lisätietolähteiden listaaminen asiakokonaisuuden käsittelyn päätteeksi. JHS-suosituksen olisi hyvä tarjota työkaluja ja esimerkkejä tai mallipohjia palvelun suunnitteluun: käyttöliittymäsuunnitelma, interaktiosuunnitelma, käyttöliittymästandardi. Suosituksesta olisi hyvä käydä selvemmin ilmi verkkopalvelun laatukriteeristön ja suosituksen yhteys. Suosituksessa voisi vahvemmin painottaa sitä, että ratkaisun elinkaari ja muokattavuus oletettavasti kasvaa, kun vältetään tuotesidonnaisuutta ja noudatetaan yleisiä standardeja. Suosituksessa tulisi vielä vahvemmin painottaa teknisten ratkaisujen merkitystä järjestelmän käytettävyydelle eri päätelaitteilla ja selaimilla. Olisi hienoa, jos suositus olisi sillä tasolla, että sitä vasten voisi arvioida jonkin verkkopalvelun toteutusta. Melko yksityiskohtainen kehitysprojektin vaiheiden kuvaaminen kohdassa 6 Esiselvitys verkkopalvelun kehittämisestä on varsin seikkaperäinen ja hyvä kokonaisuus, joka varmasti voi toimia työvälineenä palveluiden kehittäjille. - Suositusluonnos on kehittynyt eteenpäin siitä versioista, mikä julkaistiin kesäkuussa Siitä huolimatta suosituksessa on edelleen liian paljon ongelmallisia kohtia. Tässä lomakkeessa kommentoin kohtia kappaleeseen 7 asti (katson, ehdinkö kommentoida myöhemmin lisää; tulee erillisenä lomakkeena jos ehdin) - Tekstissä korostetaan ketterää kehittämistä, mutta esitetty malli on aika monivaiheinen ja raskas. Olisiko tarvetta jonkinlaiselle kevennetylle versiolle? Ylläpidon suunnittelusta ei ole juuri suosituksia. Voisi olla enemmän painoarvoa, koska se on melko merkittävä (ja pisin) vaihe suunnittelun ja toteutuksen jälkeen, ja jää liian usein liian vähälle huomiolle. On myös se vaihe, johon hyvä kehitys usein pysähtyy.3 Voisiko tässä suosituksessa antaa ohjeistusta budjettiarvion työstöön? Hyvin usein verkkopalveluprojektien kustannukset ylittyvät, minkä voisi välttää huolellisella ja asiantuntevalla budjettisuunnittelulla, mikä on varsinkin ensikertalaiselle projektin vetäjälle hyvin haastavaa. Prosessin hahmottaminen olisi helpompaa jos suositus etenisi vaihe vaiheelta. Rakenteen osalta suositusta voisi tiivistää ja tuoda pääkohdat entistä selkeämmin esiin. Myös toistoa on paljon, mikä voi haitata selkeyttä. Esimerkiksi käytettävyyttä/käyttöliittymiä käsitellään kappaleissa 5 sekä ja ja osittain myös kohdassa 9, jossa on kylläkin viittaus aiempiin kappalekohtiin. Yleinen huomioni on myös se, että suosituksessa ei viitata lainkaan hakupalveluihin ja hakupalvelujen suunnitteluun. Hakupalvelut ovat yksi palvelun keskeisimmistä osa-alueista ja hakupalvelujen suunnitteluun liittyy myös sellaisia osa-alueita kuten metatiedot, asiasanastojen käyttö, dokumenttien hallinta sekä sisältöjen/dokumenttien elinkaarimalli. Myös asiointiin liittyvä tunnistaminen ja sen eri vaihtoehdot olisi suosituksessa mainita ainakin yleisellä tasolla. - Näkövammaisten kannalta on ilahduttavaa, että nyt ohjeistossa suositellaan esteettömyyden ja saavutettavuuden huomiointia julkishallinnon sivustojen suunnittelussa ja toteutuksessa. On kuitenkin todettava, että esteettömyysnäkökohtien huomiointi koko suunnittelu-, hankinta-, toteutus- ja ylläpitoketjua ajatellen jää vaillinaiseksi. Mielestämme esteettömyys- ja saavutettavuus pitäisi olla voimakkaammin käytettävyyden rinnalla ja huomiointi kokonaisvaltaista. - Tämä on jatkoa aiemmin lähettämälleni palautteelle (aiempi kappaleeseen 7 asti, tämä kappaleesta 7 eteenpäin) - Yleisesti voidaan todeta, että suositusluonnos on hyvä ja tarpeellinen ja sitä voidaan jatkossa käyttää hyvin koulutusaineistona sekä hyödyntää mahdollisesti mm. osana projektin ja hankehallinnan toimintamalleja ja niihin liittyvää organisaatiokohtaista ohjeistusta. Dokumentin fokus on kuitenkin hiukan vanhahtava sen keskittyessä yksittäisen verkkopalvelun toteuttamiseen julkishallinnon kokonaisarkkitehtuurin tavoitteiden jäädessä toissijaiseksi tai puuttuvan tyystin. Työ- ja elinkeinoministeriön on pyytänyt kommentteja myös hallinnonalansa toimijoilta ja saadut kommentit on huomioitu tässä palautteessa. - Tarpeellinen suositus, jonka päivittäminen on todella ajankohtaista. Paljon hyvää sisältöä, mutta paljon myös samantyyppistä asiaa toistetaan monessa kohdassa. Pääosa korjauksista koskee kieliasua, tekstin selkeyttä, jatkuvasti tekstissä toistuvia täytesanoja ja yleensä tekstin selkeyttä ja luettavuutta koskevia asioita. Sisällöllisesti suositus on pääosin hyvä. Luetteloita on suosituksessa aivan liikaa ja niitä tulisi harkita huomattavasti tarkemmin. Nyt valtaosa luetteloista toimisi paremmin "leipätekstinä." Jos esim. check-listan tekeminen on jossain kohtaa tarpeen, sen voisi laatia vaikka liitteisiin erikseen tai ohjeistaa suosituksen soveltajaa laatimaan oman check-listauksen tiettyjen suosituksessa mainittujen asioiden perusteella. Nyt lähes koko suositus tuntuu pitkältä tsekkauslistalta. Sanastojen ja ontologioiden hyödyntämisestä verkkopalvelun taustalla olisi voinut lukea muutama sana enemmän, vaikka tässä viitataankin JHS 183:een. - Paikoitellen oikein hyvä dokumentti, esimerkiksi luku 5. Ja toki on hienoa, että saavutettavuus on muistettu melko hyvin pitää mukana. - Paljon hyvää sisältöä, tärkeitä uudistuksia suositukseen! Pieniä oikeinkirjoitus/kieliasuviilauksia tarvittaneen vielä (näitä ei tässä vaiheessa kommentoitu). 4. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: 204 Yhteensä Keskiarvo Suositus on tarpeellinen ,55 Suositus on otettavissa käyttöön ilman tukea ja koulutusta Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla , ,42 Yhteensä ,82 5. Suositusluonnoksen hyväksyminen Vastaajien määrä: Vastustusperusteet Vastaajien määrä: 3 - Huomioikaa tekijänoikeus ainakin puhuttaessa tekstidatan "uudelleen käytöstä" - Aluksikin, osa muutoksista on niin isoja, että muutosehdotuksiin ei voi kirjoittaa niin isoja korjauksia kuin mitä tarvitaan. Osaan muutosehdotuksista olen suoraan esittänyt mikä on korvaava teksti, mutta osa on niin isoja, että tarkoittaisi mittavaa uuden materiaalin tuottamista (mihin ainakaan minulla vapaaehtoisena ole resursseja). Yleisellä tasolla, suositusluonnos ei vastaa yleisiin verkkopalvelujen kehittämisongelmiin: - suositusluonnos jättää helposti harhaanjohtavan kuvan tuloksellisen käyttäjäkeskeisen suunnittelun luonteesta ja haasteista (erityisesti hankinta- ja kilpailutustilanteessa) - verkkopalvelujen tason laaja vaihtelu (joskus onnistuu paremmin, joskus heikommin) - suositus ei käytännössä sisällä mitään konkretiaa sille, miten suunnittelutaho saataisiin ottamaan vastuuta suunniteluratkaisujen laadusta, ts suunnittelun laatuvastuu jää käytännössä tilaajalle. Tämä tarkoittaa käytännössä rahavirtaa suunnittelu- (ja käytettävyys) toimijoille muutostentöiden kautta Tarkemmin - Palvelukaaren kehittämisen elinkaaressa ei näy ollenkaan keskeistä kehittämisen osa-aluetta: suunnittelu. Suunnitteluasioita on laitettu vaatimusmäärittelyn alle, mikä ei (tietenkään) missään tapauksessa ole loogista. Tämä on ISO ongelma Verkkopalvelun suunnittelu käyttäjänäkökulmatasolla nähdään osana vaatimusmäärittelyä (kpl 7), vaikka se on erityisesti suunnittelutehtävä, ja keskeisesti vaativa ja ratkaiseva verkkopalvelun onnistumisen näkökulmasta. Suunnittelu nähdään puolestaan lähinnä teknisen toteutuksen suunnitteluna (kpl 9) - Suositusluonnoksessa on monia epätarkkoja, vääriin tulkinnallisuuksiin mahdollisesti johtavia yksityiskohtia (mm. termien käyttö ja määritelmät) - Hankinta- ja kilpailutusnäkökulma on otettu esiin todella suppeasti ja epämääräisesti; kuitenkin se on erittäin5 keskeinen asia. johon erityisesti tämän tyyppisen ohjeiston pitäisi antaa vahvaa ohjeistusta - Vastustusperusteen kuten ensimmäisessä osassa. Tässä vielä korostuu - ongelmat tuloksellisen ja aidon käyttäjälähtöisyyden varmistamisessa - hankintaohjeistojen puutteet 7. Yleiset muutosehdotukset Vastaajien määrä: 13 - Suhde komission asetukseen verkkopalveluista (EY N:o 976/2009) on tuotava selkeästi esiin. Ellei sitä rajata kokonaan ulos suosituksesta, voisi siitä kuitenkin ottaa oppia vastaavissa yksityiskohdissa, joita on suositeltu hieman eri tavoin. - Suositus koskee yleisen verkkopalvelun suunnittelua ja kehittämistä. Ehdotamme että sanaa ja käsitettä verkkopalvelu käytettäisiin laajasti kaisissa kuvissa ja kuvateksteissä ja myös taajaan ja tiuhasti teksteissä palvelusanan kohdalla. - Ohje olisi mainio paikka ottaa kantaa verkkopalvelun tietosisältöjen lisensointiin esim. standardisoiduin sisällön lisensointiehdoin (esim. Creative Commons). Sisällön osalta ohjeessa voitaisiin kannustaa huomioimaan ja selvittämään aiheesta muiden organisaatioiden toimesta tuotetut sisällöt. Olisi tärkeää virtaviivaistaa sisällöntuotantoprosesseja ja hyödyntää mahdollisimman laajasti valtionhallinnon yhteisiä verkkopalveluita (mm. Julha, Otakantaa, Suomi.fi, Finlex) joko syvempien integraatioiden tai linkitysten avulla. Ohje voisi ottaa jollain tavalla kantaa myös kevyempiin verkkopalveluihin ja viitoittaa esim. sitä miten blogialustoja (wordpress.com, blogger.com) voi hallitusti hyödyntää osana organisaation verkkopalvelukokonaisuutta. Ohjeessa tulisi selkeästi huomioida altion yhteisen julkaisujärjestelmän esitutkimushankeessa (VM057:00/2011) tehty työ. - Ohje olisi mainio paikka ottaa kantaa verkkopalvelun tietosisältöjen lisensointiin esim. standardisoiduin sisällön lisensointiehdoin (esim. Creative Commons). Sisällön osalta ohjeessa voitaisiin kannustaa huomioimaan ja selvittämään aiheesta muiden organisaatioiden toimesta tuotetut sisällöt. Olisi tärkeää virtaviivaistaa sisällöntuotantoprosesseja ja hyödyntää mahdollisimman laajasti valtionhallinnon yhteisiä verkkopalveluita (mm. Julha, Otakantaa, Suomi.fi, Finlex) joko syvempien integraatioiden tai linkitysten avulla. Ohje voisi ottaa jollain tavalla kantaa myös kevyempiin verkkopalveluihin ja viitoittaa esim. sitä miten blogialustoja (wordpress.com, blogger.com) voi hallitusti hyödyntää osana organisaation verkkopalvelukokonaisuutta. Seuraavassa kohdassa pyydetty hyväksyminen oheisilla muutosehdotuksilla ei ole oikein toimiva tapa. Toimitan muutosehdotukset, mutta ohje on sen verran keskeneräinen, että hyväksymiseen organisaation puolesta on mahdoton ottaa kantaa. Valtion yhteisen julkaisujärjestelmän esitutkimushankeessa (VM057:00/2011) tehty työ huomioitava ohjeessa. - JHS-suosituksen olisi hyvä tarjota työkaluja ja esimerkkejä tai mallipohjia palvelun suunnitteluun: käyttöliittymäsuunnitelma, interaktiosuunnitelma, käyttöliittymästandardi. Suosituksesta olisi hyvä käydä selvemmin ilmi verkkopalvelun laatukriteeristön ja suosituksen yhteys. Suosituksessa voisi vahvemmin painottaa sitä, että ratkaisun elinkaari ja muokattavuus oletettavasti kasvaa, kun vältetään tuotesidonnaisuutta ja noudatetaan yleisiä standardeja. Suosituksessa tulisi vielä vahvemmin painottaa teknisten ratkaisujen merkitystä järjestelmän käytettävyydelle eri päätelaitteilla ja selaimilla. - Sisällön ulkoasun selkiyttäminen, yhtenäiset esitystavat esim. listoille. Linkkien perään viittauspäivämäärä, osa linkeistä jo nyt ei tarjoa sisältöä, jota pitäisi, eli linkit viittaavat esim. yleiselle, josta viitattu tieto on jo siirretty muualle. - Nämä käynevät ilmi muista kommenteista, mutta tiivistettynä: - vaatimusmäärittelyn ja suunnittelun suhde pitäisi määrittää kokonaan uusiksi - vaatimusmäärittelyn sisältö pitäisi määrittää; esimerkiksi jää epäselväksi, mitä ovat "käytettävyysvaatimukset" - käyttäjälähtöisyys on monin paikoin kuvattu epäselvästi/ harhaanjohtavasti - hankinta ja kilpailutusosio on köykäinen; tähän kuitenkin olisi erityistä tarvetta - useat termit, yksityiskohdat - Pahimman pettymyksen aiheuttaa kohdassa "Verkkopalvelun vaatimusten ja toiminnallisuuksien määrittely", jossa todetaan: "Esteettömyydessä tulee pyrkiä vähintään WCAG 2.0 -ohjeen A-tason toteutumiseen. On6 kuitenkin huomattava, että A-tason toteuttaminen ei mahdollista sivujen esteettömyyttä kaikille käyttäjäryhmille." Näkövammaisten kannalta A-taso ei paljon lämmitä eikä se ole linjassa direktiiviehdotuksen (COM(2012) 721) kanssa. - muutosehdotuksia siis kappalesta 7 eteenpäin - Luonnosta ovat ilmeisesti olleet kirjoittamassa eri henkilöt, koska kirjoitustyyli on eri osissa erilainen ja jäsentelytyyli on joiltakin osin hieman sekavaa. Luonnoksen luettavuus ei ole paras mahdollinen, kun tekstissä on niin paljon viittauksia liitteisiin ja viitteisiin. Jos mahdollista, voisi viitteiden ja liitteiden keskeisimmät huomioitavat kohdat koota kunkin kappaleen tekstin yhteyteen. Samoin eri aineistojen www-osoiteeet voisi laittaa alaviitteksi eikä kuormittaa niitä tekstiosuutta Luonnoksessa on osittain mukana myös projektin/hankkeenhallintaan liittyviä osa-alueita. Osa niistä on geneerisiä eivät spesifejä juuri verkkopalvelujen kehittämiselle. Tältä osin toivoisimme vielä suosituksen läpikäymistä ja ao asioiden priorisointia ja osin kirkastamista. Varsinkin mikäli JHS-suositustyötä ollaan käynnistämässä projetinjohtamiseen/hallintaan liittyen. ==> Tämän suosituksen yhteydessä tulisi huomioida mm. piakkoin käynnistyvä julkishallinnon projektien johtamista käsittelevän JHS-suosituksen kehitystyö ja siihen liittyvä julkaistun ISO-SFS Ohjeita projektinhallinnasta siltä osin kuin ko. suosituksen asiat liittyvät nimenomaan geneeriseen projektinhallintaan eivätkä nimenomaan verkkopalvelun kehittämisen substanssiin - Kieliasua on muokattava paremmin luettavaksi. Tekstissä on aivan liikaa luetteloita, jotka ovat vielä usein kolmiportaisia. Täytesanoja, kuten "myös" toistellaan liikaa. Lauseet ovat usein liian pitkiä tai niissä on liian monta asiaa. Myös otsikoita ja sisälötöjen uudelleen ryhmittelyä voisi miettiä napakammaksi. Suosituksessa on paljon tekstiä, mutta se voisi olla ytimekkäämpi. - Kannattaisi ehkä valita kumpaa termiä pääsääntöisesti käyttää, saavutettavuutta vai esteettömyyttä. Nyt lukija saattaa hämääntyä, koska niitä käytetään aivan sekaisin. - Rakennetta ja jäsentelyä voisi vielä hioa siten, että asioita ei toistettaisi eri kohdissa, vaan ne esiteltäisiin selkeämmin oman otsikkonsa alla. Voisiko otsikointia ja asioiden käsitelytapaa muuttaa siten, että kukin asia esiteltäisiin ja selitettäisiin kappaleen/luvun alussa ja sen jälkeen olisi selkeitä ohjeita siitä, miten suosituksen lukijan/käyttäjän tulisi suunnittelu ja kehittämistyössä toimia. Suositus voisi esimerkiksi vastata kysymyksiin: 1) mitä xx tarkoittaa 2) miten xx:n suhteen toimin ja toteutan. Rakennetta voisi selventää mahdollisesti myös käyttämällä otsikoinnissa elinkaarimallin termejä sellaisenaan. 8. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 2 - Johdannossa olisi ollut tarpeen määrittää tarkemmin se, mitä palvelun käsitteellä tämän suosituksen näkökulmasta tarkoitetaan. Lisäksi johdannossa olisi ollut hyvä linjata se, mikä on tämän suosituksen ja aihealueeseen liittyvien viitearkkitehtuurien suhde. - Tämän suosituksen tarkoituksena on opastaa julkisen hallinnon organisaatioita verkkopalveluiden (verkkosivustojen ja asiointipalveluiden) suunnittelussa, hankinnassa ja toteutuksessa. Jos hankintaa ja kilpailuttamista ei kuvata huomattavasti tarkemmin kuin mitä kappaleessa 8 on kerrottu, niin ei voi sanoa, että tämä suositus ohjaa verkkopalvelujen hankinnassa. Joko suositusta pitää tarkentaa tältä osin, tai jättää pois että se antaa ohjeita hankinnalle 9. Muutosehdotukset kappaleeseen 1.1 Suosituksen rakenne Vastaajien määrä: 6 - Palvelun kehittämisessä ei tule nojata vanhanaikaiseen ja toimimattomaan malliin, jossa ensin tehdään vaatimusmäärittely, ja sitten hankinta/kilpailutus. Tätä ei ole helppo asia, mutta tässä voisi tuoda esille sitä, että kehittämistä tehdään iteratiivisesti mm. vaatimusmäärittelyä jatkuvasti tarkentaen. - Palvelusana kuvassa ja kuvatekstissä: muutos verkkopalvelu -sanaksi - palvelun kehittämisen elinkaarta kuvaavat vaiheet olisi ollut hyvä linkittää varsinaisiin tekstilukuihin. - Elinkaarimallissa on iso ongelma: (verkkopalvelun) suunnitteluratkaisujen (käyttäjänäkökulmasta, ei teknisen tason) tuottaminen puuttuu kokonaan. Elinkaarimalli tulisi muuttaa siten, että suunnittelu on keskeinen elementti ylemmällä tasolla.7 Suunnitteluratkaisujen tuottaminen ei voi olla mitenkään osa vaatimusmäärittelyä - Positiivista, että suosituksessa on huomioitu palvelun kehittämisen koko elinkaari mukaan lukien mysö palvelun jatkuva ja hallittu kehittäminen. s. 2 sivu 1: Palvelun kehittämisen elinkaari ja sen hallinta Kuvassa voisi olla mukana myös päätös- ja tarkistuspisteet (ml. arkkitehtuurin mukaisuuden tarkistuspisteet) kuten ao pisteet ovat mukana samankaltaisessa kuvassa sivulla 10 (kuva 2). - ks. yleiset 10. Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: 5 - Suhde komission verkkopalveluasetukseen em. yleisen muutosehdotuksen mukaisesti. - Suositus pyrkii olemaan täydellisen kattava kokonaisuus sisältäen mm. palvelun kilpailuttamiseen liittyviä kysymyksiä. Suositusta olisi voinut kohdentaa huomattavasti tiiviimmäksi ja painottua palvelun määrittelyn ja yhteentoimivuuden kysymyksiin. - Suositus ei kaikilta osin sovellu suhteellisen monimutkaisille internetsovelluksille, kuten vaativammille karttasovelluksille, sähköposti- tai puhelinsovelluksille, ammattikäyttöön tarkoitetuille sovelluksille ja järjestelmille, peleille tai pelillistetyille palveluille. Suositukset eivät myöskään kaikilta osin sovellu ääni- tai liikeohjattuihin käyttöliittymiin." Jos näin todetaan, olisi tarkentaa miltä osin ei sovi (siis mitä tarkemmin tarkoittaa ei kaikilta osin sovellu ) - Luvun 2 kaksi ensimmäistä kappaletta voistaisiin muotoilla osin hieman eri tavalla kuin mitä luonnoksessa tällä hetkellä on - nykyisin "avoin" ja "suljettu" eivät ole niin selkeästi erillään kuin ehkä joskus aiemmin. Useissa palveluissa on vähintään ekstranet -osioita tms. tunnistautumista vaativia palveluita osana palvelukokonaisuutta. Toisaalta mikäli tässä tarkoitetaan tavanomaisemmin www. -osoitteesta eli internetin kautta löytyvää sivustoa, niin kirjaus voi olla näinkin. Suosituksen kohderyhmissä voisi mainita esim. arkkitehdit - kolmas kappale: "verkkopalvelulla ei tässä yhteydessä tarkoiteta (fyysisten) tietoverkkojen tarjoamia palveluita" voisi olla selkeämpi ilmaus. 11. Muutosehdotukset kappaleeseen 3. Viittaukset Vastaajien määrä: 5 - VAHTI 2/2013: Tämä on 1/ Tässä olisi hyvä mainita myös aiheeseen liittyvät viitearkkitehtuurit. - Viittauksissa mainitaan laki julkisista hankinnoista. Hankintoihin liittyy myös kielilaki, jonka mukaan hankinnoissa toimittava (on velvoittava). Jossain sopivassa jaksossa olisi tuotava esiin perustuslaki ja se, kuinka suunnittelussa tulisi ottaa huomioon ja varmistaa PL:ssa turvattujen perusoikeuksien toteutuminen, mm. yhdenvertaisuus, julkisuusperiaate, oikeus omaan kieleen. Jos lakiviittaukset ja pääperiaatteet ovat "liitteen varassa", niitä ei huomata/lueta - ne olisi hyvä sisällyttää jtkn perustekstiin. - Suositustekstissä viitataan standardiin ISO 13407, jota ei kuitenkaan mainita viittauksissa. Toisaalta, kyseinen standardi on vanhentunut, ja sen sijaan olisi viitattava standardiin ISO Viittauksissa on osin mukana sellaisia JHS-suosituksia, jotka ovat JHS-jaoston toimintasuunnitelmassa kaudella todettu joko lakkautettaviksi ehdotettuja suosituksia tai suosituksia, joita ollaaan tai tullaan päivittämään. Ao asia olisi hyvä mainita myös tässä yhteydessä esim. alaviitteenä (esim. sivulla 8 Julkisen hallinnon asiakkuusstrategia). 12. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet Vastaajien määrä: 10 - Käsite saavutettavuus: saavutettavuus on muutakin kuin helppokäyttöisyyttä. Saavutettavuus tarkoittaa sitä, että ihmisillä on tasavertainen pääsy ja mahdollisuus käyttää järjestelmää, laitetta, ohjelmaa tai palvelua. - Komission verkkopalveluasetus ja INSPIRE Glossary määrittelee useita käsitteitä hieman eri tavoin kuin tämä suositus. Harmonisointi olisi suotavaa, jos mahdollista. - Tiedonhallinnan käsitteen määrittelyssä voisi olla viittaus metatietoihin, esim helposti löydettävissä ja käytettävissä metatietojen avulla8 Tietomallin käsite on suppeasti määritelty. Tähän löytyisi varmasti kattavampi ja tämä olisi hyvä kirjoittaa nimenomaan verkkopalveluiden näkökulmasta. vaatimusmäärittelyn käsitteen yhteydessä painotutaan ohjelmiston vaatimuksiin, tässä olisi hyvä ohjelmisto käsite korvata palvelulla, eli vaatimusmäärittelyn avulla kerrotaan se, millaista palvelua halutaan saatavan. - termit olisi hyvä olla myös ruotsiksi, koska mm. ruotsinkieliset viranomaiset tarvitsevat termistöä. - Käyttäjälähtöinen suunnittelu, viittaus iso-standardiin > standardi on nykyään ISO Lause: "Käyttäjälähtöinen suunnittelu edellyttää entistä enemmän eri alojen yhteistyötä..." turha tai sitten korjattava toiseen muotoon, esim. "käyttäjälähtöinen suunnittelu edellyttää eri toimijoiden ja alojen yhteistyötä, koska suunnittelussa huomioitavat tekijät ovat moninaisia". Metatiedot - jokin esimerkki olemassa olevasta hyväksytystä sanastosta tai ontologiasta olisi hyödyksi ensikertalaiselle lukijalle. esim. ICD10-koodisto tai kuntakoodisto, tai jokin JHS-luokittelu. Saavutettavuus -termin tarkentaminen tähän paremmin vastaavalla tavalla kuin "käytettävyys". Nyt ei kerro oikein mitään. Esim. WCAG-määrittelystä johdettuna. Sanastosta puuttuu termi käyttökokemus, jota kuitenkin myöhemmin suosituksessa käytetään ja kappaleessa termi on avattu (kuten käytettävyyskin). Sanastoon lisättävä termi "selkokieli". määritellään kyllä kappaleessa 7.2.2, mutta sanastomäärittelyt syytä löytyä koottuna myös tästä yhdestä paikasta luettavuuden ja tarkistettavuuden helpottamiseksi. - Seuraavia muutoksia - konsepti: selkeät alaotsikot käytetyille alakäsitteelle: ylätason konsepti, käyttöliittymäkonsepti, visuaalisen ilmeen konsepti määrittelyosissa ei tulisi antaa prosessiohjeita, eli pois ohje konseptisuunnitelmia käytetään usein tavoitteita kuvaavina dokumentteina myöhempien vaihteitten kilpailutuksessa (tämä ohje on sitä paitsi harhaanjohtava; esim. eri konseptialakäsitteet tulee käsitellä eriksiin) - käytettävyys: pieni täsmennys määritelmään, jotta se olisi ISO mukainen: Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi - käyttäjälähtöinen suunnittelu: määrittely on osittain harhaanjohtava (erityisesti lähtökohtana käyttäjien toiveet ). Parempi käyttää standardin määrittelyä: "järjestelmäsuunnittelun ja kehityksen lähestymistapa, jonka tavoitteena on tehdä järjestelmät käytettävyydeltään paremmiksi kohdistamalla huomio järjestelmän käyttöön sekä soveltamalla ergonomian ja käytettävyysalan tietämystä ja tekniikoita" termien määrittelyn yhteydessä ei tulisi kertoa enempää kuin mikä on määrittelyä. Jos kuitenkin kerrotaan, niin ISO on vanhentunut. Sen korvaava uudempi standardi on ISO saavutettavuus: käyttäisin mielummin termiä esteettömyys, vaikka ovatkin synonyymejä (saavutettavuus voidaan sekoittaa termiin saatavuus, mikä on ihan eri asia - saavutettavuus (esteettömyys): määritelmä on kovin epämääräinen (otettu wikistä?). Täsmällisempi esim. ISO määritelmä usability of a product, service, environment or facility by people with the widest range of capabilities - toiminnallinen vaatimus: määritelmä ei voi olla kehämääritelmä: vaatimus, joka määrittelee kehitettävän tai hankittavan järjestelmän toiminnallisuutta. Parempi jotain "Vaatimus, joka kuvaa, mitä asioita järjestelmällä pitäisi pystyä tekemään, mitä palveluita järjestelmän tulisi tarjota" - vaatimusmäärittely: määritelmä ei sisällä keskeistä osa-aluetta, eli vaatimusten käyttöä testauksessa. Parempi esim. prosessi, jonka tavoitteena on määrittää ohjelmistolle asetettavat vaatimukset siten, että ne ovat valideja (määrittävät sisällöllisesti oikein halutun palveluna), todennettavia (niin, että niiden saavuttaminen voidaan testausvaiheessa objektiivsesti mitata) ja riittävän kattavia. Seuraavia lisäyksiä (näitä termejä käytetään muissa määritelmissä/ tai tekstissä) - toimintaympäristö - tavoiteratkaisu - toimintamalli - palveluidea - käyttäjätarve (käyttäjän tarve)9 - käyttäjävaatimus - käytettävyysvaatimus - järjestelmävaatimus - käytettävyystaso - käyttökokemus - Verkkopalvelut -käsitteellä tarkoitetaan eri yhteyksissä eri asoita. Töästä syystä on erittäin kannatettaavaa että ao käsite on avattu. Toivoisimme kuitenkin että myös käsitteet verkkosivusto, asiointipalvelu ja portaali avattaisiin. HTML 5 viittaa nykyisin usein yleisesti moderneihin web-tekniikoihin; ts. pelkän kuvauskielen lisäksi kokonaisuuteen lasketaan mukaan (tilanteesta riippuen) CSS (3) ja sovellusliittymät. Toisin sanoen HTML 5:n konsepti on laajempi kuin pelkkä merkintäkieli Kohta HTML5, viimeinen kappale. Poistetaan turhat sanat: HTML5 on uusimman sukupolven versio... --> HTML5 on uusi versio Ehdotan että termeihin lisätään "SELKOKIELI", ja sen määritelmä jätetään pois myöhemmin tekstistä. - Saavutettavuuden määritelmä on outo. Esimerkiksi wikipediassa on parempi ja se vastaa onnistuneemmin saavutettavuuden yleisintä tulkintaa. Määritelmässä tulisi joka tapauksessa mainita sen liittyminen eri käyttäjäryhmiin tai erilaisiin käyttäjiin (yhdenvertaisuus) erotuksena käytettävyydestä. - hallintamalli-termiä voisi täsmentää, että tarkoitetaan ilmeisesti tuotettavan palvelun hallintamallia (ei esim. kehittämisprojektin) verkkopalvelun omistaja -käsitettä voisi täsmentää, että tarkoitetaanko organisaatiota/organisaatioyksikköä/henkilöä 13. Muutosehdotukset kappaleeseen 5. Verkkopalvelun yleiset periaatteet ja reunaehdot Vastaajien määrä: 11 - Erinomaista, että käytettävyys ja käyttäjälähtöisyys on näin vahvasti esillä! Tarkistuspisteet ovat hyvä asia, mutta jotta esim. tietoturva ja käytettävyys oikeasti otetaan huomioon, pitäisi niiden olla leivottu sisään oleellisena osana kehittämistä.. siis tietynlainen jatkuva laaduntarkkailu. - s. 9/31 Kuvassa palvelun kehittämisen elinkaari, Ehdotus: verkkopalvelun kehittämisen elinkaari. Kuvan nimi muuttuu myös. - Voisi korostaa tarjotun palvelun ja taustaprosessin suhdetta. Teksti on tässä hyvin luettelopainotteinen - 2. kpl: huomioitava myös lainsäädäntö. 3. kpl: Jo kehittämispäätöstä tehtäessä kpl, kohta 3: Verkkopalvelun tulee myös noudattaa organisaation arkkitehtuuriperiaatteita ja linjauksia sekä lainsäädäntöä. Listaan on syytä lisätä myös laajemmin mainintaa mobiilikäytöstä. Tämä pätee oikeastaan koko suositusluonnosta: mobiilikäyttö tulee lisääntymään entisestään, ja se tulee myös olemaan joillekin ainoa käyttötapa. Tästä syystä koko palvelu - asiointeineen kaikkineen - tulee olla käytettävissä niin tietokoneella kuin mobiililaitteella. Laitteet uudistuvat niin nopeasti, että jos jonkin toiminnon käyttäminen ei olisikaan käytännöllistä vielä nyt, niin se tilanne voi olla toinen jo vuoden kuluttua, kun järjestelmää otetaan vasta käyttöön. Puhumattakaan useamman vuoden elinkaaresta. - lista kehittämisen perusperiaatteista, periaate 1.a) "käytä suunnittelussa apuna... käytettävyysvaatimuksista". Käytettävyysvaatimukset johdetaan toiminnallisista vaatimuksista. Käytettävyysvaatimusten tärkeys hukkuu nyt muun joukkoon. Tekisin käytettävyysvaatimusten ja esteettömyysvaatimusten muodostamisesta ja testaamisesta oman perusperiaatteen. 2. Rakenna sähköinen palvelu tai palvelukokonaisuus, älä pelkkiä verkkosivuja --> + tai lomaketta. Myös sähköisen palvelun tuki tulee olla saavutettavissa sähköisesti, jos mahdollista (esim. chat). Yleisesti perusperiaatteiden lista olisi hyvä laittaa loogiseen järjestykseen, siihen järjestykseen, jossa tulisi toimia (mitä tehdään esiselvityksessä, vaatmiusmäärittelyssä, toteutuksessa jne.) ja toisiinsa linkittyvät asiat yhdessä "nipussa". Esim. uusi järjestys: 2,5,3,4,13,1,6,7,8,9,10,11, konseptisuunnittelu, jossa palvelun omistaja määrittelee verkkopalvelun tehtävät, tavoitteet ja käyttäjät. Tarkenna ylätason konseptisuunnittelu, jossa... - Käytä suunnittelussa apuna olemassa olevia tietoja käyttäjistä, käyttäjätehtävistä ja halutuista10 aikaansaannoksista ja käytettävyysvaatimuksista. Mieluummin tyyliin: Käytä suunnittelua ohjaamaan olemassa olevia tietoja käyttäjistä ja käyttäjätehtävistä, määriteltyjä käyttäjien aikaansaannoksia ja käytettävyysvaatimuksia, sekä yleisiä suunnitteluohjeistoja. Varmista lopuksi, että suunnitteluratkaisut täyttävät asetetut käytettävyysvaatimukset. Toteuta palvelu tarvittavan monen käytettävyystestauskierroksen avulla. Älä tee kerralla liian suuria kokonaisuuksia vaan pyri nopeisiin toteutuksiin ja kehitä palvelua jatkuvasti aidon käyttäjäpalautteen pohjalta edelleen. Tämä voi ohjata resurssien tuhlaamiseen. Kun puhutaan toteutuksesta, se on periaatteessa toimittajan vastuulla. Ja sen vuoksi toimittajalla pitäisi olla vapaus käyttää harkitsemaansa suunnittelutapaa. Mutta voidaan toimittajalle kuitenkin osoittaa toiveita, tyyliin: Toteuttajalle voi suositella yhtenä menettelytapana, että toteutuksen voi tehdä monen käytettävyystestauskierroksen avulla, tekemättä liinan suuria kokonaisuuksia vaan pyrkimällä nopeisiin toteutuksiin. (Luulisi toimittajan automaattisesti huomioivat ohjeen Muista kuitenkin suunnitella ja määritellä testattavat versiot huolellisesti turhan testaamisen ja kustannusten välttämiseksi, jos kerran toimittajalla on vastuu suunnitteluratkaisujen laadusta) Lisätietoja kohtaan voi laittaa viitteiksi ainakin ISO Kohdassa 7 on lause: Suunnittele palvelusta mahdollisimman yksinkertainen ja helppokäyttöinen. Ehdotamme poistettavaksi sanaa yksinkertainen, sillä palvelun johdonmukaisuus ja toimintavarmuus on keskeisempi arvo kuin pelkkään yksinkertaisuuteen pyrkiminen. - Vekkopalvelujen kehittäminen esrityisesti sähköisten asiointipalvelujen kehittäminen liittyy keskeisesti toiminnan ja palvekujen kehittämiseen (ml. prosessien kehittäminen). Nyt listalta sivulta 8 " verkkopalvelujen kehittämisen periaateet" puuttuu maininta asiointipalvelujen kehittämisen kytkeytymisestä taustajärjestelmiin (back-officeen) sekä siihen miten käyttöönotettava sähköinen asiontipalvelu muuttaa organisaation/toimijan omaa tekemistä ==> ei pelkästää asiakkaan toimintaa. Samoin periaate 2 on osin "kummallinen" - voidaanhan verkkopalvekuja kehitettäessä kehittää sekä verkkosivustoja että asiointipalveluja. Periaate 8: "Linkittäminen" nykyisin laajempi kokonaisuus kuin aikaisemmin; ei siis enää pelkästään liity hyperlinkkeihin, vaan myös esimerkiksi palvelun sisällön syndikointi verkkosyötteillä (esim. RSS, Atom), leijukkeilla, iframella yms. tekniikoilla. Tulisiko tämä kehitys huomioida myös tässä yhteydessä? - 1. Toinen kappale, viimeinen lause. Jätetään pois sana "esimerkiksi". 2. Kolmas kappale, viimeinen lause. Muutetaan muotoon: Päätöksentekoon kuuluu myös rahoitusmallista päättäminen sekä Neljäs kappale: jätetään pois sana "myös" ja "yleisen." 4. Viides kappale muutetaan muotoon: Tyypillisesti organisaatioissa pyritään ohjaamaan asiakkaat muista palvelukanavista sähköisiin kanaviin kustannustehokkuuden lisäämiseksi sekä asiakkaan asioinnin joustavuuden parantamiseksi. Johdon tulisi seurata asetettujen vaatimusten toteutumista ja tehdä jatkokehittämistä koskevat linjaukset...jne. 5. Luettelo, muutetaan seuraavasti: 1. Tunnista käyttäjien tarpeet. (jne.) 3. Varmista palvelun yhdenmukaisuus organisaation strategian ja tavoitteiden kanssa. Verkkopalvelun tulee noudattaa organisaation... jne. 4 a. Selvitä organisaatiorajat ylittävät prosessit, palvelu, tiedot sekä tietojärjestelmät ja verkkopalvelun liittymät niihin. 7a. Varmista käytettävyys, selkeys ja esteettömyys käyttämällä valmisteluun riittävästi aikaa ja oikeanlaista asiantuntemusta. 7b. Huomioi käyttäjien erilaiset valmiudet palvelun suunnittelussa. 8. poistetaan lauseen toinen sana "myös". 9. Muutetaan --> Toteuta palvelu käytettävyystestauskierrosten avulla. Älä tee kerralla liian suuria kokonaisuuksia, vaan pyri nopeisiin toteutuksiin. Kehitä palvelua jatkuvasti aidon käyttäjäpalautteen pohjalta. 9a) poista sana "kuitenkin". (-Tämä kohta on myös turhaa toistoa, voisi poistaa). 10. poistetaan sana "riittävän" 12b: poistetaan sana "aina" 13. Muutetaan muotoon: määrittele suunnitteluvaiheessa, miten palvelua ylläpidetään ja jatkokehitetään sekä miten käyttäjäpalaute ja tarpeet huomioidaan. Lisäksi tässä luvussa käytetään samantapaisissa yhteyksissä verbejä "tarkistetaan" ja "tarkastetaan" - Tämä kaipaa selkeämpää jäsentelyä. Voisiko perusperiaatteet olla oma väliotsikkonsa ja kohdat 1-13 nimetty ytimekkäämmin. Esim. 1. Tunnista käyttäjien tarpeet. - Suunnittele palvelu käyttäjätarpeiden pohjalta. - Käytä suunnittelussa apuna olemassa olevia tietoja käyttäjistä, käyttäjätehtävistä ja halutuista aikaansaannoksista ja käytettävyysvaatimuksista. - Hyödynnä suunnitteluohjeistoja ja -standardeja. Kohdat 1-13 olisi ehkä syytä järjestää jollakin kriteerillä, esim. ryhmitellen toisiinsa liittyviä kohtia tms. - Sivujen sisällön selkeyden ja viihtyisyyden merkitys11 Olisi suotavaa että oltaisiin sovittu julkishallinnon sivustojen olevan helposti lähestyttäviä, viihtyisiä, puhuttelevia ja palvelevia. Nämä arvot kirjataan suunnitteluperiaatteiksi joita käytetään määrittelyyn liittyvissä valinnoissa palvelua toteutettaessa. Suunnitteluperiaatteilla tarkoitetaan niitä kokonaisuuksia, johon palvelun suunnittelijat perustavat ratkaisunsa. Mainitut periaatteet eivät poissulje yleisiä palveluiden suunnitteluperiaatteita, mutta esimerkiksi ristiriitatilanteessa ratkaisevat suunnan kumpi on tärkeämpi. Vaikkapa näin: Positiivisuus Positiivinen palvelu palkitsee käyttäjänsä, innostaa kokeilemaan uutta ja kannustaa seuraavaan klikkaukseen turvallisesti. Käyttäjä palaa mielellään uudelleen palveluun, joka tervehtii ja kiittää. Avuliaisuus Käyttäjän ollessa on kiinnostuneempi asiastaan kuin siihen liittyvistä lainmukaisista prosesseista, täytyy palvelun tarjota hänelle lisätietoa, esimerkkejä, apua. Täsmällinen ohjeistus vähentää epätietoisuutta sekä aikaansaa positiivista palautetta. Palveleva Ohjeissa ja toiminnoissa aputeksteissä käyttäjälle kerrotaan mitä toimimisesta ja tekemisestä seuraa, ja mitä hyötyjä käyttäjälle näistä seuraa. Esim. Osallistumisesta luvataan yhteenveto ja Vetuma-vahvistusta tarjottaessa kerrotaan käyttäjälle että rekisteröityneenä pääsee useampiin hankkeisiin osallistumaan. Yksinkertaisuus Kun suunnitellaan toiminnallisuuksia, toteutetaan yksinkertaisin mahdollinen toiminnallisuus tai käyttöliittymällä jolla käyttäjä saa ydintoiminnallisuuden hyödyt. Lisä- tai vaihtoehtokäyttötapauksien toteuttamisen päätökset suositellaan tehtäväksi metriikkadatan tai käyttökokemustutkimuksen konkreettisten löydösten perusteella. Ulkoasun viihtyisyys Ammatti- ja pääkäyttäjäkäyttöön toimivat ulkoasultaan viimeistelemättömätkin sivut. Kuluttajapalvelussa epämiellyttävyys ulkoasussa heijastuu palvelukokemukseen. Viimeistelty sivu toimivine muotokielineen osoittaa arvostusta lukijaa kohtaan kuten netiketin noudattaminen ja selkeä suomenkielinen tekstikin. Mielikuvan luominen yksinkertaisella tasapainoisella ulkoasulla vaikuttaa paitsi palvelun brändimielikuvaan, myös käyttäjien mielialaan ja käyttäytymiseen palvelussa asioitaessa. Erityisesti sosiaalista vuorovaikutusta hyödyntävissä tai ihmisten prosesseja sähköistävissä palveluissa tämä vaikutusketju on syytä ottaa vakavasti: Käyttäjät tekevät osallistumispäätöksiä viihtyisyyden perusteella. 14. Muutosehdotukset kappaleeseen 5.1 Verkkopalvelun tavoitteiden ja hyötyjen määrittely Vastaajien määrä: 5 - Tavoitteiden määrittelyn tukena olisi voinut käyttää verkkopalvelun integraatioasteen määrittämistä. Tarkoittaen sitä, että onko verkkopalvelu vain tiedon tarjoamisen kanava, vai tuotetaanko interaktiivista asiointia, vai onko kyseessä tiivis integraatio hyödyntävän ja palvelevan järjestelmän välillä osallistuminen ja vaikuttaminen samanlaisin perustein (PL) lause: poistetaan sana "muiden". Toinen lause (yhteiskunnallinen hyöty... jne) on tarpeeton, ehdotan poistettavaksi. - Voisiko "yhteiskunnallinen hyöty" olla oma väliotsikkonsa asiakas- ja organsaatiohyötyjen rinnalla? - Palvelun käyttäjätarinat olisi suotavaa järjestää kehityssuunnitelmissa epicien eli useista toiminnoista koostuvista tarujen kokonaisuuksiin. Tämä mahdollistaa liiketoimintaperusteisten hyötyjen perusteella ohjaamisen ja kehitysresurssien kohdistamisen kustannustehokkaasti. Käyttäjätarinoita tulisi mallintaa varhaisessa vaiheessa niin että selviää, mikä on pienin mahdollinen määrä teknisiä ylläpidettäviä toiminnallisuuksia, joilla saadaan toteutettua suurin mahdollinen hyöty. Ennen toteutusta käyttäjätarinat olisi suotavaa kuvata niin että niistä on tunnistettavissa roolin ja tavoiteltavan hyödyn lisäksi vaihtoehtoiset käyttötapaukset, joilla saattaa olla dramaattinen vaikutus kehitysresurssien kulumiseen. 15. Muutosehdotukset kappaleeseen Verkkopalvelun hyödyt asiakkaalle ja sidosryhmille Vastaajien määrä: 4 - Hyödyt on esitetty sangen kategorisesti ottamatta kantaa siihen, mikä on tavoitetaso.12 - 1. pallukka:... ajasta, paikasta ja laitteesta riippumatta Luettelo toistaa samoja lauseita koko ajan. Sen voisi lyhentää siten että jokaisen kohdan alusta otetaan pois "verkkopalvelun kautta..." ja muotoilee listauksen alun vähän fiksummin. - Asiointi on mahdollista ajasta ja paikasta... - Asiakkaalta vaadittu panos.. jne. tässä kohdassa tuleva sisennys on turha. Lauseet voi kirjoittaa yhteen. - Vaivaton asiointi ja asian valmistelun etenemisen seuraaminen. - Verkkopalvelusta voi saada tukea tai lisätietoa asiointiin - Mahdollista osallistua päätöksentekoon... - Palveluprosessit ovat... Seuraava kappalele, 1. lause, poistetaan "mitkä ovat". 2. lause, poistetaan "Esimerkiksi" ja lause: Palvelun tuoma hyöty on asiakkaan mahdollisuus asioida iltaisin ja viikonloppuisin. 16. Muutosehdotukset kappaleeseen Verkkopalvelun hyödyt organisaatiolle Vastaajien määrä: 4 - Tulee korostaa sitä, että sähköisten verkkopalveluiden hyödyt realisoituvat vasta siinä vaiheessa, jos palvelun tuottamiseen liittyvät taustaprosessit ovat sen mukaiset ja sähköiset organisaation hyödyt samalla tavalla bulletteina tai numeroituna listana kuin kpl > helpompi luettavuus, asioiden poimiminen ja yhteinäinen esitystapa. Linkki sade-ohjelman kustannus-hyötyanalyysiin ei tarjoa työkalua, eli linkki vanhentunut? - Tässä luvussa runsaasti esimerkkejä, jotka sinällään hyviä ja kannatettavia. Luettavuuden kannalta voisi olla hyödyllistä miettiä niiden (esimerkki + osoite) laittaminen alaviitteeksi kpl, lisätään: "...mahdollisuus osallistua asioiden valmisteluun..." 5. kpl, toinen lause. Esimerkiksi asiakastiedot voivat olla paremmin ajan tasalla..." päivitysmahdollisuus ei siis takaa sitä, että tiedot ovat ajantasalla, tällaista ei voi luvata. Se voi kyllä parantaa sitä, mutta jos asiakastietojen ylläpitoon ei muuten kiinnitetä huomiota ja luotetaan vain asiakkaiden aktiivisuuteen, voi tilanne olla jopa heikompi kuin ennen. 6 kpl, toinen lause: jätetään alusta pois sana "esimerkiksi". 17. Muutosehdotukset kappaleeseen 5.2 Verkkopalvelut osana kokonaisarkkitehtuuria ja palveluiden viitearkkitehtuureja Vastaajien määrä: 2 - Kappale on hyvin suppea eikä linkitä palveluita arkkitehtuurin vitrmallin mukaisesti. Tässä kohdassa konkreettisempi viittaaminen JHS179 suosituksen kohtiin olisi perusteltua. Lisäksi tässä tulisi konkretisoida SAVI-viitearkkitehtuurin suhdetta tähän suositukseen. - Tässä yhteydessä voisi konkreettisuuden vuoksi mainita esim. arkkitehtuurinmukaisuuden tarkastuspisteet, sillä ne ovat kuitenkin se konkreettisin toimi tällä saralla esim. verkkopalveluprojektissa. Tai asiaa voisi avata tarkemmin/konkreettisemmmin luvussa 5 kuvan 2 yhteydessä. Luvussa mainitaan sosiaali- ja terveyspalveluiden kohdealuearkkitehtuuri. Olisko tarpeelista laittaa alaviitteksi myös muut kohdealueet 18. Muutosehdotukset kappaleeseen Verkkopalvelu osana tiedonhallintaa Vastaajien määrä: 4 - Tiedonhalknta sähköisessä asioinnissa linkittää verkkopalvelun organisaation asiankäsittelyyn. Metatiedot jotka todentavat tapahtuneen. Arkistolaitoksen vaatimukset nimenomaan sähköisen asioinnin ja palveluiden tuottamiseen kohdentuvat asiointitapahtuman todentamisen dokumentointiin metatietojen avulla ja siihen, että päätöksestä voidaan tarvittaessa antaa sähköinen tiedoksianto. Osana kokonaisuutta on myös tiedonhallinta henkilötieto- ja julkisuuslain näkökulmasta siten, että palveluiden käytön yhteydessä käyttörajoitettu informaatio ei ole oikeudettomien käytössä. - Kohdassa Verkkopalvelu osana tiedonhallintaa on syytä korostaa asianhallintajärjestelmien merkitystä verkkopalvelun taustajärjestelmänä asiakirjojen julkaisussa. Organisaation asianhallintajärjestelmän olisi oltava asiakirjojen primääri julkaisupaikka. HARE:n merkitys hallinnon avoimuudelle ja asiakirjajulkisuudelle tulisi huomioida ja integraatio HARE:sta organisaatiokohtaisiin verkkopalveluihin olisi hyvä ottaa tavoitteeksi. - Kohdassa Verkkopalvelu osana tiedonhallintaa on syytä korostaa asianhallintajärjestelmien merkitystä13 verkkopalvelun taustajärjestelmänä asiakirjojen julkaisussa. Organisaation asianhallintajärjestelmän olisi oltava asiakirjojen primääri julkaisupaikka. HARE:n merkitys hallinnon avoimuudelle ja asiakirjajulkisuudelle tulisi huomioida ja integraatio HARE:sta organisaatiokohtaisiin verkkopalveluihin olisi hyvä ottaa tavoitteeksi. - Tulisiko luvun otsikoinnin olla "verkkopalvelu osana tiedonhallintaa ja tiedonohajusta". Sähköisten asiointipalvelujen kehittäminen ja kytkeminen osaksi organisaation taustajärjestelmää (prosessia) on keskeinen osa kun tavoitellaan tuottavuutta ja tehokkuutta. pelkkä verkkopalvelun kehittäminen ei riitä, mikäli toiminta siirtyy "paperimaailmaan" organisaation omassa toiminnassa. Luvussa olevat JHS-suositukset ja SÄHKE 2 -määritys antaa ohjeita ennenkaikkea organisaatioiden/toimijoiden omien asianhallintojen yms sähköistämiseen ei suoraan verkko- ja/tai asiointipalveluihin. 19. Muutosehdotukset kappaleeseen 5.3 Palvelun johtaminen ja hallinta Vastaajien määrä: 5 - Palvelun johtaminen olisi hyvä linkittää JHKA:n arkkitehtuurin johtamisen käsitteistöön ja hyödyntää arkkitehtuurin viitekehyksiä tässä yhteydessä. Palveluiden johtaminen sekä kehittäminen ovat vahvasti arkkitehtuuriohjattua toimintaa. Tässä asiakohdat on esitetty hyvin suppeasti ja viitteenomaisesti. Osaa näistä asiakohdista on käsitelty tässä suosituksessa muissa kohdissa tarkemmin ja viittaus suosituksen sisällä olisi ollut tarpeen. Lisäksi viittaukset muihin lähteisiin jotka käsittelevät kyseistä teemaa perusteellisemmin olisi hyödyllinen. - vastuu kieliversiosta? - On hyvä, että nimetään selkeästi vastuuhenkilöt/roolit verkkopalvelun kehitystyön ja hallinnan eri vaiheissa. Kokonaishallinnan kannalta on olennaista, että vastuut ovat selvät, ja päätösvallan keskittäminen yhdelle organisatoriselle taholle yleensä auttaa, joten palvelun omistajan roolia voisi ehkä vielä korostaa? - Tässä luvussa toivoismme että eri toimijoiden roolit arvioitaisiin osin uudelleen. Erityisesti ristiriitaista on verkkoplavelun omistajan, prosessin omistajan ja substanssin edustajan rooleja koskevat kohdat sivulla 12. Ymmärtääksemme sähköisessä asiointipalvelussa kyse on aina prosessin/palvelun kehittämisestä nimenomaan toiminta/substanssilähtöisesti. Näin ollen substanssi omistaa koko asiointiprosessin (asian/palvelun elinkaaren) ja verkkopalvelujen kehittämisen asiantuntijat (ml. ICT) tukevat asiantuntijuudellaan ao prosessin/palvelun sähköistämistä. Samoin luvussa voisi selkeämmin määritellä, mitä tarkoitetaan ylläpidolla. Ylläpidon tehtävinä on mainittu tehtävin teknisen toimivuuden seuranta ja käyttäjätyytyväisyyden seuranta, jotka kuulunevat eri tahoille tekninen toimivuus tekniikasta vastaavalle ja käyttäjätyytyväisyys sisällöstä vastaavalle. Tässä luvussa on mukana runsaasti projetinhalllintaan/hankehallintaan liittyvää aineistoa/ohjeistusta lause, jätetään pois sana "siten". Tässä kappaleessa kannattaisi miettiä luettelon soveltuvuutta vs. asioiden kirjoittamista auki lauseina. Tässä on kolmitasoista luetteloa ja asioina sellaisia, jotka toimisivat myös kokonaisena tekstinä. Luettelo ei juuri tuo lisäarvoa. 20. Muutosehdotukset kappaleeseen Palvelun kehittämismallin valinta Vastaajien määrä: 10 - Kappale on hyvin suppea ja antaa liian pintapuolisen kuvan kehittämismallista. - Palvelun kehittämismalleissa mainitaan vesiputousmalli ja ketterä kehitys. Näitä ei ensinnäkään avata juuri sen enempää. Lisäksi vesiputousmalli on jonkin verran vanhanaikainen, jossa kehitys tapahtuu ilman, että tilaajalla olisi juurikaan mahdollisuuksia puuttua mahdollisiin ratkaisuihin. Ketterä kehitys puolestaan vaatii asiantuntevan tilaajan sekä osaamista ja aikaa ketterän ohjelmistoprojektin omistajan tehtäviin. Ketterässä suunnittelussa täytyy tehdä päätöksiä myös nopealla tahdilla, joten tähän on oltava valmiudet koko tuotanto- ja käyttöönottovaiheiden ajan. Tämä kommentti koskee jälleen laajemmin dokumenttia, ja voi kannattaa jakaa se useampaan paikkaan lopullisessa dokumentissa. - Kohdassa Palvelun kehittämismallin valinta tulisi huomioida ekosysteemimalli. Ekosysteemimallia on käsitelty mm. Valtion yhteisen julkaisujärjestelmän esitutkimushankeessa (VM057:00/2011)14 - Kohdassa Palvelun kehittämismallin valinta tulisi huomioida ekosysteemimalli. Ekosysteemimallia on käsitelty mm. Valtion yhteisen julkaisujärjestelmän esitutkimushankeessa (VM057:00/2011) - - "Valinta esimerkiksi perinteisen vesiputousmallin kehittämisen ja ketterämmän menetelmän välillä tulee tehdä harkiten. Valinnan tulee perustua palvelun tulevaan käyttötarkoitukseen ja käyttäjiin sekä käyttötapoihin". Tuskin kehittämismallin valinnan kriteerit perustuvat erityisesti palvelun tulevaan käyttötarkoitukseen ja käyttäjiin sekä käyttötapoihin? Tämä uusiksi Lähtökohtaisesti suositeltava malli (riippuen palvelun/organisaation luonteesta) perustuu jatkuvaan ja nopeasykliseen kehittämiseen. Mieluummin Periaatteessa lähtökohtaisesti suositeltava malli perustuu jatkuvaan ja nopeasykliseen kehittämiseen. Kuitenkin hankinta- ja kilpailutuskontekstissa tämä sisältää merkittäviä haasteita: laatu- ja kustannusvastuu jäävät tilaajalle ja (2) tilaajan suunnitteluosaaminen pitää olla erittäin vahvaa. Tämä pitäisi mainita - Projektimallin valinnassa on hyvä huomioida myös käytettävissä olevat projektiresurssit. Eri mallit sitovat resursseja eri tavoin ja projektin eri vaiheissa. - Tulisiko tämän vahvemmin näkyä esim. sivun 2 kaaviossa. Kehittämismallin valinta ohjaa merkittävästi sitä, miten palvelu määritellään, suunnitellaan, toteutetaan ja ylläpidetään (ajatellen vaikka jotain ketterää kehittämistä POC - metodilla?) - 1. kappale, toinen lause. Poistetaan sana "erittäin." Tässäkään luettelo ei tuo lisäarvoa, vaan siinä on sellaisia asioita, jotka voisi hyvin kertoa kokonaisina lauseina ja kappaleina. - Kehittämismallin valinnan tärkeyttä korostetaan suosituksessa ja viitataan lukuun 6 Esiselvitys, malleja ei kuitenkaan ainakan kovin selvästi esitellä dokumentissa tai luvussa 6. - Budjetista vastaava johtoryhmä ja sisältöä suositteleva neuvoa-antava asiantuntijakokoonpanoinen ohjausryhmä erikseen. Kokoonpanot voi aikatauluttaa kokoontumaan vaikka samoilla osittain samoilla henkilöilläkin vuorotellen. Scrum-metodin opetuksiin kuuluu käytäntö luoda tasavertainen keskusteluilmapiiri pitämällä kommentoivien ja sitoutuneiden toimijoiden - scrum termein "possujen" ja "kanojen" - keskustelut erikseen. Pääkäyttäjäyhteisön ja kehittäjäyhteisön osallistuminen on syytä muodollistaa pitämällä näitä edustettuna ohjausryhmässä. Ohjausryhmä voi olla myös ITIL:in mukainen CAB eli Change Advisory Board. 21. Muutosehdotukset kappaleeseen 6. Esiselvitys verkkopalvelun kehittämisestä Vastaajien määrä: 5 - Kappaleen luettelomaisuus ja asioiden pinnallinen esille nostaminen jättää lukijalle epävarmuuden siitä, että miten eri kohdat tulisi toteuttaa. Sinänsä listassa olevat tehtävät ovat relevantteja, mutta niiden esittämistapaan sekä tarkempaan esittelyyn olisi hyvä vielä paneutua. - kieliversioiden toteutus tulisi olla mukana jo sopimusehdoissa - - Arvioi mahdollinen olemassa oleva verkkopalvelu. Pitäisi mainita, että tämä on keskeinen tehtävä silloin, jos korjataan nykyisen verkkopalvelun ongelmakohtia. Jos kehitetään uutta, niin nykyisen arviointi ei välttämättä ole hyödyllistä; vie kustannuksia ja voi suunnata ajattelumallia pois uusista innovatiivista ratkaisuista.. - Kohtaan Selvitä erilaiset toteutustavat (s. 15 ylhäällä) pitäisi lisätä uusi ranskalainen viiva: Vaatimusmäärittelyn tekijän ja suunnitteluratkaisujen (rakenteellinen ja käyttöliittymäsuunnittelu) tuottamisesta vastaavien pitäisi edustaa eri toimijoita, koska ei ole loogista, että suunnittelusta vastaava asettaa vaatimuksia itselleen. (jos asettaa vaatimuksia itselleen, voi tulla kiusaus asettaa helppoja vaatimuksia). - Silloinkin, kun palvelu annetaan ulkopuolisen tahon toteutettavaksi, organisaatiolla on vastuu tavoitteiden määrittelemisestä, palvelun ja prosessin suunnittelusta ja kehittämisestä ja linjauksista sekä käyttöönotosta. Toteuttava taho vastaa luonnollisesti toteutuksen laadusta, mutta organisaation tulee myös varmistaa, että laadulle asetetut vaatimukset täyttyvät. Loppu antaa väärän kuvan; parempi esimerkiksi toteutuksen laadusta. Tämä tarkoittaa, että jos organisaatio toteaa, laadulle asetetut vaatimukset eivät täyty, toteuttavan tahon tulee korjata laatuongelmat omin kustannuksin. - Esiselvityksen kohdat voisi olla luetteloitu siinä järjestyksessä, jossa esiselvitystä on järkevää laatia. Kustannusarvion laatiminen on nyt kolmantena, kuitenkin myöhemmin arvioitavat kohdat vaikuttavat siihen. Myös konseptisuunnitelmassa olevat kohdat, esim. Palvelun sisältö ja viestinnälliset ulottuvuudet vaikuttavat budjettiin. - Tässä jälleen koko kappale 6 on kolmiportainen luettelo, joka ei oikein toimi. Pienellä vaivannäöllä luettelon voi15 muokata loogiseksi tekstiksi. Jotain osia sisällöstä voisi kuvata esim. kuvina tai prosessikaavioina. Kommentteja tekstiasuun: Sivun 15 ensimmäinen pallukka, toinen lause, jätetään pois sana "lisäksi." Saman pallukan, ranskalaisen viivan alla olevan toisen alapallukan "Silloinkin" sanan voi jättää pois. Samasta palukasta viimeisestä lauseesta voi jättää pois sanat: "luonnollisesti" ja "myös." Lisäksi muuttaisin verbin varmistaa --> valvoa. Sivun 15 toinen musta pallukka, toinen lause, muutetaan. Huomioi integraatiotyössä julkisen hallinnon... jne. Sivu 15, 3. musta pallukka: Lauseen alusta poistetaan "Huomioi, että..." ja lause alkaa: Esiselvityksen tuloksena... jne. 22. Muutosehdotukset kappaleeseen 6.1 Konseptin määrittely Vastaajien määrä: 5 - Konseptisuunnittelun tarve ja tarkoitus on esitetty hyvin abstraktilla tasolla ja jää mahdollisesti monelle lukijalle avoimeksi. Aiheen syvempi taustoittaminen ja teemojen perustelu sekä avaaminen olisi ollut tarpeen. - huomioitava lainmukaisuus (mm. PL, hallintol ja kielil) - - Verkkopalvelun konseptilla tarkoitetaan tässä yhteydessä verkkopalvelun palveluideaa. Miksi tässä määritellään konsepti eri tavalla kuin termien määrittelyssä? Korjaa, että käytetään systemaattisesti samoja termien määrittelyjä - Konseptisuunnitelmassa määritellään verkkopalvelun pääpiirteet ja tavoitteet perustuen organisaation vaatimuksiin ja verkkopalvelun käyttäjien tarpeisiin. Sama kommentti. - Konseptisuunnitelma ohjaa palvelun kehittämistä sen koko suunnittelun, toteutuksen ja ylläpidon aikana, ja sillä pyritään varmistamaan yhtenäinen käyttäjäkokemus verkkopalvelun sisällä sekä suhteessa muihin palveluntarjoajan verkkopalveluihin ja palvelukanaviin. Tämä on nyt hämärää, kun konseptikäsite on hämärä. Tämä konseptikappale pitäisi kirjoittaa uusiksi, käyttäen aiemmin määriteltyjä käsitteitä ylätason konsepti, käyttöliittymäkonsepti, visuaalisen ilmeen konsepti. - Tähän voisi lisätä myös sähköisen asiointiin liittyvän asioinnintukipalvelun (esim. eri hallinnonalojen asiakaspavelukeskukset jotka antavat neuvontaa ja tukea mm.uusien sähköisten palvelujen käyttöönottotilanteissa) kappale: Konseptisuunnitelmassa määritellään verkkopalvelun pääpiirteet ja tavoitteet, jotka perustuvat organisaation vaatimuksiin ja... Konseptisuunnitelma ohjaa palvelun kehittämistä sen koko suunnittelun, toteutuksen ja ylläpidon aikana. Sen avulla pyritään... jne. Konseptisuunnittelua koskeva luetteloa voisi korjata siten, että vain tummennetut otsikot ovat luettelomaisesti ja alla olevat ranskalaiset viivat olisi kuvattu kokonaisina lauseina. Kysymysmerkkejä vilisevä luettelo on epämiellyttävä lukea. 23. Muutosehdotukset kappaleeseen Käyttöliittymäkonsepti Vastaajien määrä: 1 - Tämän mukaan keskeiset suunnitteluratkaisut (käyttöliittymäkonsepti: tietorakenteen ja navigation hahmotelma, palvelun osakokonaisuuksien alustavat päänäkymät ) luodaan esiselvitysvaiheessa. Tämä on yksi tämän luonnoksen ISO ongelma. Käyttöliittymän keskeiset ratkaisut tulisi luoda vasta suunnitteluvaiheessa vaatimusmäärittelyn jälkeen 24. Muutosehdotukset kappaleeseen Ulkoasukonsepti Vastaajien määrä: Pitäisi suositella, että ulkoasukonseptin suunnitteluun yleensä ei kannata tehdä alkuvaiheessa, jotta alussa voitaisiin keskittyä kriittisimpiin vaiheisiin. - Ulkoasun konseptisuunnitelmaa ei aina tehdä suunnittelun alkuvaiheessa, vaan ulkoasu suunnitellaan usein osana myöhempää suunnittelua konseptisuunnitteluvaiheen jälkeen. Asiaa voisi vielä korostaa: Ulkoasun suunnittelua ei yleensä tule tehdä alkuvaiheessa ) - Ulkoasun suunnittelua voi joskus olla vaikea käytännössä erottaa käyttöliittymäsuunnittelusta, koska molemmat vaikuttavat merkittävästi toisiinsa. Tämä sanottu vähän harhaanjohtavasti. Parempi esim.: Ulkoasun suunnittelu on yksi syöte käyttöliittymän yksityiskohtien suunnittelulle, mutta sinällään ulkoasun suunnittelu (usein tyyliopas ) ja käyttöliittymän rakenteen ja toiminnallisuuden suunnittelu ovat varsin itsenäisiä toimenpiteitä toistensa suhteen.16 25. Muutosehdotukset kappaleeseen 7. Verkkopalvelun vaatimusten ja toiminnallisuuksien määrittely Vastaajien määrä: 5 - Vaatimusten yhteydessä on hyvä tuoda esille myös se, että mikä on palvelun tuottamiseen liittyvän prosessin vaatimus ja miten taustaprosessit sekä muut järjestelmät liittyvät nyt tuotettavaan palveluun. - lainmukaisuus huomioon - Käytettävyysvaatimuksiin voisi lisätä sen, että asiointipalveluissa koko verkkopalveluun mallinnettu polku olisi hyvä olla asiakkaalle näkyvä, jotta tämä tietää, missä kohtaa prosessia hän on menossa. Polku voidaan esittää esimerkiksi joko valikkorakenteessa tai erillisenä murupolkuna. Erityisesti asiakkaan tietoturvaan ja yksityisyyden suojaan liittyvät näkökohdat olisi hyvä esittää omana kokonaisuutenaan sen lisäksi, että ne mainitaan kulloisessakin asiayhteydessä. Esimerkiksi suositus siitä, että palvelu pyytäisi erikseen vahvistusta ennen kuin käyttäjä tekee peruuttamattoman toimen (s. 18) kuuluu toiminnallisten vaatimusten määrittelyyn (kohta 7.1) mutta voitaisiin nostaa esille myös asiakasnäkökulmasta. Samoin arkaluonteisten tai yksityistietojen esittämisen välttäminen ilman käyttäjän tietoista valintaa (s.22) on osa käyttäjälähtöisyyden vaatimuksia, kohta 7.2, mutta olisi hyvä tuoda esille myös sen merkitystä asiakkaan suojaan nähden. Ehkä pääotsikon 11 alle voisi sijoittaa alaotsikon asiakkaan/käyttäjän tietoturva, jonka alle koottaisiin julkisen hallinnon sähköisen palvelun käyttäjän yksityisyyden suojaan ja siihen kuuluvan oikeusturvan edellyttämät seikat. Sekä periaatteiden ja reunaehtojen yleisesittelyssä kohdassa 5 että toiminnallisten vaatimusten käytännön määrittelyn käsittelyssä kohdassa 7.1 on ilahduttavalla tavalla kirjattu tärkeitä ja olennaisia seikkoja. Esimerkiksi yleisten periaatteiden ja reunaehtojen kohta 10 riittävän avoimesta mutta kuitenkin tietoturvan huomioivasta suunnittelusta (s. 9) on hyvä löytää tämänkaltaisesta suositustekstistä. Samoin toiminnallisten vaatimusten määrittelyä käsiteltäessä käytetään kiitettävää konkretiaa hyvien verkkopalvelujen toiminnallisuuksia listattaessa (s. 18). - Tämä kappale on ISO ongelmallinen kokonaisuus, koska siinä on sekoitettu kaksi täysin eri asiaa toisiinsa: vaatimusmäärittely ja suunnitteluratkaisujen tuottaminen. Kappaleessa on useita yksittäisiä ongelmia. alkaen ensimmäisestä lauseesta: Vaatimusmäärittelyvaiheessa määritellään verkkopalvelun vaatimukset ja toiminnallisuus. Pitäisi olla: Vaatimusmäärittelyvaiheessa määritellään verkkopalvelun toiminnalliset ja ei-toiminnalliset vaatimukset. ketterissä menetelmissä määrittely tarkentuu tällöin työn edetessä ja varsinainen määrittelydokumentti valmistuu usein vasta itse palvelun valmistuessa. Tässä kyseessä ei voi olla vaatimusmäärittely vaan jokin muu määrittely. - Sivustolla on myös kerrottava, mitä palvelu tekee. Esim. kansalaisaloite.fi tai otakantaa.fi. Toimintoa kuvaava otsikko ja pari-kolme lausetta on pituus, jonka joka käyttäjä ehtii lukea. Selaimen toimintoja ei ole perusteltua toistaa web-sivulla, jos palveluperiaatteena on Yksinkertaisuus, kuten olisi suotavaa. Tulostamisen sijaan PDF-, ja.doc-tiedostojen generointi sivuston datasta on suositeltavaa esitystavan optimoimiseksi erikseenvarsinaiseen käyttöön tulosteiksi, arkistoitavaksi. Web-työkalujen toiminnallisuusnäkymien tulostaminen tuskin lienee tarpeellista. Dokumenttitiedostojen generointi tukee myös oman organisaation dokumenttipohjapolitiikan noudattamisperiaatetta. Monikanavaisuus on mahdollistettava avoimen API-rajapinnan kautta jolla sivuston sisältö voidaan julkaista erikoisryhmille, esim näkövammaisille tai mobiilikäyttäjille, tapaukseen räätälöidyllä ja muihin datalähteisiin yhdistelevällä ratkaisulla. Avoin rajapinta mahdollistaa tiedon julkaisemisen saumattomasti erikoisryhmän erillisessä ja muiden tahojen hallinnoimassa palvelussa. API julkaisu API on olennainen osa minkä tahansa palvelun esteettömyys- ja monikanavaisuusstrategiaa. Palvelun tiedot kannattaa dokumenttiviennin lisäksi julkaista palvelun tietokantarakenteella Odata- tai REST/JSON muodossa sellaisenaan. Kirjoittamishetkellä ei valitettavasti ollut suositusta rajapintojen parhaista käytännöistä, ja nämä vaihtelevat teknologioiden ja julkaisujärjestelmien mukaan. Suomenkielisen avoimen datan rajapinnan rakennusohjeen koostaminen olisi kuitenkin suotavaa. Ikonien käyttö ja visuaalinen kieli on olennaista palvelun viihtyvyyden ja yksinkertaisuuden mahdollistamiseksi. Ikonit ovat yksinkertainen tapa ratkaista kosketusnäyttöihin liittyvää kompleksisuutta ruutujen koon vaihdellessa. Ikonien käyttöä rajoittaa että käyttäjä tarvitsee tietyn määrä toistoja ikonin merkityksen oppimiseen. 26. Muutosehdotukset kappaleeseen 7.1 Toiminnallisten vaatimusten määrittely Vastaajien määrä: 617 - Verkkopalvelun pitää kyetä ehkäisemään ja sietämään virheitä sekä auttaa korjaamaan niitä. Verkkopalvelun tulee ilmoittaa käyttäjälle virheistä selkeästi Ehdotus: Verkkopalvelun pitää kyetä ehkäisemään virheitä. Palvelun tulee toimia moitteetta eri toimintaympäristöissä Ehdotus: Palvelun tulee toimia eri toimintaympäristöissä kappaleeseen lisäys: ja lain vaatimukset. 3. kpl:een luettelo, toiseksi viimmeinen pallukka: Palvelua tulee voida käyttää ainakin suomeksi ja ruotsiksi sekä tarvittaessa muilla kielillä. Lisätietoja-kohta: - Ensimmäiseksi Valtionhallinnon viestintäsuositus 2/ VN:n kertomuksen tilalle Kansalliskielistrategia - Jos kielikertomus halutaan säilyttää listan viimeisenä, sen voisi otsikoida "Tutustu myös". - Seuraavassa listassa on kuvattu muutamia hyville verkkopalveluille ominaisia toiminnallisuuksia ja niihin liittyviä suosituksia Nämä eivät ole toiminnallisia vaatimuksia (niin kuin kappaleen otsikko antaa olettaa), vaan yleisiä suunnittelohjeita. Tämä kohta pitäisi korjata - Kappaleessa 7.1. Toiminnallisten vaatimusten määrittely tulisi huomioida, että ne eivät liity pelkästään asiointiin, jota kappaleessa nyt korostetaan, vaan myös muuhun sisältöön liittyviin sekä asiakkaista ja organisaatiosta lähteviin tarpeisiin (esim. sisältöjen automaattinostot, tiedotepalvelu, ym.). - Luettelon alussa voi jättää pois sanan "palvelussa" : Asioinnin on edettävä asiakkaan näkökulmasta... jne. - Toiminnalliset vaatimukset kannattaa sitoa kehitysnormeihin ja jo varhaisessa vaiheessa suunnitella yhteensopivuustestattavaksi. Tähän on tehokkaita työkaluja kuten 27. Muutosehdotukset kappaleeseen 7.2 Verkkopalvelun käyttäjälähtöisyyden vaatimukset Vastaajien määrä: 2 - Palvelua on kehitettävä perustuen todellisten käyttäjien kanssa toteutettuihin tutkimuksiin. Erilaisia tutkimusmetodeja ovat esimerkiksi käytettävyystestit, käyttäjähaastattelut, fokusryhmät, yhteisläpikäynnit sekä käyttökyselyt ja palautteet. Tämä on periaatteessa hyvä, mutta pitäisi lisätä seuraava. On kuitenkin varottava, että vaatimuksia ja suunnitteluratkaisuja tuotetaan suoraan näiden tutkimusten perusteella. Kehittämisen tulee lopulta aina perustua suunnittelusta vastaavien tulkintoihin ja näkemykseen tutkimustuloksista, samalla niin että suunnittelijataho kantaa riskin suunnitteluratkaisujen laadusta (ei koskaan käyttäjät). - lause: Käyttäjän on nähtävä verkkopalvelun etusivulta, onko palvelussa hänelle tärkeää tietoa tai toimintoja. ==> Varmaan periaatteessa kyllä, mutta käytännössä haastavaa - varsinkin jos on kyseessä hyvin laaja palvelusivusto tms. Käyttäjä voi kyllä tehdä oletuksen etusivun perusteella siitä, että mahdollisesti löytäisi jotain mitä on etsimässä. Korostaisin mielummin tätä sekä sitä, että palvelussa satsataan riittävän hyvään ja käyttäjää ohjaavaan hakutoiminnallisuuteen tms. jolla käyttäjä saa nopeasti selville löytyykö hänelle tärkeä tietoa tai toimintoja. Laajan palvelun all-in-one etusivulta ei kyllä IMHO löydy sitten enää mitään jos se venyy ja paukkuu. luvussa 7.2 on kohta Käyttäjän tulee voida löytää organisaation verkkopalvelusta helposti keskeiset tiedot, kuten yhteystiedot, aukioloajat, vastuualueet, keskeiset tehtävät, ajankohtaiset asiat yms. Käyttäjän tulee voida löytää organisaation verkkopalvelusta helposti keskeiset... tähän voisi yksilöitynä tarkennuksena todeta, että verkkopalveluissa ja erityisesti apps storeista ladattaessa mobiilisovellusta, käyttäjän on saatava helposti (sovelluskaupasta) käyttöönsä rekisteriseloste/kuvaukset ennen mobiilisovelluksen lataamista sovelluksen avulla kerättävistä tai sovelluksen käyttämistä tiedoista. ==>Rekisteriselosteiden merkitystä ei saisi häivyttää JHS-suosituksessa liian vähälle huomiolle mobiilipalvelujen osalta, joka on uusi verkkopalvelujen aalto.18 28. Muutosehdotukset kappaleeseen Verkkopalvelun käytettävyys ja käyttökokemus Vastaajien määrä: 6 - Käytettävyystestaus on huomioitava jo hankintavaiheessa. Tarjouksissa on pyydettävä huomioimaan, että lopputuote tullaan testaamaan käytettävyyden osalta, ja siinä tehdyt (kriittiset ja vakavat) havainnot tulee korjata osana takuuta ja hyväksymismenettelyä. Voi hyvinkin kannattaa käyttää ulkopuolista käytettävyystestaajaa. Silloin ei tule eturistiriitoja testitulosten raportoinnissa ja vakavuuden analysoinnissa. Lisäksi testaajan on joka tapauksessa oltava jokin projektin ulkopuolinen toimija (henkilö tai organisaatio), jotta järjestelmä ei olisi liian tuttu testauksessa. - Sivulla 22: Palvelun ja sen sivujen on latauduttava nopeasti. -Vasteajan tulee olla pääsääntöisesti enintään 0,1 sekuntia. Jos lataus kestää, sivujen latautumisen edistymistä on syytä kuvata esimerkiksi palkilla. Ehdotetaan, että otsikko muotoillaan uudelleen: Palvelun on annettava asiakkaalle palaute tämän toiminnasta nopeasti - kuten selittävässä kappaleessa mainitaan, toiminnon ei tarvitse valmistua nopeasti, mutta asiakkaan on saatava jokin vaste järjestelmältä nopeasti. Esimerkiksi vierityspalkki tai jokin muu symboli voi kertoa asiakkaalle, että järjestelmässä on tapahtumassa jotain. - Käyttökokemus-termiin viittaus temin määrittelevään iso-standardiin kuten käytettävyyden termistäkin --> yhtenäisyys! Käytettävyys- ja käöyttäjäkokemus varmistetaan... -listaukseen tarkistuspisteeksi mitattavien käytettävyysmittarien muodostaminen toiminnallisista vaatimuksista, joita vasten käytettävysytestaus suoritetaan ja arvioidaan. - Käytettävyydellä tarkoitetaan sitä, kuinka helppoa, miellyttävää ja tehokasta palvelun käyttö on todellisessa käyttökontekstissa. Se vaikuttaa siihen, kuinka hyvin käyttäjä saavuttaa todellisen tavoitteensa palvelussa. Miksi tässä tällainen vähän epämääräinen määritelmä; käytä oikeaa käytettävyyden määritelmää! (ks aiemmat kommentit) Käyttökokemuksella tarkoitetaan sitä, millainen kokonaiskokemus ja tunne käyttäjälle muodostuu. Tähän vahvempi määritelmä (termeihin). Käyttökokemus pitää määritellä niin, että se ei ole laajasti mitä tahansa vaan nimenomaan liittyy palvelun käyttöön (kyseessä kun on KÄYTTÖkokemus ) - "- Käytettävyys ja käyttökokemus varmistetaan mm. seuraavilla tavoilla kehittämisprosessin (kts. kuva 2 Palvelun kehittämisen tarkistuspisteet) aikana". Tämä ei ole vaatimusmäärittelyä, ei tulisi olla tässä kohdin suositusta - "Ota mukaan suunnitteluun palvelun loppukäyttäjiä eri suunnitteluvaiheissa. Käy läpi jo karkeita suunnitelmia heidän kanssaan". Tämä on eettisesti väärä ohje, jossa käyttäjä laitetaan tekemään asioita, johon hänellä ei ole aitoja edellytyksiä eli käyttöliittymän arviointiin/ suunnitteluun. Sen sijaan ohje "testaa niitä mahdollisuuksien mukaan" on ok. Tässä kappaleessa pitäisi ohjeistaa siihen, että suunnittelua tekevien pitäisi myös vastata suunnitteluratkaisujen laadusta. Pitäisi ohjeistaa siten, että suunnittelutaho vastaa käytettävyystestien organisoinnista ja kustannuksista. (perinteinen, tilaajalle laatuongelmia ja kustannuksia aiheuttava tapa on ollut, että tilaaja organisoi ja kustantaa testit, ja tämä ohjeen versio tulkintani mukaan edelleen ohjaa siihen suuntaan). Vielä toisella tavalla sanottuna: mahdollinen ulkopuolinen käytettävyysasiantuntija pitäisi olla suunnittelutahon itselleen hankkima ja maksama, ei asiakkaan niin kuin tänä päivänä on käytäntö. Vain tämä ohjaa laadukkaaseen suunnitteluun heti alusta lähtien. (tilaaja voi sitten lopussa hankkia ulkopuolisen käytettävyysasiantuntijan testaamaan,saavutettiinko asetetut (mitattavat) käytettävyysvaatimukset. (Näitä kommentteja, vaikka tämä kappale pitäisi olla otsikkonsa mukaisesti vaatimusmäärittelyä eikä suunnittelua tai testausta - 1, kappale, 1. lause: lisäisin sanan "hyvä" ennen "käyttökokemus" -sanaa. Tässä kappaleessa on jälleen kaksi luetteloa, jossa on paljon tekstiä. Ehdotan luetteloiden korvaamista kunnollisella tekstiosuudella. Toisen luettelon kolmas pallo: "Arvioinnit ja testaukset tulee huomioida jo budjetoinnissa ja aikataulutuksessa." Tästä olisi voinut kirjoittaa lisää, kuinka nämä asiat huomioidaan käytännössä ja onko jotakin välinettä, jonka avulla tätä voi arvioida? 29. Muutosehdotukset kappaleeseen Verkkopalvelun saavutettavuus ja esteettömyys19 Vastaajien määrä: 11 - Sitoutuminen WCAG:n versio 2.0 hyvä. Hyvä, että esteettömyysvaatimukset tulevat monessa kohdassa esiin. s. 20 Esteettömyydessä tulee pyrkiä vähintään WCAG 2.0 -ohjeen A-tason toteutumiseen. Voisi lisätä, että kehittyvän lainsäädännön kautta vaatimustaso voi nousta AA-tasoksi, mihin on hyvä varautua. - "Palvelun ja sen sivujen on latauduttava nopeasti" - Nykyään suositaan aika paljon jotain pyörivää elementtiä. Etenemispalkki toimii, jos jäljellä oleva aika voidaan laskea. Näin ei yleensä ole. "Verkkopalvelun käytön aloittamisen on oltava mahdollisimman helppoa" - Flashin ja sovelmien käytön voisi kieltää kokonaan. HTML5-tekniikoilla saadaan tehtyä kaikki tarpeellinen. - WCAG ja HTML, XML sekä CSS -standardit tukevat toisiaan. Kaikkien standardien noudattaminen helpottaa esteettömyystavoitteiden toteutumisessa. Verkkopalvelun käytön aloittamisen on oltava helppoa -osuus. Toisessa bulletissa lienee syytä mainita nimellä JavaScript. Termi "komentosarja" voi olla vähän vieras monelle. 2. pallukka: Henkilöit, joiden äidinkieli on muu kuin suomi tai ruotsi 4. pallukka: Kaksikielisen viranomaisen verkkopalvelussa tulee tarjota oleellinen tieto kielilainsäädännön mukaan suomeksi ja ruotsiksi sekä saamelaisten kotialueella saameksi. 10. pallukka: Kansalaisen turvallisuuteen ja terveyteen liittyvien palveluiden tulee olla käytettävissä molemmilla kansalliskielillä. (vaaratiedotteet, 466/2012) 14. pallukka: - "Esimerkiksi vieraskielisen lyhenteen käyttö verkkotunnuksena ei yleensä ole käyttäjälle selkeä tai nopeasti pääteltävä. -..., jos palvelulla selkeä domain-osoite - Kuuloliiton kanta on, että verkkosisällön saavutettavuusohjeiden (WCAG 2.0) mukaisen tason tulisi julkisen palvelun sivustoilla olla AA. Perusteluina on se, että pelkkä A-tason vaatimus on tallennetun audiosisällön tekstitys. Sen sijaan AA-tasossa suoralla audiosisällölle on tarjottava reaaliaikainen tekstitys. Tämä mahdollistaa eri tavoin kuulovammaisille suorien nettilähetysten seuraamisen. - Verkkopalvelun kielivaatimukset: "... tulee olla saavtavilla myös muilla kielillä" --> miten kielet valitaan. Muutosehdotus: verkkopalvelun tulee olla saatavilla organisaation virallisesti päättämillä palvelukielillä, joita voivat olla suomen kielen lisäksi esimerkiksi ruotsi, englanti, saame ja suomalainen viittomakieli. Lause "lähtökohaisesti palveluissa on käytettävä selkeää kieltä" ei tarkoita lukijalle mitään. Kuka määrittelee, mikä on selkeä kieli ja mieten selkeyden arviointi tehdään? Muuttaisin lauseen seuraavasti: "Palveluissa on käytettävä helposti ymmärrettävää kieltä ja termistöä". Jakaisin tämän kappaleen lisäksi kahtia seuraavasti: kpl verkkopalvelun esteettömyys (vs käytettävyys) ja lisäksi uusi kappale verkkopalvelun saavutettavuus, johon kirjataan käyttäjälähtöisen suunnittelun ja toteutetun palvelun vaatimukset. Nyt kappale on sekava ja hankalalukuinen, koska sisältää kahdenlaista asiaa: kielisyyteen ja käyttöliittymän esteettömyyteen liittyviä vaatimuksia, ja perään käyttäjäryhmiin, rooleihin, tekniseen saavutettavuuteen jne. liittyviä vaatimuksia. Nykyinen otsikko myös kuvaa sisällön eri järjestyksessä kuin se on (nyt esteettömyys ensin, vaikka otsikossa saavutettavuus ensin). - (tähän ehdin kommentoida; katson jos ehdin jatkaa loppuu myöhemmin ;taitaa olla sitten erillinen lomake - Esteettömyydessä tuleepyrkiä vähintään WCAG 2.0 -ohjeen AA-tason toteutumiseen. On huomattava, että A-tason toteuttaminen ei mahdollista sivujen esteettömyyttä kaikille käyttäjäryhmille, esim näkövammaisille. - Sivu 21, luettelon 2. ja 3. pallo: Tässä voisi vain mainita selkokielen ja määritellä sisältö termiluettelossa. Luettelon käyttöä tulisi jälleen harkita. Lisäksi tässä kohtaa luetteloon ilmestyy tummennettuja "otsikoita", jotka poikkeavat aiemmista. Voisiko näistä tehdä väliotsikoita ja kertoa luetteloiden sijaan asiat kokonaisuuksina näiden alla? Tummennettu pallukka "Palvelu tulee suunnitella riittävän avoimeksi ja läpinäkyväksi" --> eikö tätä asiaa ole käsitelty jo aiemmin? Toinen tummennettu pallukka, 1. lause: palvelun pääkohderyhmät sekä toissijaiset kohderyhmät tulee määritellä. Palvelun käyttäjät kannattaa ryhmitellä käyttäjäroolien, osaamisen, ja palvelutarpeiden perusteella. (loppupätkä poistetaan). Kolmas tummennettu pallukka: Otskko on huono, voisi lyhentää muotoon: "Palvelun on oltava käytettävissä kattavasti".20 Sivu 22. Toinen otsikko, 1. pallukka... poistetaan lopusta ylimääräiset pisteet. 2. pallukka, mitä tarkoittaa: "käyttäjän tietoista valintaa"? En ymmärrä tätä väittämää ollenkaan. Kolmas tummennettu pallukka/otsikko: 1. ranskalainen viiva: epäselvä, lähes käsittämätön lause. 2. ranskalainen viiva, muutetaan: Käyttäjän kokema palvelun nopeus liittyy myös palvelun luonteeseen. Käyttäjä voi olla valmis odottamaan kiinnostavaa videota tai laajoja hakutuloksia. Sivun 22. viimeinen tummennettu otsikko, poistetaan sana "mahdollisimman". Viimeisen tummennetun otsikon alla on huonoja laueita, luettelo on huono. Myös- sanoja ja muita täytesanoja pitää poistaa, kolmannessa pallukassa on sekavasti liikaa asiaa. Otsikot pitää miettiä nasevimmiksi. - Listauksessa on mainittu kohderyhminä "henkilöt, joiden näkö tai kuulo on heikentynyt". Tarkkuuden vuoksi kannattaisi mainita myös henkilöt, joilla ei ole lainkaan kykyä nähdä tai kuulla. - Kappaleesssa useita kohtia, jotka liittyvät enemmän käytettävyyteen kuin saavutettavuuteen ja esteettömyyteen. Ne voisi siirtää kappaleeseen ("Seuraavissa kappaleissa on kuvattu vaatimuksia käyttäjälähtöisesti suunnitellulle ja toteutetulle palvelulle...") - Verkkopalvelun suunnittelussa on syytä huomioida myös kognitiivinen esteettömyys, eli muita työkaluja samaan käyttävät, autoa ajavat, väsyneet, lapsia hoitavat jne. Esteettömyys on syytä varmistaa avoimella rajapinnalla. Katso kohta Muutosehdotukset kappaleeseen 7.3 Verkkopalvelun tietomalli Vastaajien määrä: 2 - Tässä tulisi viitata myös tietoarkkitehtuureihin sekä tiedon yhteentoimivuuteen. Lisäksi tässä on hyvä nostaa esille arkistolaitoksen sähke-vaatimukset liittyen vaadittuihin metatietoihin. - Tämä on suunnittelua eikä vaatimusmäärittelyä! Ei kuulu olla tässä kappaleessa. 31. Muutosehdotukset kappaleeseen 7.4 Sisällön suunnittelu ja sisällöntuotannon organisointi Vastaajien määrä: 7 - "Huolehdi siitä, että sisällön tuottamisesta vastaavilla henkilöillä on riittävä verkkokirjoittamisen osaaminen ja tarvittava kielitaito. 7.4 (ja muutama muu kohta) Rooleissa on hyvä mainita ja tehdä ero toimituksellisen ylläpidon (päätoimittajat, toimittajat) ja teknisen ylläpidon välillä. Tekninen pääkäyttäjä hallinnoi teknisiä ominaisuuksia ja käyttää niitä toiminnallisuuksia, joiden käyttäminen voi vaikuttaa useisiin sivustokokonaisuuksiin tai muihin ympäristömuuttujiin. On myöskin linjattava teknisen pääkäyttäjän rooli: onko heillä tarvittaessa pääsy muokkaamaan järjestelmän sisältöä esimerkiksi sijaistustilanteissa tai muutoin vai rajoittuuko rooli vain teknisten ominaisuuksien hallinnointiin ja ylläpitoon. Tekninen ylläpito on myöskin huomioitava järjestelmän hankinnan selvityksessä ja resurssoinnissa. Dokumentissa ei juuri ole mainintaa migraatiosta vanhoista järjestelmistä - Harvoin tehdään täysin uutta verkkopalvelua, vaan joko uudistetaan vanhentunutta palvelua tai kootaan useampia yhteen. Tällöin on huolehdittava siitä, että tieto siirtyy uuteen järjestelmään ja parhaassa tapauksessa myös löytyy vanhoista osoitteista vähintään ohjauksen avulla. Jos palvelussa on jatkuvaa sisältöä, joka on voimassa (julkaistu) tietyn ajan, tulee sen yliheitto suunnitella. Siirrytäänkö kertaheitolla käyttämään uutta järjestelmää, jolloin täytyy huolehtia, että vanhasta järjestelmästä siirretään tiedot uuteen järjestelmään. Toinen vaihtoehto on määrätä päivä, jonka jälkeinen sisältö kirjataan vain uuteen järjestelmään. Vanhaa käytetään niin kauan kunnes viimeinenkin ilmoitus on vanhentunut. Molemmilla on omat puolensa - joko vaatii kahden järjestelmän rinnakkaista käyttöä tai osittain päällekkäistä työtä. Lisäksi kaipasin dokumentissa vähän laajempaa mainintaa avoimesta datasta. - Mikäli mahdollista, tulisi palvelun tuottajan tarjota järjestelmän dataa avoimesti koneluettavassa muodossa. Esimerkiksi palvelun tilastotiedot voivat kiinnostaa muita käyttäjiä. Esimerkiksi kansalaisaloitepalvelun tilastotietoja pystyy saamaan rajapinnan kautta. Datan tulisi oltava saatavissa jollain standardoidulla tavalla (esim. liitteessä mainitulla XML-muodossa). Datan käytölle ei pidä asettaa turhaan rajoituksia, vaan antaa se vapaaseen yksityiseen ja kaupalliseen käyttöön. - Kohdassa 7.4 Sisällön suunnittelu ja sisällöntuotannon organisointi tulisi ottaa huomioon se, että verkkoviestintä ei ole viestinnästä tai organisaation muusta toiminnasta erillinen kokonaisuus. Pyrkimyksen tulisi olla se, että asian hodosta vastaava vastaa myös sen esiintymisestä verkossa. Esimerkiksi asiaa valmisteleva virkamies vastaa asian tietojen ja asiakirjojen talentamisesta tarvittaviin tietojärjestelmiin ja julkaisee ne taustajärjestelmistä verkkopalveluun. Kappaleessa tulisi laajemmin huomioida verkkopalveluiden linkittyminen organisaation prosesseihin. Näytä lisää
Palautekooste: JHS 153 / JHS XXX EUREF-FIN -järjestelmän mukaiset koordinaatit Suomessa 1. Organisaatio - Yksityishenkilö - Yksityishenkilö - Puolustusvoimat - Joensuun kaupunki - Sosiaali- ja terveysministeriö Lisätiedot JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen
JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys Lisätiedot Projektin tilannekatsaus
Kuntasektorin yhteinen KA Asianhallinnan viitearkkitehtuuri Projektin tilannekatsaus Heini Holopainen Kuntien Tiera Oy heini.holopainen@tiera.fi Sisältö» Taustaa Mitä tarkoitetaan viitearkkitehtuurilla Lisätiedot SUOMEN KUNTALIITTO RY
Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet... Lisätiedot Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7
Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe Lisätiedot JHS 190 Julkisten verkkopalvelujen suunnittelu ja kehittäminen
JHS 190 Julkisten verkkopalvelujen suunnittelu ja kehittäminen Versio: 1.0 Julkaistu: 13.6.2014 Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen rakenne... 2 2 Soveltamisala... 3 Lisätiedot Julkisen hallinnon kokonaisarkkitehtuuri JHKA
Digitaalinen hallinto - mitä puuttuu vai puuttuuko mitään? Informaatio- ja tietoteknologiaoikeuden professori Tomi Voutilainen 1 Sähköinen hallinto Sähköiset palvelut ja tietojärjestelmät Palveluiden käyttäjät Lisätiedot Julkisen hallinnon kokonaisarkkitehtuurijaoston työsuunnitelma 2014
Suunnitelma Valtiovarainministeriö/Julkisen hallinnon ICT - toiminto/vaatimukset ja suositukset JHKA-sihteeristö 22.1.2014 Julkisen hallinnon kokonaisarkkitehtuurijaoston työsuunnitelma 2014 Julkisen hallinnon Lisätiedot Käytettävyys tuotekehityksessä mitä pitäisi osata?
Käytettävyys tuotekehityksessä mitä pitäisi osata? ( mitä tehdä konkreettisesti ja kuinka paljon?) Timo Jokela, FT, dos. Joticon Oy (Oulun yliopisto, Helsingin yliopisto) Käytettävyyseminaari Oulu 15.4.2011 Lisätiedot Opiskelun ja opetuksen tuen viitearkkitehtuuri
Opiskelun ja opetuksen tuen viitearkkitehtuuri Mitä osia opintohallinnon viitearkkitehtuurissa tulee olla Työstänyt Synergiaryhmä 4.12.2014 Toimittanut Pekka Linna, CSC Tuleva toteutus Tuotetaan sivusto, Lisätiedot Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015
Fiksumpi käyttöliittymä kuntaan Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Otso Kivekäs 20.8.2015 Otso Kivekäs+ Codento Kehittämispäällikkö, kunta-alan projektit Lisätiedot Avoin lähdekoodi. Jani Kylmäaho Maanmittauslaitos www.oskari.org
Avoin lähdekoodi Jani Kylmäaho Maanmittauslaitos www.oskari.org Avoimen lähdekoodin määritelmä (OSI) Ohjelman täytyy olla vapaasti levitettävissä ja välitettävissä. Lähdekoodin täytyy tulla ohjelman mukana Lisätiedot EKSOTE Sähköisen asioinnin seminaari 14.10.2014
EKSOTE Sähköisen asioinnin seminaari 14.10.2014 Sähköisen asioinnin mahdollisuudet tulevaisuudessa Sami Säisä Mitä on sähköinen asiointi? Sähköinen Internetissä toimivaa palvelua? Itsepalveluna toteutettavaa Lisätiedot Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011
Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa Lisätiedot Verkkokirjoittaminen. Verkkolukeminen
0 Nopeaa silmäilyä: Pääotsikot, kuvat, kuvatekstit, väliotsikot, linkit, luettelot, korostukset. 0 Hitaampaa kuin paperilla olevan tekstin lukeminen 0 F-tyyppinen lukeminen Verkkolukeminen Verkkokirjoittaminen Lisätiedot Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen
11.10.2013 Tekijän nimi Arkkitehtuuri kehittämisen välineenä Kokonaisarkkitehtuuri hallitun muutoksen avaimena Etelä-Savon maakuntaliitto 10.10.2013 Markku Nenonen Tutkijayliopettaja Mikkelin ammattikorkeakoulu Lisätiedot Tietohallinto Projektipäällikkö Matti Sairanen. Fujitsu Myyntijohtaja Markku Örn
Tietohallinto Projektipäällikkö Matti Sairanen Fujitsu Myyntijohtaja Markku Örn Sähköinen asiakirjahallinta Sähköinen työpöytä Dokumenttienhallinta (kuvatut käsittelyprosessit) Asiahallinta Sähköinen arkisto Lisätiedot Käytettävyyslaatumallin rakentaminen verkkosivustolle
Käytettävyyslaatumallin rakentaminen verkkosivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -tutkielma Timo Laapotti 9.6.2005 Esityksen sisältö Kirjoittajan Lisätiedot ICT muutos kunta- ja palvelurakennemuutoksessa. Selvitysvaiheen tehtävät
ICT muutos kunta- ja palvelurakennemuutoksessa Selvitysvaiheen tehtävät Kunta- ja palvelurakennemuutos Selvitysvaiheen tehtävät 1.0. Selvitysvaiheen projektointi Suunnittelu 1.1. Nykytilan kuvaaminen 1.2. Lisätiedot KYSELYTUTKIMUS: Yritysten verkkopalvelut sekä hankaluudet niiden hankinnassa ja määrittelyssä
KYSELYTUTKIMUS: Yritysten verkkopalvelut sekä hankaluudet niiden hankinnassa ja määrittelyssä TUTKIMUKSEN TOTEUTUS Aihe: Yritysten verkkopalvelut ja hankaluudet niiden hankinnassa ja määrittelyssä Ajankohta: Lisätiedot Kansallinen digitaalinen kirjasto ja arkistopalvelut
Kansallinen digitaalinen kirjasto ja arkistopalvelut Tiedon saatavuus ja tutkimuksen vapaus KAM-juridisen yhteistyöryhmän seminaari Arkistoneuvos Jaana Kilkki, Kansallisarkisto 12.12.2011 Esityksen sisältö Lisätiedot Sosiaali- ja terveydenhuollon ITratkaisujen
26.1.2014 Joulukuussa 2013 toteutetun kyselyn tulokset Sosiaali- ja terveydenhuollon ITratkaisujen hyödyntämistä ja tietohallintoa koskeva kysely Tomi Dahlberg Karri Vainio Sisältö 1. Kysely, sen toteutus, Lisätiedot Espoon arkkitehtuurin kehittäminen - Tiedonhallinta ja arkkitehtuuri kaupungin näkökulmasta
Espoon arkkitehtuurin kehittäminen - Tiedonhallinta ja arkkitehtuuri kaupungin näkökulmasta Arkistosektorin KDK- yhteistyöverkosto 10.11.2014 Marko Kukkonen, Konserniesikunta - Tietohallinto Kokonaisarkkitehtuuri Lisätiedot Yhteentoimivuutta kokonaisarkkitehtuurilla
Yhteentoimivuutta kokonaisarkkitehtuurilla Terveydenhuollon atk-päivät 20.5.2014 Juha Rannanheimo Ratkaisupäällikkö, sosiaali- ja terveydenhuollon ratkaisut Esityksen sisältö Kehittämisvaatimukset sosiaali- Lisätiedot www.hankintatoimi.fi 21.06.2010 Juha-Pekka Anttila VTT
www.hankintatoimi.fi 21.06.2010 Juha-Pekka Anttila VTT Hankintatoimen kehittäminen teknologiateollisuudessa - VTT mukana kehitystyössä VTT:n Liiketoiminta ja teknologian johtaminen -osaamiskeskuksen toteuttamissa Lisätiedot Verkkokirjoittaminen. Anna Perttilä Tarja Chydenius
Verkkokirjoittaminen Anna Perttilä Tarja Chydenius 1 Suosi lyhyttä tekstiä 2 Kenelle kirjoitat 3 Helpota lukijan työtä; lajittele tekstisi 3.1 Otsikot 3.2 Johdanto 3.3 Väliotsikot 3.4 Pääteksti 4 Linkit: Lisätiedot TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!
TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka Lisätiedot Sähköinen asiointi ja ICT:n hyödyntäminen
Sähköinen asiointi ja ICT:n hyödyntäminen - Kohti uutta ICT-strategiaa Oppijan verkkopalvelut -seminaari 13.12.2011 Yksikön päällikkö Ville-Veikko Ahonen Sähköinen asiointi (eservices): Sähköisellä asioinnilla Lisätiedot Yliopistojen erilliset palautteet. Webropol kyselyn tulokset. RAPORTTI 2 Uudet värit portaaliin Testipäivä: 26.9.2011 sekä kysely Webropolissa
Palvelukonsortion johtoryhmän kokous 3-2011- 3.10.2011 RAPORTTI 2 Uudet värit portaaliin Testipäivä: 26.9.2011 sekä kysely Webropolissa Yliopistojen erilliset palautteet Helsingin yliopisto LIITE R1 Turun Lisätiedot KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti
1 KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI Kehitysvammaliitto / Hyvät käytännöt -projekti 2 Tuotetaan käytännöstä tietoa yhdessä Käytännön kuvaamisen tarkoituksena on Lisätiedot Asiakasystävällinen ja ylläpidettävä verkkopalvelu tarua vai totta
Asiakasystävällinen ja ylläpidettävä verkkopalvelu tarua vai totta 00.0.2008 Esitelmän pitäjän nimi (tarusta todeksi?) Leila Oravisto Mirjam Heikkinen Helsingin kaupunki Haasteet Kunnilla on palveluja Lisätiedot PDF-tiedostojen optimointi hakukoneille
PDF-tiedostojen optimointi hakukoneille PDF-tiedostojen optimointi herättää ristiriitaisia tunteita. Jotkut väittävät, että PDF:illä ei ole mitään arvoa hakukoneoptimointimielessä, toiset taas puhuvat Lisätiedot ividays BLOG Design Elina / Tomi / Timo / Otso / 23.9.2013
ividays BLOG Design Elina / Tomi / Timo / Otso / 23.9.2013 1. Suunnitelma Konsepti 1. Yksinkertainen ja rento tapa välittää konkreettisempaa ja epämuodollisempaa tietoa digiviestinnän opiskelun arjesta Lisätiedot KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0
KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi Lisätiedot Thl.fi konseptointi 1. työpaja
MARKO SAARINEN marko.saarinen@solita.fi +358 40 740 1711 TERO SAARENPÄÄ tero.saarenpaa@solita.fi +358 50 359 0556 Thl.fi konseptointi 1. työpaja 20/8/2012 Agenda Lyhyet esittäytymiset Työpajan esittely Lisätiedot Tietohallinnon uudistuksia ja haasteita sähköisen hallinnon näkökulma viranomaisten asiakirjojen pysyvään säilyttämiseen
Tietohallinnon uudistuksia ja haasteita sähköisen hallinnon näkökulma viranomaisten asiakirjojen pysyvään säilyttämiseen Anne Kauhanen-Simanainen 11.6.2014 Mitä sähköisellä hallinnolla tavoitellaan? tehokkaampia Lisätiedot 83450 Internetin verkkotekniikat, kevät 2002 Tutkielma 83450 Internetin verkkotekniikat, kevät 2002 Tutkielma TTKK 83450 Internetin verkkotekniikat Tekijät: Ryhmän nro: Lisätiedot Kokonaisarkkitehtuuri. Kankaanpään kaupunki
Kokonaisarkkitehtuuri Kankaanpään kaupunki Kokonaisarkkitehtuuri johtamisvälineenä Kankaanpään strategia 2015 Avoimmuus Edistävä johtajuus Luovuus Jatkuva kehittyminen Tehokkuus Vetovoimaisuus Kilpailukyky Lisätiedot JHS Esiselvitys tietojärjestelmähankintaa varten
JHS Esiselvitys tietojärjestelmähankintaa varten Hankesuunnitelma v.0.3 1/12 SISÄLLYSLUETTELO 1 HANKKEEN LÄHTÖKOHDAT 4 1.1 Hankkeen perustamisen tausta 4 1.2 Hankkeen tavoitteet 4 1.3 Hankkeen sidosryhmät Lisätiedot JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa
JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 2. Liiketoimintamallit ja kyvykkyydet KA-suunnittelussa Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Lisätiedot Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien* hankinnoissa? Vaihtoehdot ja niiden haasteet?
Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien* hankinnoissa? Vaihtoehdot ja niiden haasteet? Timo Jokela, FT, dos. Joticon Oy (Oulun yliopisto, Helsingin yliopisto) *asiakaskohtaisten Lisätiedot Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007
Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut Lisätiedot Laadunvarmistus julkishallinnon ohjelmistoprojekteissa. 08.06.2010 Antti Sinisalo
Laadunvarmistus julkishallinnon ohjelmistoprojekteissa 08.06.2010 Antti Sinisalo Sisältö Julkinen hankinta ja kansallinen kilpailutusprosessi Laadunvarmistus julkishallinnon ohjelmistoprojekteissa Avoin Lisätiedot YritysSuomi verkko- ja puhelinpalvelun kehittäminen 15.11.2007
YritysSuomi verkko- ja puhelinpalvelun kehittäminen 15.11.2007 Jaana Lappi KTM, Elinkeino-osasto, TE-keskusryhmä 11/19/2007 1 YritysSuomi verkko- ja puhelinpalvelun kehittämisen lähtökohtana YritysSuomi Lisätiedot Kansalaisten sähköiset palvelut osana kuntien palveluprosesseja
Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta? Lisätiedot Case: Helsinki Region Infoshare - pääkaupunkiseudun tiedot avoimiksi
Case: Helsinki Region Infoshare - pääkaupunkiseudun tiedot avoimiksi Projektipäällikkö Ville Meloni Forum Virium Helsinki 5.4.2011 Hankkeen yhteenveto Avataan Helsingin seutua koskevaa tietoa kaikkien Lisätiedot Vastaajan taustatiedot
Lausuntopyyntö sosiaali- ja terveydenhuollon valtakunnallisesta kokonaisarkkitehtuurista Vastaajan taustatiedot 1. Lausunnon antajan organisaatiotyyppi * kunta sairaanhoitopiiri muu kuntayhtymä yksityinen Lisätiedot Kirja on jaettu kahteen osaan: varsinaiseen- ja lisätieto-osioon. Varsinainen
Alkusanat Tämän tieto- ja viestintätekniikan oppikirjan ensimmäinen versio (1. painos) syntyi vuonna 2006 Jyväskylän yliopiston tietotekniikan laitokselle tekemäni pro gradu -tutkielmani yhteydessä. Tutkimuksessani Lisätiedot KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ
KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset Lisätiedot Mikkelin sähköisen asioinnin alusta - päätöksenteko. Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665
Mikkelin sähköisen asioinnin alusta - päätöksenteko Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665 Esityksen osat Hankemallista jatkuvaan ylläpitoon Etenemisehdotus sidosryhmien Lisätiedot Näkökulmia hallitusohjelmaan, digitalisaatioon ja toimintamme kehittämiseen - Mitä tulisi tehdä ja mitä teemme yhdessä, mikä on TIETOKEKOn ja
Näkökulmia hallitusohjelmaan, digitalisaatioon ja toimintamme kehittämiseen - Mitä tulisi tehdä ja mitä teemme yhdessä, mikä on TIETOKEKOn ja JUHTAn roolit? Seminaari 09.06.2015 Sirpa Alitalo & Markku Lisätiedot JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli
JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Organisaation Lisätiedot Verkkoviestintäkartoitus
Verkkoviestintäkartoitus 9.2.2015 Minna Helynen minna.helynen@tampere.fi http://www.tyollisyysportti.fi/seutunuotta https://www.facebook.com/seutunuotta @seutunuotta http://takuullatekemista.blogspot.fi/ Lisätiedot Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015
Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty Lisätiedot Arkkitehtuuriverkosto toimija, kokonaisarkkitehtuurin edistämisessä
Arkkitehtuuriverkosto toimija, kokonaisarkkitehtuurin edistämisessä Kasvatus, esi- ja perusopetus, toinen asete (lukio- ja ammatillinen) sekä aikuiskoulutus Kurttu seminaari 30.9.2013 Leena Kononen 1 Yhteistyön Lisätiedot Ohjeita informaation saavutettavuuteen
Ohjeita informaation saavutettavuuteen Tarkoitus Kasvattaa tietoisuutta ja lisätä esteettömän informaation aiheen näkyvyyttä ja sen merkitystä elinikäisen tasapuolisen oppimisen mahdollisuuksista Tukea Lisätiedot Tietojärjestelmän osat
Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto Lisätiedot Liite 2. Alustava projektisuunnitelma. JulkICTLab tehtävien toimeenpanosta CSC - Tieteen tietotekniikan keskus Oy:n ja Valtiovarainministeriön välillä
Liite 2. Alustava projektisuunnitelma JulkICTLab tehtävien toimeenpanosta CSC - Tieteen tietotekniikan keskus Oy:n ja Valtiovarainministeriön välillä 16.10.2013 Versio: 0.4 Laatija: Kirsi Pispa 1 Sisältö Lisätiedot Julkisen hallinnon asiakkuusstrategia. Rovaniemi 29.11.2012 Johanna Nurmi
Julkisen hallinnon asiakkuusstrategia Rovaniemi 29.11.2012 Johanna Nurmi Miksi asiakkuusstrategia? Asiakkuusstrategian lähtökohtina ovat hallitusohjelmassa esitetyt linjaukset sekä Hallintopolitiikan suuntaviivat Lisätiedot Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla:
Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: a) käytettävyys b) käyttäjäkeskeinen suunnittelu c) luonnollinen kieli Lisätiedot Suomen avoimien tietojärjestelmien keskus COSS ry
Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet Lisätiedot Hankinnan suunnittelu, hankinnoista ilmoittaminen ja viestintä
Hankinnan suunnittelu, hankinnoista ilmoittaminen ja viestintä Julkisten hankintojen neuvontayksikön seminaari 21.10.2013 Lakimies, VT Jonna Törnroos Sähköiset viestintävälineet Jäsenvaltioiden on huolehdittava Lisätiedot OmaOulu asiointialusta Sähköisen asioinnin strategia. Paikkatietoseminaari 12.2.2014
OmaOulu asiointialusta Sähköisen asioinnin strategia Paikkatietoseminaari 12.2.2014 Sisältö OmaOulu-asiointialustan kehitys kehittämisstrategia 2006 2013 Perustana tietohallintostrategia (2006) kehittämisstrategia Lisätiedot QPR kuvausvälineen käyttö ja tavoitteet OKM&OPH, Oppijan palvelut - koulutuksen ja opetuksen osakohdealue. Leena Kononen 6.3.2013
QPR kuvausvälineen käyttö ja tavoitteet OKM&OPH, Oppijan palvelut - koulutuksen ja opetuksen osakohdealue Leena Kononen 6.3.2013 JulkICT-KA-ympäristön päivitys, kevät 2013 OKM/OPH arkkitehtuurikuvaukset Lisätiedot Käytettävyys julkishallinnon tietojärjestelmähankinnoissa tilaajan näkökulmasta
Käytettävyys julkishallinnon tietojärjestelmähankinnoissa tilaajan näkökulmasta Sytyke/ käytettävyys OSY Anu Ylä-Pietilä Lyhyesti Trafista Trafi vastaa liikennejärjestelmän sääntely- ja valvontatehtävistä, Lisätiedot Digipäivä, Hallintoryhmä. 25.8.2015 Sipoo
Digipäivä, Hallintoryhmä 25.8.2015 Sipoo NURMIJÄRVEN SÄHKÖINEN ASIOINTI 2 Tero Kulha Taustaa Sähköisestä arkistoinnista on puhuttu Nurmijärvellä kauan ja se ollut budjetissakin useampana vuonna. Nyt teema Lisätiedot Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön
Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa. Lisätiedot Oppijan verkkopalvelu Ammatillisen koulutuksen seminaari 14.11.2012 Pori. Ritva Sammalkivi
Oppijan verkkopalvelu Ammatillisen koulutuksen seminaari 14.11.2012 Pori Ritva Sammalkivi SADe-ohjelma (VM) Oppijan verkkopalvelu (OKM) Keskitetysti tuotetut palvelut (OPH) Oppijan palvelukokonaisuudessa Lisätiedot Hyvän verkkopalvelun rakentamisen periaatteita
Hyvän verkkopalvelun rakentamisen periaatteita Nuoret ja museon houkutus Museoliiton seminaari Marko Kuparinen 25.11.2008 Koulutus- ja kehittämiskeskus Palmenia Mikä on verkkopalvelu? Verkkopalvelu on Lisätiedot Strategian laadinta ja toimijoiden yhteistyö. Tehoa palvelurakenteisiin 25.10.2011 ICT-johtaja Timo Valli
Strategian laadinta ja toimijoiden yhteistyö Tehoa palvelurakenteisiin 25.10.2011 ICT-johtaja Timo Valli Information and Communication Technology Teknologia Kommunikaatio Infrastruktuuri Informaatio Integraatio Lisätiedot JHS XXX Kehittämisprojektien ohjaus ja hallinta julkisessa hallinnossa
JHS XXX Kehittämisprojektien ohjaus ja julkisessa hallinnossa 28.06.2010 1/14 SISÄLLYSLUETTELO 1 HANKKEEN LÄHTÖKOHDAT 4 1.1 Hankkeen perustamisen tausta 4 1.2 Hankkeen tavoitteet 4 1.3 Hankkeen sidosryhmät Lisätiedot G4 Yliopistosairaaloiden ja keskuskaupunkien yhteistyö. Yrjö Koivusalo tietohallintojohtaja VSSHP
G4 Yliopistosairaaloiden ja keskuskaupunkien yhteistyö Yrjö Koivusalo tietohallintojohtaja VSSHP Mikä ihmeen G4? Yliopistosairaanhoitopiirit paitsi HUS: Varsinais-Suomi, Pirkanmaa, Pohjois- Pohjanmaa, Lisätiedot Kunnan rakennetun ympäristön sähköiset palvelut (KRYSP)
Kunnan rakennetun ympäristön sähköiset palvelut (KRYSP) Hankkeen tavoitteet ja sisältö Kunnan rakennetun ympäristön sähköiset palvelut projektin (KRYSP) tavoitteena on tuottaa sähköinen asiointipalvelukokonaisuus, Lisätiedot EU ja julkiset hankinnat
EU ja julkiset hankinnat Laatua hankintoihin Julkiset hankinnat - taustaa EU2020-strategia edellyttää entistä voimakkaampaa panostusta osaamis- ja innovaatiotalouteen, vähähiiliseen ja resurssitehokkaaseen Lisätiedot MIIKKA VUORINEN, SANTERI TUOMINEN, TONI KAUPPINEN MAT-81100 Verkkopalvelun laadukkuus ja arviointi
AMPPARIT.COM VERKKOPALVELUN ARVIOINTISUUNNITELMA RYHMÄ VUTUKA MIIKKA VUORINEN, SANTERI TUOMINEN, TONI KAUPPINEN MAT-81100 Verkkopalvelun laadukkuus ja arviointi II SISÄLLYS 1 Arvioitava verkkopalvelu 3 Lisätiedot FlowIT virtaa IT-hankintoihin
FlowIT virtaa IT-hankintoihin Virpi Kalakoski, Matti Gröhn, Kirsi Jääskeläinen, Tiina Kalliomäki-Levanto, Jani Lukander, Kristian Lukander, Jarno Turunen, Teppo Valtonen, Tiina Vihtonen, Tuija Virtanen Lisätiedot Työpaja B - Kuinka kokonaisarkkitehtuurin laadunhallinta voidaan integroida osaksi korkeakoulun laatujärjestelmää?
Työpaja B - Kuinka kokonaisarkkitehtuurin laadunhallinta voidaan integroida osaksi korkeakoulun laatujärjestelmää? Työpisteessä pohdittiin, mitä on kokonaisarkkitehtuurin laadunhallinta ja miten se voidaan Lisätiedot MAANMITTAUSLAITOKSEN LAUSUNTO HALLITUKSEN ESITYKSESTÄ LAIKSI HALLINNON YHTEISISTÄ SÄHKÖISEN ASIOINNIN TUKIPALVELUISTA
1 (6) Valtiovarainministeriö valtiovarainministeriö@vm.fi Valtiovarainministeriön lausuntopyyntö 26.11.2015 / VM140:06/2013 MAANMITTAUSLAITOKSEN LAUSUNTO HALLITUKSEN ESITYKSESTÄ LAIKSI HALLINNON YHTEISISTÄ Lisätiedot Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria?
Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Kuntamarkkinat Tietoisku 10. ja 11.9.2014 1 Mitä on kokonaisarkkitehtuuri? Kokonaisarkkitehtuuri on organisaation johtamis- ja kehittämismenetelmä, Lisätiedot Asiakas ja tavoite. Tekninen toteutus
Asiakas ja tavoite Heikieli on vuonna 2015 perustettu yhden hengen asiantuntijayritys, joka tarjoaa käännös- ja oikolukupalveluita englannista ja saksasta suomeksi. Freelance-kääntäjiä on Suomessa paljon, Lisätiedot Valtionhallinnon lausuntoprosessin kehittäminen ja digitaalinen tietojen hallinta Digitaaliseen tietojen hallintaan Sotu seminaari 29.11.
Valtionhallinnon lausuntoprosessin kehittäminen ja digitaalinen tietojen hallinta Digitaaliseen tietojen hallintaan Sotu seminaari 29.11.2013 Markku Nenonen Tutkijayliopettaja Mamk Lähtökohdat ja tausta Lisätiedot BLOGGER. ohjeita blogin pitämiseen Googlen Bloggerilla
BLOGGER ohjeita blogin pitämiseen Googlen Bloggerilla Sisältö Blogin luominen... 1 Uuden blogitekstin kirjoittaminen... 4 Kuvan lisääminen blogitekstiin... 5 Lisää kuva omalta koneelta... 6 Lisää kuva Lisätiedot AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011
AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä Lisätiedot AKATEEMISEN OSAAMISEN DOKUMENTOINTI
AKATEEMISEN OSAAMISEN DOKUMENTOINTI Tiina Kosunen tiina.kosunen@helsinki.fi Sisältö Portfolio??? Portfolion kaksi roolia Yliopistoportfolion rakenne ja sisältö Portfolio CV Hyvä / huono / turha portfolio Lisätiedot Sähköiset palvelut - Isäntä ja renki
Sähköiset palvelut - Isäntä ja renki Projektikoordinaattori Minna Vänskä, Helsingin yliopisto Avoimien yliopistojen neuvottelupäivät To 1.10.2009 6.10.2009 1 Sähköisiä palveluja asiakkaille Opintojen haku Lisätiedot Perussurffaajat: Tiia Tirkkonen, Teppo Porkka, Janne Tuomisto. Verkkopalvelun arviointisuunnitelma Spotify
Perussurffaajat: Tiia Tirkkonen, Teppo Porkka, Janne Tuomisto Verkkopalvelun arviointisuunnitelma Spotify Tampereen teknillinen yliopisto Hypermedia MATHM- 00000 Hypermedian opintojakso 30.9.2011 Sisällysluettelo Lisätiedot Avoimen datan vaikutuksia tiedontuottajan toimintaan
Avoin data ja liiketoiminta Avoimen datan vaikutuksia tiedontuottajan toimintaan SKS/Poligonin talviseminaari 3.2.2011 Antti Kosonen MML Tietopalvelukeskus MML ja avoin data 2011 alusta MML on tarjonnut Lisätiedot Liite B. Asemakaavan mallinnus tiedonsiirtoa varten
Liite B. Asemakaavan mallinnus tiedonsiirtoa varten Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Asemakaavasuosituksen tausta... 2 1.2 Asemakaavasuosituksen Lisätiedot Tampereen kaupungin paikkatietostrategia 2013 2015. Tampereen kaupunki
Tampereen kaupungin paikkatietostrategia 2013 2015 Tampereen kaupunki 28.3.2013 TAMPERE Tampereen kaupungin paikkatietostrategia 1 PAIKKATIETO JA PAIKKATIETOINFRASTRUKTUURI KÄSITTEENÄ Paikkatiedolla tarkoitetaan Lisätiedot IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT
IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen. Lisätiedot SOPIMUS [...] PALVELUSTA
Julkisen hallinnon IT- hankintojen sopimusehdot (JIT 2007) 1 ----------------------------------------------------------------------------------------------------------------------------------- [JHS 166 Lisätiedot Kohti kokonaisvaltaista tietojohtamista Kokonaisarkkitehtuuri johtamisen tukena. 7.6.2013 Leena Kononen
Kohti kokonaisvaltaista tietojohtamista Kokonaisarkkitehtuuri johtamisen tukena 7.6.2013 Leena Kononen 1 Johtaminen tiedon ekosysteemissä Tiedon ekosysteemi johtuu tiedon jatkuvasta kierrosta ja uusiutumisesta Lisätiedot 4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa
4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat Lisätiedot Verkkopalveluiden saavutettavuus
Verkkopalveluiden saavutettavuus Puhuja: Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Paikka: Helsinki, Tieteiden talo, 24.3.2011 Johdanto Verkkopalvelun saavutettavuus Lisätiedot JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus
JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Arkkitehtuurikehyksen Lisätiedot Sosiaalihuollon toimintaprosessien mallinnus. Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä
Sosiaalihuollon toimintaprosessien mallinnus Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä Sisältö Taustaa Tavoite Lähtökohta Tuotokset Prosessien kuvaaminen esimerkkinä lasten päivähoito Lisätiedot 2016 © DocPlayer.fi Yksityisyyskäytäntö | Palveluehdot | Palaute