“Tehtävän menestyksekäs hoitaminen edellyttää kokemusta toimittajan ja/tai verkkosisällön tuottajan roolista sekä sosiaalisen median hyödyntämisestä. Osaat myös muokata faktat helposti hyödynnettävään sekä jaettavaan muotoon. Sinulla on kokemusta lehden ja verkkojulkaisujen tekemisestä ja/tai markkinointikampanjoista sekä kampanjaviestinnästä.”

Puolueiden viestintäkoneisto lieneekin melko monimuotoinen paikka tällä hetkellä. Kohdeyleisöjen odotukset vaihtelevat laidasta laitaan, joten kanavien monimuotoisuus lienee todellisuutta vielä pitkään.

“Sinulta löytyy myös graafista silmää ja hallitset yleisimmät taitto-, kuvankäsittely- sekä editointiohjelmat. Sosialidemokratian ja järjestöalan tuntemus sekä englannin ja ruotsin kielen taito katsotaan vahvuudeksi. Työehdot määräytyvät Järjestötoimitsijain Liiton JTL ry. työehtosopimuksen mukaisesti ja palkka on n. 3700 e/kk.”

>> Katso ilmoitus: Verkkoviestinnän ammattilainen/toimittaja

Tässä joukko poimintoja tällä hetkellä avoimista työpaikoista:

• Senior Web Application Developer (Frosmo, Helsinki)
• Junior Web Developer (Pisa Digital, Helsinki)
• Web designer, mobiilipalvelut (NearMe Services, Espoo)
• Konseptisuunnittelija / käyttöliittymäsuunnittelija (Logica, Helsinki, Tampere, Lahti tai Joensuu)
• Verkkopalvelujen tuottaja (StudentWork Sharper Oy, Tampere)
• Flash-suunnittelija (StudentWork Sharper Oy, Tampere)
• 8 kehittymishaluista web-kehittäjää (useita työnantajia, pääkaupunkiseutu)
• Copywriter (Reaktor, Helsinki)
• Verkkoliiketoiminnan huippuosaaja (Mediakolmio, Lappeenranta)
• Frontend-kehittäjä (Mediakolmio, Lappeenranta)
• AD ja graafinen suunnittelija (Mediakolmio, Helsinki tai Lappeenranta)
• Web-suunnittelija (Vida Design Oy, Pori)
• Web-ohjelmoija (Suomen Vuokraisäntä Oy, Helsinki)
• Web-ohjelmoija (Finnish Net Solutions Oy, Espoo / Lohja)
• Front-End Developer (Starcut Software Oy, Espoo)
• Web Designer (Sininen Meteoriitti, Helsinki tai Jyväskylä)

>> Kaikki avoimet työpaikat web-alalla

1) Teitte tuotteenne uudistuksen hiljattain – miksi päätitte uudistaa tuotteenne alusta saakka uusiksi?

“Päätimme kirjoittaa kaiken uusiksi alusta. Erityisesti tietämys asiakkaiden tarpeista lisääntyy meidänkaltaisen verkkosovelluksen alkuaskelien aikana. Lisäksi myös oma liiketoimintamalli hakee suuntaansa. Meidän tapauksessamme olimme tehneet järjestelmän jolla pystyi varaamaan aikoja resursseilta, mutta kun palvelun kysyntä lisääntyi, niin totesimme esimerkiksi parturi- ja palvelupuolella koko alan logiikan olevan erilaista kuin mihin olimme alunperin varautuneet. Jouduimme jumppaamaan erityisesti ohjelmiston tietomallia. Lisäksi jouduimme miettimään käyttötavat ja käytettävyyden uudestaan, niin että se palvelisi asiakaskuntaa josta meillä ennestään oli kovin vähän substanssiosaamista. Palvelun uudelleenkirjoitus kesti yli vuoden, mutta nyt meillä on sovellus joka taipuu ilman liimaa ja purkkaa niihin tarkoituksiin joissa tänään näemme kasvumme olevan. Tällä hetkellä tärkein palvelumme on nimittäin palvelu- ja ryhmävarausten myymisessä sekä PK-yrittäjien markkinointivälineenä. Alunperin olimme tekemässä tennisratavarausjärjestelmää, joka oli täysin eri maailmansa.”

2) Millä teknologioilla ja millaisin voimin palvelun uudistettu versio nousi pystyyn?

“Uudistettu versio päätettiin tehdä samalla teknologiapaletilla kuin aikaisempikin versio, joka oli hyväksi havaittu, ja jolla pääsimme nopeasti vauhtiin. Ajanvarausjärjestelmämme on Linux+Apache+MySQL+PHP-pohjainen sovellus, jossa käytämme JQuerya käyttöliittymän sokeroimisessa. Palvelu uudistettiin yhden hengen voimin ja uudistuksen kesto oli yli vuoden pituinen työurakka.”

3) Kuinka paljon käytitte työaikaa ja millaisiin asioihin meni eniten aikaa?

“Uudelleenkirjoitus oli erittäin tekninen prosessi jossa suurin osa ajasta (50%+) meni käytettävyyden määrittelemiseen ja suunnitteluun. Työaikaa kului yhteensä noin 350 henkilötyöpäivää kahdelta henkilöltä. Tästä työmäärästä koodaus vei noin puolet ajasta.”

4) Kuinka paljon teillä menee palvelun ylläpitoon, asiakaspalveluun ja jatkuvaan kehittämiseen nykyisin aikaa?

“Ylläpito ja asiakaspalvelu itsessään vie 1-5 tuntia viikossa aikaa. Kaikki keskeiset, toistuvat toiminnot laskutuksesta alkaen on automatisoitua. Jatkuva kehitys saa osakseen kaiken jäljelle jäävän ajan. Välillä on tasaisempia aikoja jolloin nykyistä palvelua parannetaan, ja välillä taas jokin osa-alue räjäytetään osiin, ja aloitetaan joltain osin uudestaan. Teemme noin yhden täyden henkilön edestä töitä järjestelmään tällä hetkellä, joten huomattavasti vähemmän kuin uudistuksen yhteydessä. Toisaalta täysin uudistettu palvelu mahdollistaa muutokset paljon tehokkaammin, joten aikaa jää enemmän asiakaspalveluun.”

5) Mistä asioista muiden kannattaisi ottaa oppia teidän kohdallanne? Mitkä asiat sujuivat mielestäsi hyvin uudistuksessa? Mitä tekisitte kenties toisin?

“Se, että jos haluaa tehdä loistavia verkkosovelluksia on tunnettava sekä teknologiaa että ihmisiä. Yksin “liiketoimintaosaamisella” ei voi tuoda ratkaisuja jotka palvelevat ihmisiä tarpeeksi hyvin, ja yksin teknologiaa osaamalla ei voi tehdä mitään. Suomessa hyvä esimerkki onnistuneesta liiketoimintaosaamisen ja teknisen osaamisen yhdistämisestä on mielestäni esimerkiksi Eat.fi.

Jos voisin aloittaa alusta nyt, niin keskittyisimme myyntiin enemmän heti alussa emmekä odottaisi “ensimmäistä valmista versiota heti nurkan takana”. Muuten olen erittäin tyytyväinen kaikkeen mitä olemme saaneet aikaiseksi. Mutta oppina muille, ymmärtäkää teknologiaa ja asiakkaita, niin onnistutte siinä mitä yritätte tehdä – liian usein painotetaan vain business plania, mutta unohdetaan että jos halutaan tehdä jotain mullistavaa, se ei riipu vain siitä liiketoimintasuunnitelmasta.”

Kommentit (Perttu Tolvanen): DigitalBooker on esimerkki verkkosovelluksesta, jonka ensimmäinen versio ei vastannut toiminnallisesti sitä mitä markkinat kaipasivat. Palvelun kehityksessä jouduttiin tunnustamaan, että pelkästään muokkaamalla hieman perusteita ei jatkokehitys olisi järkevää. Täten päädyttiin uudistamaan koko sovellus alusta alkaen.

Tämä on hyvä esimerkki ohjelmistoalan realiteeteista, jotka koskettavat etenkin tiettyyn erikoistarkoitukseen tehtäviä sovelluksia. Joskus vain täytyy laittaa palvelun perustus kokonaan uusiksi. 

Rönnlund myös korostaa kokemuksissaan sitä, että pelkästään liiketoimintaosaaminen ei riitä menestyvän kaupallisen verkkosovelluksen pyörittämiseen. Tekniikan hallitsemisella on merkittävä rooli, ja tekniikan kanssa tulee olla valmis myös työskentelemään ensimmäisen toteutusvaiheen jälkeen.

Webshaped-seminaarin ajankohta on osuva, koska juuri tänä keväänä on frontend-kehittäminen ollut kuumana puheenaiheena, ja samalla esimerkiksi aihepiirin rekryilmoituksien määrä on lähes räjähtänyt.

Puhujina tapahtumassa nähdään sekä kotimaisia että ulkomaisia ammattilaisia. Mielenkiintoisiin puhujiin lukeutuu mm. designer-supertähti Simon Collison, Github -palvelun pääsuunnittelija Kyle Neath sekä palkitun Tinkercad-palvelun WebGL-asiantuntija Mikko Mononen.

Tapahtuman järjestäjiin kuuluu suomalaisia verkkoammattilaisia, joilla on aiempaakin historiaa tapahtumien järjestämistä (esim. Agile Finland ja Frozen Rails). Organisaattorit ovat myös olleet pystyttämässä kotimaista frontend-yhteisöä (www.frontend.fi).

Tapahtuman hinta on 230 euroa, ja päivän laadukkaasta seminaarista tätä ei voi pitää pahana hintana.

Harvoin Suomessa järjestetään näin kapeaan kenttään erikoistunutta ammattilaisseminaaria juuri webin tekijöille. Sponsoreina tapahtumalla on myös tunnettuja web-alan toteuttajafirmoja, kuten Futurice ja Reaktor.

Kannattaa siis tarttua tilaisuuteen, jos tilaa kalenterista löytyy.

>> Tarkempi ohjelma ja lisätietoja löytyy osoitteesta http://webshaped.fi

PS. Vierityspalkin yleisöön kuuluville frontend-asiantuntijoille on kaksi ilmaislippua tarjolla. Lipun saa kaksi ensimmäistä kommentoijaa, jotka osaavat kertoa kuka puhujista kertoo tarinaa responsiivisen designin toteutuksen workflowsta käytännön tasolla. Jätä kommenttiisi nimi ja sähköpostiosoite, niin pääset seminaariin ilmaiseksi. Lippu on henkilökohtainen.

Otsikkona on “Mobiilisivustot vai responsiivinen design?“. Seminaari järjestetään reilun kahden tunnin mittaisena aamupalatilaisuutena perjantaina 4.5.2012 digitoimisto Deasignin tiloissa Helsingissä. Seminaari alkaa klo 8.30 aamupalalla. Ohjelma alkaa klo 9.00 ja päättyy klo 11.00.

Seminaarissa on neljä lyhyttä puheenvuoroa asiantuntijoilta, jotka ovat olleet eri puolilla mobiilisivustojen rakentamisprojekteja. Seminaarissa mobiilisivustojen toteutuksen haasteisiin ja ratkaisuihin otetaan neljä erilaista näkökulmaa.

Ensimmäistä näkökulmaa edustaa SC5-yrityksen Pyry Lehdonvirta. Pyry Lehdonvirran tausta on etenkin eri päätelaitteet tavoittavissa HTML5-ratkaisuissa. Pyry avaa seminaarissa responsiivisen suunnittelun käsitettä, ja kertoo myös miksi hänen mielestään julkaisujärjestelmien aikakausi on mobiilipalveluiden ja uusien web-standardien myötä historiaa.

Toisena puhujana lavalle nousee Sinisen Meteoriitin Lead Designer Tuukka Uskali. Tuukka katsoo maailmaa myös vahvasti responsiivisen suunnittelun näkökulmasta, mutta kertoo erityisesti siitä millaista on tehdä mobiilipalveluita SharePoint-julkaisujärjestelmän päälle. Tuukan näkökulmana on avata sitä mitkä asiat perinteisissä julkaisujärjestelmissä ovat kenties hieman ristiriitaisia mobiilipalveluiden toteutuksen näkökulmasta.

Kolmantena esiintymisvuoroon pääsevät vihdoin “julkaisujärjestelmämiehet”, joita seminaarissa edustaa EPiServerin Petri Isola. Petrin tavoitteena on tietysti todistaa kaksi edellistä puhujaa aivan tyhjänpuhujiksi, ja todistaa julkaisujärjestelmien mahtipontisuus myös mobiiliaikakauden myllerryksessä.

Viimeisen sanan seminaarissa saa kehityspäällikkö Kaisa Aalto HS.fi:n dev-tiimistä. Kaisa kertoo miten HS.fi on vastannut mobiilimyllerrykseen, ja mitä heillä on suunnitteilla jatkossa – ja tietysti Kaisa paljastaa, että kenen edellisten puhujien sanomaan Kaisa uskoo eniten.

Ohjelma: Mobiilisivustot vai responsiivinen design?  -seminaari 4.5.2012

• 8.30-9.00 Aamupala
• 9.00-9.10 Avauspuheenvuoro: Perttu Tolvanen
• 9.10-9.25 Responsiivinen design ja miksi julkaisujärjestelmät ovat historiaa? -Pyry Lehdonvirta
• 9.25-9.40 Mobiilisivustot ja responsiivinen design SharePointilla – onnistuuko? -Tuukka Uskali
• 9.40-9.55 EPiServer-julkaisujärjestelmä ja mobiilikanava paketista -Petri Isola
• 9.55-10.10 HS.fi ja mobiilikanavaratkaisut -Kaisa Aalto
• 10.10-10.20 Tauko
• 10.20-10.50 Paneeli ja keskustelua

Seminaarin osallistujiksi toivotaan erityisesti asiakasorganisaatioiden edustajia, koska seminaarin ohjelma on suunniteltu nimenomaan auttamaan asiakkaita tekemään parempia päätöksiä mobiilikanavien toteutuksen suhteen.

Seminaari on ilmainen.

>> Ilmoittaudu seminaariin (Huom. seminaari on täynnä!)

Verkkopalveluja käytetään nykyisin uskomattoman monimuotoisella joukolla laitteita. Tätäkin sivustoa selaillaan ainakin tableteilla, älypuhelimilla, kannettavilla ja työasemilla. Videopalvelu Netflix uutisoi yksistään erilaisten palveluaan käyttävien Android-laitteiden määräksi lähes tuhat. Tutkimusfirma Gartner raportoi samansuuntaisesta kehityksestä: heidän mukaansa tabletit ja älypuhelimet muodostavat 90 % uusien laitteiden hankinnassa tapahtuvasta kasvusta vuoteen 2015 mennessä.

Verkkopalvelujen suunnittelun on sopeuduttava laitteiden ja käyttötapojen monipuolistuvaan valikoimaan. Emme voi enää olettaa, että verkkopalvelujen käyttö rajoittuu työasemien tai kannettavien tietokoneiden äärelle. Tämän kehityksen huomioiminen ei saa olla suunnittelun jälkiviisautta tai irrallinen vaihe, vaan laitteiden koko kirjo on otettava suunnittelun lähtökohdaksi.

Mukautuvat käyttöliittymät osana Mobile first -strategiaa

Ethan Marcotten webin osalta tunnetuksi tekemä mukautuva suunnittelu (responsive design) tarjoaa erään ratkaisun laitteiden monimuotoisuudesta syntyneeseen suunnitteluhaasteeseen. Mukautuvuudella tarkoitetaan käyttöliittymien kykyä sopeutua käytetyn laitteen ominaisuuksien perusteella. Verkkopalvelun käyttöliittymä saattaa esimerkiksi älypuhelimella selattuna sisältää kaiken tekstin yhdessä palstassa, kun tabletilla sama teksti voi olla jaettuna kahteen palstaan. Käyttöliittymän visuaalinen esitystapa voidaan määritellä laitteen ominaisuuksien mukaan koskematta sivuston rakenteeseen.

Luke Wroblewskin esittelemässä Mobile first -suunnittelustrategiassa ydinajatuksena on, että käyttöliittymän suunnittelussa lähdetään liikkelle progressive enhancement -metodologian mukaan. Tässä lähestymistavassa suunnittelun lähtökohtana toimii kaikkien laitteiden “heikoin yhteinen nimittäjä”. Esimerkiksi työaseman näytölle tarkoitettua käyttöliittymää ei usein ole mielekästä skaalata pienemmäksi älypuhelinta varten, vaan työasemalle tarkoitettu käyttöliittymä rakentuu älypuhelimella näkyvän käyttöliittymän pohjalle. Näin vältytään muun muassa mobiililaitteiden suorituskykyyn liittyviltä ongelmilta.

Mukautuva suunnittelu perustuu CSS3-spesifikaation mukaisiin media queryihin, joiden avulla voidaan määritellä niin sanottuja breakpointteja laitteiden eri ominaisuuksien perusteella. Esimerkiksi selainikkunan leveys voi toimia kriteerinä breakpointtia määriteltäessä. Kun breakpointin sisältämä ehto täyttyy, otetaan tietyt media queryn sisältämät tyylimääritykset käyttöön. Tuki media queryjen käytölle löytyy jo nyt kaikista moderneista selaimista, eli mitään ylivoimaisia teknisiä esteitä niiden hyödyntämiselle ei ole.

Mukautuva suunnittelu on vielä rajoittunutta

Nykyisin enemmistö mukautuvista käyttöliittymistä rakentuu laitteiden näyttöjen leveyden mukaan määriteltyihin breakpointteihin. Useimmissa tapauksissa mukautuvuus ei valitettavasti toteudu käyttöliittymän skaalaamista ja sisällön uudelleenjärjestelyä pidemmälle. Suunnittelutyön onnistumisen kannalta tällainen lähes puhtaasti tekninen lähestymistapa on ongelmallinen, sillä näin tehdyt ratkaisut perustuvat usein vain rajalliseen joukkoon jo olemassa olevia laitteita.

Mukautuvien käyttöliittymien sisältämät ratkaisut tulisi aina perustella ensisijaisesti käyttäjän kannalta. Käytetyllä päätelaitteella ei tulisi olla merkitystä, vaan aidosti mukautuva käyttöliittymä on miellyttävä käyttää millä laitteella tahansa. Laitteiden ominaisuudet ja niiden perusteella määriteltävät breakpointit ovat ainoastaan apuvälineitä, joiden ei missään tapauksessa tulisi sanella käyttöliittymän lopullista muotoa tai luonnetta. Breakpointtien valinnassa kannataa pyrkiä vaihtoehtoihin, jotka takaavat käyttöliittymän kannalta luonnollisen tuntuisen lopputuloksen.

Käyttöliittymän toimivuutta korostava, mukautuva ja proaktiivinen suunnittelu on tulevaisuutta ajatellen järkevä tapa toimia. Kun käyttöliittymä ei ole liian tiukasti sidoksissa tällä hetkellä olemassa oleviin laitteisiin, on se todennäköisesti suhteellisen toimiva myös tulevaisuuden laitteissa. Valitettavasti laitteiden monimuotoisuuden huomioiva suunnittelu jää vielä tällä hetkellä usein hyvin insinöörimäiselle ja pinnalliselle tasolle. Mukautuvien käyttöliittymien suunnitteluun kaivataankin lisää käyttäjäkeskeisyyttä ja maalaisjärjen käyttöä.

Sisältö tulee suunnittella ja toteuttaa mobiiliin sopivaksi

Käyttökokemusten tason nostamiseksi pelkkä käyttöliittymän onnistunut suunnittelu ei riitä. “Sisältö on kuningas” on Mobile first -suunnittelustrategian kannalta oikea tapa asennoitua sisällön rooliin verkkopalveluissa. Tavat esittää sisältöä työasemilla tai kannettavissa tietokoneissa eivät usein ole mobiilikäyttöön mielekkäitä. Tarkkaan harkittu sisältöstrategia onkin Mobile first -lähestymistavan eräs olennaisimmista elementeistä.

Mobiililaitteiden käyttö eroaa merkittävästi perinteisestä tavasta käyttää tietokoneita. Käyttäjien motivaatio, käytön konteksti ja käyttäjien tarpeet ovat mobiilikäytössä erilaisia. Mobiililaitteille tyypillistä on sykäyksittäin, tiheästi toistuva käyttö. Esimerkiksi säätietojen tarkastaminen kesämökiltä älypuhelimella heikon datayhteyden varassa on luonteeltaan täysin erilainen tapahtuma kuin seuraavan viikon sääennusteen katselu kannettavalla tietokoneella kiinteän verkkoyhteyden varassa suurkaupungin keskustassa. Käyttötilanteiden ominaispiirteiden ja vaatimusten tunnistaminen ja tukeminen ovatkin sisältöstrategian onnistumisen kannalta kriittisiä tekijöitä.

Mobiililaitteiden sisällöissä vähemmän on usein enemmän. Sisällön on oltava käyttötilanteen luonteen takia ytimekästä, yhtenäistä ja selkeästi rajattua. Kaikkea työasemaympäristössä olevaa sisältöä ei kannata näyttää mobiilikäyttäjille. Esimerkiksi raskaiden graafisten käyttöliittymäelementtien siirtäminen 2g-verkon yli voi katvealueella olevalle mobiilikäyttäjälle olla todella turhauttava kokemus. Käyttäjät eivät halua monimutkaisia näkymiä sotkemaan mobiililaitteensa pientä näyttöä vaan vain sen sisällön, joka on tilanteen kannalta tehokasta, hyödyllistä ja välttämätöntä.

Mobile first -strategia on kustannustehokas ja kestävä ratkaisu

Mobile first -suunnittelustrategian mukaan menestyksekkäästi toteutettu verkkopalvelu tarjoaa käyttäjilleen oleellisimpiin asioihin keskittyvän, selkeän käyttöliittymän, joka mukautuu käytetyn laitteen ominaisuuksiin luonnollisen oloisesti. Palvelun sisältö on käyttäjän motivaation, kontekstin ja tarpeiden kanssa samassa linjassa. Käyttökokemusten laatu nousee, kun käyttäjät kokevat pääsevänsä heille juuri sillä hetkellä merkitykselliseen sisältöön käsiksi niin, ettei käyttöliittymä asetu heidän päämääriensä tielle.

Suunnitteluprosessin kannalta Mobile first -lähestymistapa auttaa suunnittelijoita ja kehittäjiä keskittymään verkkopalvelun kannalta oleellisimpiin asioihin. Käyttäjien tarpeisiin keskittyvä suunnittelu mobiililaitteen pienikokoisesta näytöstä alkaen auttaa pitämään projektin päämäärän koko ajan selkeänä. Tärkeimpien käyttötapausten ulkopuoliset ominaisuudet ja vaatimukset voidaan perustellusti jättää matalammalle prioriteetille, sillä niiden kokonaisvaikutus verkkopalvelun menestyksessä on marginaalista. Selkeämmät suuntaviivat suunnittelussa ja kehityksessä luonnollisesti voivat myös laskea kehityskuluja.

Mobile first -strategiaa mukaillen toteutetut verkkopalvelut ovat yksittäisiä sovelluksia varmempia ratkaisuja tulevaisuutta ajatellen. Kun markkinoille ilmestyy uusia laitteita, joilla verkkopalvelun käyttö on mahdollista, ei tällöin ole tarvetta tehdä erillistä sovellusta tai omaa versiota kyseistä laitetta tai alustaa varten. Palvelut saadaan myös kohdistettua laajalle käyttäjäkunnalle kustannustehokkaasti. Kustannustehokkuutta lisää myös se, että palvelun sisällönhallinta säilyy keskitettynä palvelua käyttävien laitteiden valikoimasta riippumatta.

Mobile first -strategia yleistyy lujaa, mutta on silti vain yksi monista vaihtoehdoista

Suunnittelustrategian valinnassa kannattaa pitää mielessä, että Mobile first on vain yksi monista vaihtoehdoista eikä kaikkia verkkopalveluja ole järkevää pakottaa samaan muottiin. Joissakin tapauksissa karsituille mobiiliversioille ei välttämättä ole tarvetta. Joskus palvelusta tarvitaan pelkästään hyvin minimaalinen, täysin erillinen mobiiliversio. Myös erillinen applikaatio voi usein olla perusteltu vaihtoehto. Sopiva lähestymistapa tulee aina valita palvelun ja käyttäjien tarpeiden ja vaatimusten mukaan.

Valitusta strategiasta riippumatta on selvää, että verkkopalvelujen on jollain tavalla otettava kantaa palvelua käyttävien erilaisten laitteiden lukumäärän kasvuun. Tähän monimuotoisuuteen avoimesti suhtautuva suunnittelustrategia on vielä tällä hetkellä verkkopalveluissa vahvasti positiivinen erottuvuustekijä, mutta tulevaisuudessa se tulee olemaan useimmille verkkopalveluille elinehto.

Digitoimisto Avaus on ottanut Sitefinityn tarjontaansa, ja hehkuttaa tuotetta varsin voimakkaasti. Vierityspalkin kysymyksiin vastasi Avauksen teknologiajohtaja Mikko Heilimo.

1) Miksi Avaus päätti ottaa tarjontaansa uuden julkaisujärjestelmätuotteen?

“Avaus ja Avaus Technology (entinen Uoma) on tehnyt verkkopalveluita isoille ja pienille firmoille sekä aikaisemmin myös julkisyhteisöille (mm. Suomi.fi) pitkälti yli kymmenen vuoden ajan. Olemme nähneet siis markkinamuutoksen, jossa ensin oli tärkeää omistaa jonkinlaiset verkkosivut ja nykyään suurin osa asiakkaista tekee verkkopalveluillaan jo isoa liiketoimintaa. Markkina muuttuu edelleen nopeasti asiakkaiden alta - erityisesti niillä jotka tekevät merkittävää liiketoimintaa verkossa. Tämä vaatii nopeampaa reagointia markkinan muutoksiin.

Äsken kuvaamani markkinamuutos vaatii asiakkaalta paljon tiiviimpää osallistumista palvelun ja sen sisällön tuottamiseen. Rakenteita tarvitsee muuttaa usein ja paljon. Meitä rupesi hatuttamaan kun perinteiset julkaisujärjestelmät olivat kyllä hienoja tuotteita, mutta käytännössä edelleen rakensimme asiakkaalle verkkopalveluja, joiden muuttaminen tarvitsi yleensä meidän koodaria roolissa tai toisessa. Se oli hidasta ja kallista! Asiakkaat alkoivat vaatia järjestelmiä, jotka toimivat helposti drag-and-drop käyttöliittymällä niin, että isojakin rakenteellisia muutoksia voidaan tehdä heidän oman henkilöstönsä toimesta (teknisen tai kaupallisen henkilön toimesta, riippuen muutoksesta).

Toinen merkittävä syy vaihtaa käyttämiämme “Enterprise CMS-järjestelmiä” oli tarve kehittää palveluihin paljon aikaisempaa enemmän räätälöityjä toiminnallisuuksia julkaisujärjestelmäalustan päälle. Julkaisujärjestelmätoimittaja, jolla ei ole muita tuotteita kuin julkaisujärjestelmä on erittäin heikoilla tässä kun ei pysty tarjoamaan meille välineitä rakentaa tehokkaasti omia moduuleja julkaisujärjestelmän päälle.”

2) Miksi ette tehneet “turvallista ratkaisua” ja ottaneet EPiServeriä tai Drupalia?

“Hyvä kysymys – teen työssäni paljon strategista teknogiakonsultointia ja minulta usein kysytään kyseisten julkaisujärjestelmien hyödyntämismahdollisuuksia. Viimeksi viime viikolla päädyin suosittelemaan asiakkaalle toista näistä järjestelmistä Sitefinityn sijaan, sillä kaikilla järjestelmillä on omia sopivia hankkeita.”

“EPiServer on hyvä julkaisujärjestelmä. Sen filosofia on kuitenkin hieman erilainen ja käytännössä palvelut rakennetaan sillä edelleen koodaamalla hyvin pitkälle ja valikoista voidaan määrittää vähemmän. EPiServeriin on saatavissa erillinen drag-and-drop-moduuli sivuston rakenteen muokkaamiseen, mutta moduuli pelkästään maksaa yhtä paljon kuin Sitefinity kokonaisuudessaan. Lisäksi moduuli ei ole yhtä kätevä käyttää kuin Sitefinityn perustoiminnallisuus. Palveluita on vain helpompi ja nopeampi rakentaa Sitefityn päälle konfiguroimalla valmista kuin rakentaa kaikki koodilla.

Perustuotteen hinnoittelu kaataa vaakakuppia vielä enemmän Sitefinyn suuntaan. EPiServerillä lisenssit maksavat noin 12 000-25 000 euroa kun Sitefinityllä yhden verkkopalvelun rakentaa 1500 euron lisenssikululla viidellä yhtäaikaisella käyttäjällä. Sitefinityyn saa noin 6000 euron hintaan EPiserverin yläpäätä vastaavat palvelut. Viimeisenä ja erittäin merkittävänä syynä on ollut EPiServerin huono pilvipalvelutuki Azureen. Sitefinity sen sijaan on erittäin helppo asentaa Azureen, johon asiakkaat haluavat sen yleensä kustannus- ja ylläpidettävyyssyistä asentaa. ”

“Drupalin erityinen vahvuus on lukuisat valmismoduulit, mutta kuten usein sanotaan, niin se on kehittäjien oma julkaisujärjestelmä, kun Sitefiny on loppukäyttäjien lähtökohdista suunniteltu julkaisujärjestelmä. Drupaliin kiistämättä on saatavissa enemmän valmismoduuleja, mutta me haluamme rakentaa palveluja joita asiakas voi oikeasti itse muokata. Drupal meni huimasti eteenpäin versiossa 7 käytettävyyden osalta kun mukaan otettiin käytettävyyssuunnittelijoita enemmän, mutta kaikki joille olemme Sitefinityä esitelleet huomaavat selvän eron käytettävyydessä edelleen. Rakenteen ja sivupohjien muokkaaminen Sitefityssä käy vain helpommin.”

>> Videoita Sitefinity-julkaisujärjestelmän käyttöliittymän toiminnasta.

“Lisäksi yksi merkittävä syy Drupalin välttämiseen on, että se ei mielestämme oikeasti kestä suuria muutoksia, joita meidän tarvitsee tehdä asiakkaiden prosesseja tukeaksemme. Sitefinityyn on helpompi räätälöidä uusia ominaisuuksia Telerikin muilla tuotteilla. Drupalin vahvuus muokattavuudessa valikoista on samalla sen heikkous – liiketoimintakäyttäjän on vaikea opetella itse tekemään muutoksia julkaisujärjestelmän asetuksiin kun jokainen moduuli tekee tuhat ja yksi asetusta jotka on paikoin kuvattu todella huonosti. Lisäksi meitä pelotti hieman Drupalista löydetyt tietoturva-aukot. Onneksi ne paikataan usein aika nopeasti, mutta pikapäivityksien yhteydessä on vaarana, että joku käyttämistämme lisämoduuleista lakkaa toimimasta samalla. On vaikea pystyä tukemaan uusia versiota, jos tietoturvapäivityksiä tulee liian usein.”

3) Minkälaisessa tilanteessa asiakkaiden pitäisi ehdottomasti tutustua Sitefinityyn?

“Mikäli asiakkaalla on tarkoitus rakentaa oikeasti merkittävää liiketoimintaa tuottava verkkopalvelu, joka elää paljon ja sitä aktiivisesti kehitetään analytiikkatiedon perusteella. Tällöin Sitefinityn muokkaantuvuus ja käytettävyys tulee oikeuksiinsa. Erityistä etua saadaan jos sisältöä ja sivuston hallintavastuuta on hajautettu organisaatiossa. Tällöin käytön pitää olla helppoa, sillä jokaisesta liiketoimintavastaavasta ei voida tehdä IT-päällikköä!”

4) Mikä tekee Sitefinitystä teidän kaltaisellenne digitoimistolle erityisen mahtavan?

“1.  Aivan omaa luokkaa oleva käytettävyys.

2. Telerikin tausta kehitystyökaluissa – helppo laajentaa niiden avulla.

3. Kustannustehokkuus – merkittävästi halvempi verrrattuna muihin saman luokan kaupallisiin julkaisujärjestelmiin.

4. Hyvät verkkokauppa- ja mobiilitoiminnallisuudet.

5. Aivan omaa luokkaa oleva tuotetuki (voittanut useita palkintoja) – saamme vastauksen ongelmiin 24h ja usein vastaus on koodinpätkä joka korjaa ongelman!”

5) Mihin suuntaan mielestäsi julkaisujärjestelmämarkkina on menossa? Alkavatko ominaisuudet jo kypsyä ja kilpailu menee yksityiskohtiin, vai onko markkina vielä “aivan sekaisin” hakien suuntaa ihan perustavanlaatuisista asioista? Perustele.

“Mielestäni alustoilla on jo perustoiminnallisuudet melko hyvät kaikissa – ei niissä ole oikeasti isoja eroja. Erot syntyvät prosesseissa joilla palveluja tehdään ja siinä miten pitkälle milläkin alustalla voi omaa liiketoimintaa viedä tehokkaasti. Julkaisujärjestelmävalmistajien keskuudessa varmasti syntyy pudotuspeliä seuraavien 10 vuoden aikana ja jäljelle jää muutamia elinvoimaisempia ekosysteemejä jotka ovat riittävän monipuolisia.

Julkaisujärjestelmät ovat jatkossa vain entistä merkittävimmässä roolissa kun analytiikkatietoa hyödynnetään palveluiden kehityksessä enemmän optimoimaan palvelun tavoitteita (lisätä myyntiä, lisätä yhteydenottoja, vähentää kuluja rutiineissa…). Palvelut eivät ole enää staattisia palveluja jotka rakennetaan kerran ja sitten käytetään X vuotta. Palveluita pitää kehittää jatkuvasti jotta ne pysyvät kilpailussa mukana ja hakukonenäkyvyys säilyy ja paranee. Google esimerkiksi rankkaa entistä enemmän tiedon tuoreuden perusteella palveluja – näin ollen asiakkailla on oltava malleja tuottaa sisältöä lähes päivittäin ja tehokkaasti.

Nopeamman palveluiden muokattavuuden lisäksi toinen trendi on kaupallistuminen palveluissa. Jokaiseen uuteen julkiseen verkkopalveluun tulee jotain verkkomyyntitoiminnallisuutta. Palveluiden rakentaminen on entistä kalliimpaa ja ’kivoja palveluja’ joilla ei ole riittävää kaupallista potentiaalia ei yksinkertaisesti enää rakenneta. Palveluiden elinkaaret lyhenevät, joten niiden on maksettava itsensä takaisin nopeammin. Tämä asettaa lisävaatimuksia alustan muokattavuudelle ja valmistoiminnallisuuksien ja lisämoduulien merkitys vain kasvaa. Tässä pelissä pärjäävät vain vahvimmat ekosysteemit.”

Sitefinityä puskevan Avauksen on tärkeätä uskoa omaan tuotteeseensa. Yleensä maailmalla suosiota saaneet julkaisujärjestelmät ovatkin joillain sektoreilla kilpailijoitaan parempia. Esimerkiksi Sitefinityssä on paljon elementtejä Dreamweaverin kaltaisista tehotyökaluista, jotka antavat aktiiviselle web-tiimille paljon valtaa oman verkkopalvelunsa muokkaamiseen.

Asiakkaiden kannalta vain harvoin on välttämätöntä löytää se “paras julkaisujärjestelmä”. Isompi huoli on digitoimistoilla löytää sopiva yhdistelmä helppokäyttöistä tuotetta ja räätälöintialustaa. Mitä täydellisempi yhdistelmä, niin sitä vähemmän asiakkaiden tarpeiden ja toiveiden kanssa tarvitsee olla vaikeuksissa.

Toisaalta on ihan relevanttia kysyä, että pitääkö julkaisujärjestelmän olla myös räätälöintialusta? IT-alan historia on täynnä tuskaisia tarinoita, joissa on yritetty yhdistää valmistuotteen ja räätälöintialustan lupaukset – eikä monista näistä hiljaisuudessa haudatuista projekteista ole ollut hyötyä kuin räätälöintityöstä laskuttamaan päässeelle integraattorille. Täten asiakkaiden näkökulmasta onkin syytä kuunnella tarkkaan kun IT-alan toimittajat lupailevat yhdistää nämä kaksi ääripäätä. Epäilemättä moni verkkopalvelu tarvitsee myös erityistoimintoja, räätälöityjä moduuleja ja isojakin erityiskokonaisuuksia, mutta julkaisujärjestelmät ovat kuitenkin ensisijaisesti tehty julkaisutoimintaa tukemaan – ei asiointipalveluiden ketteriksi alustoiksi.

Sitefinity tuskin on keksinyt hopealuotia tuotteen ja räätälöintialustan yhdistämiseen, mutta on silti kiinnostavaa nähdä, että uusia tuotteita puskee markkinoille. 

Ratkaisussa sovelletaan WordPress.com-blogialustaa, mutta teemapaketiksi valitaan tavalliselle yrityssivustolle soveltuva teemapohja. Täten ratkaisu on myös varsin kestävä, ja esimerkillinen monella tapaa. Raportin ohjeiden mukaisesti tehty esimerkkisivusto löytyy verkosta osoitteesta www.kolea.fi.

Aucor ei toki ole tässä alle sadan euron kustannussummassa huomioinut työkustannuksia, joita projektiin liittyy todennäköisesti useita tunteja. Kokonaissumma projektille ei kuitenkaan nouse tuhansiin euroihin, vaikka työlle tuntikustannukset laskisi.

Aucorille tästä tuskin syntyy liiketoimintaa, vaan kyse on ollut mielenkiintoisesta harjoituksesta. Dokumentin alussa onkin kuvaava disclaimer:

“Emme vastaa yhtään mistään tässä dokumentissa kirjoitetuista väitteistä, toimenpiteistä, seurauksista tai mahdollisesta mielipahasta. Emme tarjoa käyttötukea tai opastusta, muuta kuin erittäin kovaan tuntihintaan.”

Aucorin valitsema malli ei ole kuitenkaan sellainen, josta olettaisi asiakkaalle syntyvän tarpeita konsultoinnin ostamiseen. WordPress.com päivittyy automaattisesti ja tarjoaa näin hyvän alustan sivustolle myös jatkossa. Tietoturvapäivityksiä ei tarvitse ostaa erikseen digitoimistolta eikä Twitter-nosto rikkoudu Twitterin päivittäessä palveluaan.

WordPress.comin suora kilpailija tässä tapauksessa on esimerkiksi Kotisivukone. Kotisivukoneella pienyritys saa korkeampia kustannuksia vastaan sitten toki hieman laajemmat toiminnot ja parempaa asiakaspalvelua. Aucorin valitsema WordPress.com-malli soveltuukin ehkä parhaiten tee-se-itse-miehille, jotka haluavat pitää juoksevat kulut minimissä.

Tosin WordPress.com tarjoaa myös mahdollisuuden siirtyä omaan WordPress-asennukseen myöhemmin. Esimerkiksi Vierityspalkki-bloginkin tarina on alkanut WordPress.comista, josta palvelu on myöhemmin siirretty omalle palvelimelle kun blogiin on haluttu erityistoiminnallisuuksia (esim. avoimet työpaikat -palsta jonne ilmoitukset lähetetään räätälöidyn lomakkeen avulla).

WordPress.comia hyödyntävätkin jo verkkosivustojen alustana monet yritykset. Esimerkiksi kotimainen asiakaslehtibyroo Maggie aloitti WordPress.comin avulla verkkosivustonsa ja siirtyi myöhemmin omalle palvelimelle asennettuun ratkaisuun halutessaan monipuolisempaa analytiikkaa sivustosta. Sosiaalisen median käytössä konsultoiva Intosome Oy taas hyödyntää nykyisinkin WordPress.com-ratkaisua. Tosin jostain syystä Intosome ei ole liittänyt omaa domainia sivustoonsa, jota voi pitää hieman omituisena ratkaisuna.

WordPress.com on mielenkiintoinen palveluna ostettava verkkosivustoalusta, jota voi hyödyntää myös yksinkertaisten yrityssivustojen alustana. Mahdollisuus siirtyä myöhemmin omalle palvelimelle asennettavaan versioon tarjoaa myös esimerkillisen laajennuspolun. Voisikin sanoa, että harvoin laatu ja kustannustehokkuus yhdistyvät samassa paketissa siten kuten WordPress.comissa.

>> Lataa pdf-raportti Aucorin sivuilta.

Tässä katsaus kiinnostavimpiin finalisteihin. Tähän katsaukseen on poimittu ensisijaisesti kiinnostavia projekteja ja hyviä projektikuvauksia, ei niinkään välttämättä erikoisimpia konsepteja tai tuloksellisimpia palveluita.

Fonectan Caller -mobiilisovellus on mielenkiintoinen esimerkki siitä miten Fonecta on tunnistanut selkeän käyttötapauksen erillissovellukselle, ja sen jälkeen panostanut saman palvelun tuomiseen niin iPhonelle, Androidille kuin Symbianille. Alan toimistoista Palmu Inc. vastasi konseptoinnista ja käyttöliittymäsuunnittelusta.

Valio.fi -palvelun kuvaus esittelee tunnetun brändin merkittävän palvelu-uudistuksen käyttöliittymän ja keskeisten toimintojen näkökulmasta. Palvelun suunnittelussa keskeisessä roolissa on ollut digitoimisto Valve.

YleX.fi -palvelun uudistus on täysin YLEn omaa työtä, mutta projektia kiinnostavampi osa tarinassa on radion ja verkon yhteistoiminta. YleX:lle verkko on keskeinen palvelukanava, jonka kautta sisältöä jaetaan kuulijoille, mutta yhtä lailla sivusto on vuorovaikutuskanava kuulijoiden kanssa.

Oriolan projektitarina on hyvä kuvaus tuotevetoisen extranet-palvelun käyttäjälähtöisestä toteutuksesta. Projektitarinassa on myös havainnollisia käyttöliittymäkuvia hakuvetoisen verkkopalvelun toiminnasta. Myös tuotesivujen suunnitteluun on selkeästi panostettu. Toimistoista suunnitteluvastuussa oli Palmu Inc. ja extranet-palvelun teknisestä toteutuksesta vastasi AtBusiness.

Flow Festival näyttää mallia ison tapahtuman sivustosuunnittelussa. Responsiivinen toteutus mukautuu eri päätelaitteille, ja sivusto hyödyntää voimakkaasti suosituimpia sosiaalisen median palveluita tuomalla keskeisiä toiminnallisuuksia näiden sisälle. Oman festivaaliohjelman suunnittelu ja julkaiseminen Facebookissa on hyvä esimerkki todellisesta sosiaalisen median hyödyntämisestä eikä pelkästä “kevytintegraatiosta”. Suunnittelu- ja toteutusvastuuta projektin verkkopalvelussa mm. Byroo-digitoimistolla.

Mielenkiintoisesti Helsingin Juhlaviikot esittelee samankaltaisen tapahtuman varsin toisenlaista mallia. Juhlaviikkojen erillinen mobiilisivusto on projektitarinan kohteena, ja ilmeisen toimivana ratkaisuna tämäkin malli on koettu. Juhlaviikkojen kohderyhmä lienee ainakin ollut Flow Festivalin kävijöitä monipuolisempi, joten erillisen mobiilisivuston pelkistetty käytettävyys on saattanut olla keskeinen syy mallin valintaan. Mobiilisivuston suunnittelusta ja teknisestä toteutuksesta on vastannut toimisto nimeltä Taiste.

Sitra.fi -sivuston uudistus kertoo avoimesta ja ketterästä web-uudistuksesta, jossa toteutettiin responsiivinen verkkosivusto, jonka ympärillä oleva sosiaalisen median palvelukokonaisuus on myös mietitty. Suunnittelussa ja toteutuksessa Sitran kumppanina oli Deasign & Fröjd -tiimi.

Helsingin Sanomien iPad-sovelluksen projektihistoria tiivistää hyvin kuinka toimivan ja miellyttävän tablet-sovelluksen tekeminen vaatii jatkuvia panostuksia ja käyttäjien toiveiden herkkää kuuntelemista. Uudelle tekniselle alustalle palvelun kehittäminen on kaikkea muuta kuin projektiluonteinen operaatio. Teknisenä toteutuskumppanina HS:llä Marko Karppinen & Co.

Grand One -kilpailun huipentava gaala pidetään 22.3.2012, jolloin myös voittajat julkistetaan.

1) Milloin saitte idean, ja millaisen tiimin ja yhteistyötahot kasasitte?

“Idea palvelusta on syntynyt muutama vuosi sitten, mutta nykyisessä muodossaan siitä käytiin ensimmäiset keskustelut 2011 vuoden alussa. Ideaa hiottiin yhteistyössä usean paikallisen yritysneuvonnan kanssa ja samalla käytiin keskusteluita potentiaalisten tiimin jäsenien kanssa. Ensimmäisenä tiimiin liittyi kovan luokan ekonomi, jonka kanssa selvitimme palvelun toimintaan liittyviä haasteita. Myöhemmin, itse asiassa tasan vuosi sitten, tiimiimme kasvoi kahdella erittäin lahjakkaalla koodarilla, jotta voisimme toteuttaa palvelun kokonaan omin voimin. Allekirjoittanut täydentää ja johtaa tiimiä tietotekniikan, myynnin sekä markkinoinnin kokemuksella ja koulutuksella.”

2) Millä teknologioilla ja millaisin voimin saitin ensimmäisen versio nousi pystyyn?

“Palvelumme alustana toimii suorituskykyinen Yii Framework joka on kirjoitettu PHP5:llä ja tukee MVC-mallia. Tietokannaksi valitsimme PostgreSQL:n. Olemme pystyneet kehittämään palvelun alusta lähtien omin voimin koska tiimistämme löytyy vaadittava tietotaito ja omistautuminen projektiin.”

3) Kuinka paljon paloi ensimmäisen version tekemiseen aikaa ja rahaa?

“Aloitimme palvelun kehityksen keväällä 2011 ja alusta lähtien mottonamme on ollut “Helposti & Nopeasti”. Liian usein tällaisissa projekteissa huomaa ajan kuluvan hukkaan sellaisiin yksityiskohtiin ja ominaisuuksiin, jotka eivät lopputuloksen kannalta ole välttämättömiä. Vaikka olemmekin pyrkineet etenemään nopeasti, silti tärkeimpiä kriteereitä alusta asti on ollut tietoturva ja hyvien koodauskäytänteiden noudattaminen.

Arviomme mukaan käytimme noin 500 tuntia palvelun ensimmäisen version julkaisuun. Tähän on laskettu koodaustöiden lisäksi kaikki tekemämme selvitystyöt ja suunnittelut. Keskiverto 50 – 60 euron tuntipalkalla palvelun ensimmäiselle versiolle tulisi siis hintaa noin 25 000 – 30 000 euroa, jos emme olisi tehneet sitä itse. Kaikkiin perustamistoimiin oma tietämyksemme ei kuitenkaan riittänyt tarvittavan hyvin, joten palkkasimme käyttöömme lakimiehen päiväksi. Hänen kanssaan selvitimme lakiasioita liittyen meidän rooliin ja vastuisiin tällaisen palvelun ylläpitäjinä. Tätä varten saimme haettua EU:n tukemaa rahoitusta, jolloin vain pieni osa lakimiehen 1500e päiväpalkasta jäi meille maksettavaksi.”

4) Kuinka paljon laitatte aikaa ja rahaa nykyisin palvelun kehitykseen, kuinka paljon markkinointiin?

“Nykyisin käytämme palvelun kehittämiseen viikoittain noin 20 työtuntia. Lisäksi markkinointiin kuluu viikoittain noin 30 tuntia. Toiminta-ajatuksenamme on panostaa markkinointiin enemmän omaa aikaa kuin rahaa. Tutkimme säännöllisesti uusia mahdollisuuksia markkinoida palveluamme netin ja sosiaalisen median kautta, lisäksi kokeilemme uusia ideoita ennakkoluulottomasti. Palvelun kehityksessä joudumme jatkuvasti priorisoimaan mihin käytämme tunteja. Kehityslista palveluun tulevista uusista hienoista ominaisuuksista on pitkä ja kasvaa koko ajan käyttäjiemme palautteen myötä.”

5) Meneekö vielä aikaa ja rahaa johonkin muuhunkin? 

“Keskustelemme aktiivisesti freelance-yhteisön kanssa ja pyrimme sitä kautta jatkuvasti kehittämään palveluamme. Toimialalla on paljon väärinkäsityksiä liittyen palveluiden hinnoitteluun, sekä tilaajien että freelancerien puolella. Koemme olevamme sellaisessa asemassa, että pystymme tekemään tähän muutoksen, joten tutkimme jatkuvasti mahdollisuuksiamme vaikuttaa. Tavoitteenamme on parantaa yksittäisen freelancerin etuja ja parhaiten se onnistuu kun freelancerit pystyvät yhdistämään voimansa.

Jatkuvasti juoksevia kuluja on oikeastaan tullut mukaan vasta toiminnan virallistumisen myötä eli perustettaessa yritys toiminnan taustalle. Tämä tuo aina jonkin verran pakollisia yrittäjän kuluja mukanaan. Omaa nettisivuprojektia hautoville voisi tämän osalta sanoa vinkiksi sen, että kannattaa miettiä rakentaako projektia harrastepohjalta tai oman työn ohella vai onko toiminnalla tarkoitus tulla taloudellisesti toimeen. Lisäksi on syytä miettiä miten paljon on valmis uhraamaan aikaa ja rahaa ennen kuin projekti alkaa tuottamaan. Hyvällä idealla ja omalla työpanoksella toiminnan ylläpitämisen kulut pystyy melko hyvin hoitamaan, mutta on eri asia tuleeko ideasta tuottava ja toimiva vai pelkästään toimiva.”

Kommentit (Perttu Tolvanen): Pätkät.fi on hyvä esimerkki kohtuullisen paljon toiminnallisuutta sisältävästä verkkopalvelusta, joka on kuitenkin kehitetty varsin maltillisella työpanoksella. Karkea 30 000 euron kustannusarvio on hyvä vertailukohta vastaavantyyppistä verkkopalvelua suunnitteleville. Tosin tässäkin tapauksessa isommat panostukset ja haastavuus liittyvät palvelun markkinointiin ja jatkokehitykseen. 

Eero Rönkkö nostaa esiin myös tärkeän asian joka liittyy moniin fiksuihin verkkopalveluihin: Toimivan ja fiksun palvelun voi toteuttaa melko helposti kun on osaamista ja vähän näkemystä. Siitä tasosta ponnistaminen myös taloudellisesti kannattavaksi projektiksi onkin sitten ihan toisenlaisen puristuksen takana. 

>> Tutustu Pätkät.fi-sivustoon.