Näkemiin InfoPath, oli (toisinaan) mukava tuntea – mitä tilalle, kun toteutat sähköisiä lomakkeita?

Microsoft tiedotti alkuvuodesta 2014 jo odotetun uutisen – InfoPath ja sen palvelinpuolen vastine Forms Services ovat elinkaarensa päässä, eikä uusia versioita näistä kahdesta tuotteesta tulla enää näkemään.

Uutinen ei lukuhetkellä yllättänyt. Olihan tätä odotettu mutta silti näinkin suoraviivainen tiedote asiasta (“..we’re retiring InfoPath 2013..”) yllätti allekirjoittaneen. Microsoftin Keenan Newton kirjoitti aiheesta noin vuosi sitten blogiartikkelissaan näin:

“You have a choice of tools for building forms with SharePoint, including InfoPath, Access, Excel, and Visual Studio”

Ja heti perään:

“InfoPath is our integrated forms solution for the foreseeable future.”

Muistan tämän artikkelin lukuhetkellä pohtineeni miten sekava tilanne on IT-ammattilaiselle – saati sitten tehokäyttäjälle, jonka pitäisi sähköisiä lomakkeita toteuttaa tai käyttää. Mikä oikeasti on sopiva ratkaisu? Miksi InfoPath ei ole tuonut oikeastaan mitään uutta vanhan 2010-version tilalle? Onko jotain uutta tulossa tilalle?

Vaikka vuosi on IT:ssä pitkä aika on silti selkeää, että Microsoft huomasi tilanteen sekavuuden lomaketeknologioissaan ja päätti tehdä asialle jotain – ja lopputuloksena InfoPathin pikainen eläköityminen. Muutoin kai olisi aika ikävä temppu kertoa asiakaskunnalle, että InfoPathiin satsataan jatkossakin, ja tappaa tuote alle vuoden kuluttua tästä – tarjoamatta mitään siirtymäpolkua nyt legacyksi muuttuneista ratkaisuista johonkin parempaan.

Tilalle ei juuri tänä päivänä Microsoftilla ole tarjota mitään uutta, vain nykyisiä ratkaisuja ja toistaiseksi promisewarea Paremmista Työkaluista – sitten tulevaisuudessa. Uudet lomaketyökalut (jep, useampi) ovat tulossa tämän vuoden jälkimmäisellä puoliskolla.

Kokosin yhteen viisi näkemystä, joista on toivottavasti apua jos mietit sähköisten lomakkeiden toteuttamista Intranet/Extranet-alustoille, ja olet jo valinnut SharePointin toteutusalustaksi:

1. Älä toteuta mitään InfoPathilla, minkä voit toteuttaa järkevästi jollain muulla teknologialla

InfoPath on kuollut. End of life. Siirretty eläkkeelle. Investoinnit InfoPathiin sisältävät selkeän taloudellisen riskin: Jos nyt toteutat projektin ja ajaudut erilaisiin integraatioihin, virittelyihin ja pieneen räätälöintiin jotta lomake toimii halutulla tavalla, ei toistaiseksi ole saatavilla työkalua InfoPath-lomakkeiden migroinnista tulevaisuuden alustoihin. Microsoft lupaa tällä hetkellä migraatioon ohjeistusta (guidance) aikanaan mutta sen tasosta tai riittävyydestä on mahdoton sanoa vielä mitään. Suosittelen varovaisuutta, koska pahimmillaan ohje voi olla tasolla “Kopioi sisältö uusiin lomakepohjiin”.

Yksinkertaiset lomakkeet voi mielestäni hyvin tehdä InfoPathilla vielä nytkin. Ongelmaksi muodostuu lähinnä haaste projekteissa, joissa yksinkertainen lomake kasvaa ajan mittaan monimutkaiseksi ja lopulta migrointi toiseen teknologiaan osoittautuu pahimmillaan erittäin työlääksi ja vaikeaksi.

2. Access on hyvä, kunhan et yritä rakentaa uutta Accessia

Olen aina ollut tyytymätön Accessiin, siis jo ennen Access Services-aikaa, jolloin Access oli – erästä tietokantagurua lainatakseni – “hauska kortisto-ohjelma reseptien tallentamiseen”. Sittemmin Access on kehittynyt lupaavasti ja nyt Access Appsien myötä se alkaa olla jo varteenotettava yleisimpiin käyttötarkoituksiin, joissa InfoPathia on aiemmin käytetty. Menemättä tässä artikkelissa teknisiin detaljeihin, Access Appsit vaativat pohjalle joltisenkin verran konfigurointia ja ylläpitoa, sekä lisäksi on-premises toteutuksissa Enterprise CAL-lisenssit käyttäjille.

Oleellisesta Access-pohjaisissa ratkaisuissa on miettiä kulloisenkin toteutettavan lomakkeen järkevyyttä Accessin näkökulmasta. Onko järkevää toteuttaa “Osallistutko pikkujouluihin”-kyselyt omina tietokantasovelluksinaan, vai riittäisikö jokin yksinkertaisempi toteutus? Vastaavasti monimutkaiset ja haarautuvat lomakkeet ovat enemmän ja vähemmän ideaaleja Accessilla toteutettavaksi. Suoranaiseksi InfoPathin korvaajaksi Accessista ei ole, koska teknisen käyttöalustan konfigurointi on työläämpää, ja vastaavasti Access ei käyttöliittymältään ole yhtä helppo omaksia kuin InfoPath.

3. Visual Studiolla voit toteuttaa mitä tahansa mutta älä toteuta mitä tahansa

Visual Studiolla voidaan nyt toteuttaa lomakkeita käytännössä kolmella eri tavalla: Klassisena .NET-toteutuksena (full-trust solution SharePointiin), SharePoint appsina ja HTML/JavaScript-lomakkeena. Kaikki kolme tapaa vaativat ohjelmointikykyjä ja näkemystä, sekä toteutustavasta riippuen enemmän ja vähemmän kiveen hakattua lomakemallia, joka toteutetaan “one-off”-tyyppisenä kertaratkaisuna. Aika usein tätä vaihtoehtoa heitellään huolettomasti vaihtoehtona, kun InfoPath/Access/HTML-lomakkeet tuntuvat liian heppoisilta: “Tee Visual Studiolla”. Ratkaisuehdotus on silloin saman tasoinen kuin “katso Googlesta”, kun etsitään ratkaisua tiettyyn ongelmaan.

En vastusta Visual Studiolla (tai millään muullakaan sovelluskehittimellä) tehtäviä räätälöintejä sähköisten lomakkeiden toteutusmalliksi mutta projektina puhutaan täysin eri kokoluokan ratkaisuista, kuin 1-3 päivän InfoPath/Access-toteutuksesta, jonka prototyypin näkee lähes reaaliajassa työstövaiheen aikana.

Näkisinkin Visual Studiolla tehtävät lomakkeet parhaimmillaan silloin, kun tehdään monistettavia lomakkeita (esim. viikottain), joihin liittyy selkeät liiketoiminnan sanelemat rajoitukset ja toiminnot – ja joissa InfoPath/Access ovat luontaisesti heikkoja.

4. Perinteinen HTML-lomake tai SharePointin Survey on usein “good enough”

Turvallinen ja helppo, mutta samalla tylsä ja suppea vaihtoehto. SharePointin Survey-työkalulla tehtävät lomakkeet “vain toimivat” mutta mitään kovin mahtavaa niillä ei lopulta saa aikaiseksi. Yksinkertaiset lomakkeet ja vastausvaihtoehdot onnistuvat mies+hiiri-yhdistelmällä kahvitauolla, mutta varsinaisesti oikeaksi liiketoimintaa ohjaavaksi lomakeratkaisuksi tästä harvoin on. Ellei tietysti liiketoiminnalle riitä yksinkertaiset lomakkeet (eikä siinäkään mitään pahaa ole), ja silloin Surveyt ovat hyvä ja takuuvarmasti huokea valinta.

Perinteinen HTML-lomake on myös käypä, kun intoa ja osaamista riittää viritellä esimerkiksi JavaScriptillä ylimääräistä logiikkaa lomakkeen ympärille. Kovin robusteja ratkaisuja tällä en lähtisi hakemaan mutta hämmästyttävän usein muutamalla JavaScript-kielen rivillä tekee sen mitä Surveyllä olisi mahdoton tehdä, ja se saattaa riittää.

5. Excel ja Yammer tarjoavat välimuodon, kunnes tulevaisuus saapuu

Excelin omaa Surveys-toimintoa positioidaan vahvasti korvaamaan edellisessä kohdassa mainittuja vaihtoehtoja. Lähtökohtaisesti Excel Surveys on osa Excel Onlinea, joka on osa Office Online-palvelua. Toiminnon avulla voidaan rakentaa yksinkertaisia kyselyitä osana Excel-sheetiä, ja tulokset kerätään samaan Exceliin. Toistaiseksi Excel Surveys on melko yksinkertainen ja karu, ja tuntuu melko pikaisesti kyhätyltä osaksi Office Onlineä. Ratkaisu toimii myös on-premisenä, mutta edellyttää OneDrive for Business-palvelun käyttöönottamista ja ainakin tällä hetkellä laahaa rajusti Office Online-versiota jäljessä.

Yammer sisältää myös oman Poll-toiminnon, jonka avulla organisaation sisäiset (tai ulkoiset) kyselyt voidaan toteuttaa puhtaasti Yammerin sisällä. Pieniä puutteita tässäkin on, enkä laskisi Yammerin Poll-toimintoa alkuunkaan samaan kategoriaan edellämainittujen (InfoPath, Access, HTML/JavaScript, Excel Surveys, Visual Studio) ratkaisujen joukkoon. Poll-toiminnolla voidaan lähinnä kysellä äänestysmallilla mielipiteitä, mutta kattava tulosten analysointi tai tabulointi loistaa vielä poissaolollaan.