Julkaisujärjestelmä-käsitteellä tarkoitetaan tyypillisesti kevyttä tai keskiraskasta sisällönhallintajärjestelmää jolla hallitaan internet-, intranet- tai extranet-sivustoja. Suomessa tämä markkina on kehittynyt jo 2000-luvun alusta lähtien, mutta ei ole saavuttanut vielä minkäänlaista kypsyyttä tuotetasolla tai markkinakenttänä. Viime vuosina markkinakenttää on laajentanut myös avoimen lähdekoodin järjestelmien erittäin nopea kehittyminen. Tämä artikkeli antaa suppean katsauksen järjestelmätuotteiden ja järjestelmätoimittajien markkinakenttään Suomessa.
Julkaisujärjestelmä vai sisällönhallintajärjestelmä?
Alan kirjallisuudessa julkaisujärjestelmällä viitataan yleensä laajemman sisällönhallintajärjestelmän julkaisupainotteiseen osaan ja tähän osa-alueeseen liittyviin ominaisuuksiin. Kuvaus on osuva myös tuotteiden tasolla, koska merkittävä osa julkaisujärjestelmä-nimikkeellä markkinoitavista tuotteista on keskittynyt pelkästään tämän loppukäyttäjälle näkyvän pinnan hallintaan. Monien järjestelmien keskeisimmät ominaisuudet ovat wysiwyg-editori ja sen muotoilunappulat eikä tämän monipuolisempia ominaisuuksia ole saatavilla. Kehittyneempiä ominaisuuksia kuten räätälöitäviä työnkulkuja, monipuolista versionhallintaa tai erillistä sisältökokoelman hallintaa ei monestakaan tuotteesta löydy.
Lyhyesti voisi todeta, että mitä enemmän järjestelmässä on sisältöihin liittyviä hallintaominaisuuksia, niin sitä enemmän sitä voitaneen kutsua sisällönhallintajärjestelmäksi. Jos järjestelmän ominaisuudet muistuttavat vain hieman paranneltua versiota jostain kotisivujen päivitystyökalusta (kuten Kotisivukone tai Putteri), niin ollaan lähempänä julkaisujärjestelmätuotetta.
Mitä ongelmia julkaisujärjestelmä ratkaisee?
Tyypillisesti julkaisujärjestelmällä pyritään nopeuttamaan ja helpottamaan verkkopalveluiden sisällöntuotantoa ja erityisesti julkaisuprosessia. Yhden “webmasterin” mallista halutaan siirtyä hajautettuun sisällöntuotantoon ja sisältöjen muokkaus halutaan saada lähemmäksi sisältöjen tuottajia ja omistajia. Raskaamman sarjan web-sisällönhallintajärjestelmien hankintasyitä ovat mm. tiukempi brändinhallinta, hajautetun sisällöntuotannon tehostaminen ja johtaminen, monikielisten sisältöjen keskitetty hallinta, monipuoliset metatietojen hallintamahdollisuudet, laajan verkkopalvelukokonaisuuden hallinta ja johtaminen, monipuolisempien asiointipalveluiden mahdollistaminen.
Mitä ongelmia julkaisujärjestelmä ei ratkaise?
Käyttäjien näkökulmasta tärkeitä julkaisujärjestelmän ominaisuuksia ovat yleensä matala oppimiskynnys, helpot ajastukset ja mahdollisimman monipuoliset mahdollisuudet muokata verkkopalvelun rakenteita, sivuja ja ulkoasuja. Erityisesti jälkimmäinen kategoria, eli monipuoliset muokkausominaisuudet, ovat hankala asia julkaisujärjestelmätoimittajille. Sisällönhallinnan kanssa kun näillä vaatimuksilla ei ole paljoakaan tekemistä. Monen organisaation kannattaisikin vakavasti harkita, että olisiko järkevämpää investoida Photoshoppiin, Dreamweaveriin ja näiden ohjelmistojen koulutuskursseihin. Julkaisujärjestelmät eivät ole olemassa web-sivustojen rakentamiseen eivätkä sivustojen ulkoasun muokkaamiseen.
Toki jotkut julkaisujärjestelmät yrittävät olla web-pohjaisia Dreamweavereita, mutta ovat väistämättä vain hyvin huonoja ja hyvin kalliita korvikkeita.
Millaisia tarpeita varten julkaisujärjestelmät on suunniteltu?
Julkaisujärjestelmän todellinen tarve syntyy vasta kun aktiivisia ylläpitäjiä on useita ja verkkopalveluiden sisältö muuttuu erittäin usein. Selkeimpiä sisällönhallintajärjestelmän tarvitsijaorganisaatioita ovat esimerkiksi mediayhtiöt, verkkokaupat ja yritykset joiden tuotteisiin tai palveluihin liittyy paljon usein muuttuvaa tietoa. Myös esimerkiksi samojen tietojen ylläpitäminen monella kielellä on haaste johon usein halutaan keskitetty järjestelmä.
Millaiset julkaisujärjestelmät ovat parhaita?
Tuotepohjaiset sisällönhallintajärjestelmät ovat lähes poikkeuksetta rakennettu jotain tiettyä käyttötapausta palvelemaan. Täten järjestelmien arviointi tulisi aina perustaa omiin tarpeisiin ja sisältöihin. Mitään “parasta järjestelmää” ei ole olemassakaan vaikka sisällönhallintajärjestelmien ominaisuuksien listaaminen ja käsittely voikin olla kiehtovaa. Kaikki järjestelmät kehittyvät asiakkaiden ohjaamina ja täten kannattaa valintaprosessissa myös huomioida millaisia muita asiakkaita toimittajalla on. Tämä pätee erityisesti avoimen lähdekoodin järjestelmiin joiden ominaisuuksien kehitystä ohjaa käyttäjäyhteisö erittäin voimakkaasti.
Ostajan kannalta on myös tärkeää valita hyvä kumppani niin verkkopalveluiden ylläpitoon kuin julkaisujärjestelmän ylläpitoon. Pelkkää tuotetta ei yleensä kannata ostaa vaikka oma it-osasto olisikin olemassa. Web-kehitys ja web-sisällönhallintajärjestelmät vaativat erityisosaamista jota ei välttämättä kannata pitää talon sisällä. Avoimen lähdekoodin tuotteet menevät nopeasti eteenpäin, mutta vauhti ja määrä ei aina korvaa laatua tai tuen saatavuutta.
Suomalaisia keskisarjan ohjelmistoyrityksiä joilla oma julkaisujärjestelmätuote tai merkittävä edustus:
- Abako Media, oma tuote Stato
- Absolutions, oma tuote NEST
- Ambientia, oma tuote Ambientia Content Manager
- Avoltus, edustaa mm. eSceniciä
- Ch5 Finland, oma tuote Navigo
- Crasman, oma tuote Crasmanager
- e21 Solutions, oma tuote SOLU
- eMedia, edustaa mm. Ektron-tuotetta
- Innofactor, oma tuote Innofactor Prime
- Naviatech, oma tuote Navia
- Onesta (yhdistynyt Uomaan), edustaa Open Textin LiveLink-tuoteperhettä
- Optinet, oma tuote Optinet Directo
- Poutapilvi, oma tuote P4
- Really, oma tuote ToimiSait
- Sitefactory, oma tuote Site Update ja toteuttaa myös Sitecorella
- Sininen Meteoriitti, oma tuote Meteor
- Systems Garden, oma tuote NAS
- Tietotalo, oma tuote InfoWeb ja edustaa myös EpiServeriä
- Verkkoasema, oma tuote
- Wysiwyg, oma tuote eWriter
Lista on katsaus Suomen markkinaan ja kommenttiosiossa voi listaa jatkaa. Listasta on tarkoituksella rajattu pois pelkästään avoimen lähdekoodin tuotteita tarjoavat yritykset sekä esimerkiksi MOSS-tarjontaan erikoistuneet. Monet yllä olevat yritykset tarjoavat omien tuotteidensa lisäksi myös avoimen lähdekoodin tuotteita sekä erityisesti MOSSia. Lisäksi ylläolevia tuotteita edustavat toki monet muutkin toimijat, kuten esimerkiksi Verkkojulkaisut edustaa Navigoa.
Isommat toimijat, kuten TietoEnator, Logica, Digia tai Satama/Trainers’s House, tarjoavat useampia tuotteita riippuen asiakkaan tarpeista. Esimerkiksi TietoEnator tarjoaa erityisesti Documentumia. Toisaalta TietoEnator on myös hiljattain toimittanut Alma Medialle Fatwire-alustan. Isompien toimijoiden järjestelmätarjonta riippuukin paljon kysyjästä. Lähes kaikki suuret tarjoavat myös MOSS 2007 -alustaa, joten MOSSista kiinnostuneet pääsevät ainakin vertailemaan. Moni tarjoaa oman tuotteensa lisäksi myös MOSSia, esimerkiksi Fujitsu. Myös avoimen lähdekoodin järjestelmiä löytyy isoilta toimijoilta ja näitä jopa tarjotaan asiakkaille oma-aloitteisesti. Esimerkiksi LifeRay-portaalialusta on keskeinen osa Logican sisällönhallintatarjontaa.
Avoimen lähdekoodin tuotteista ja teknologioista web-sisällönhallintaan voisi kirjoittaa ihan oman katsauksensa ja näillä onkin nykyisin yhä isompi rooli markkinakentässä. Avoimen lähdekoodin järjestelmistä mahdollisesti muodikkain on tällä hetkellä Drupal. Joomla on vahva kirittäjä tällä hetkellä. Kummallekin löytyy laajasti osaajia ja kummankin on moni it-osasto hyväksynyt omaan järjestelmävalikoimaansa. Mahdollisesti kaikkein raskaimman sarjan tuote lienee avoimen lähdekoodin sarjassa kuitenkin Plone (ainakin CMS Watchin mukaan). Plonen ainoana merkittävänä käyttäjänä Suomessa on tiettävästi kuitenkin vain Jyväskylän yliopisto. Muita avoimen lähdekoodin tuotteita ovat esimerkiksi Alfresco, Nuxeo, Typo3, TextPattern ja DotNetNuke. Osaa näistä käytetään laajastikin Suomessa. Esimerkiksi 2ndheadin NFO2-järjestelmä perustui DotNetNukeen. Nykyisin DotNetNukea tarjoaa Logican lisäksi esimerkiksi Avenla. Kaikille edellä mainituille järjestelmille löytyy Suomesta tukea, mutta erot osaajien määrässä ovat merkittäviä ja sitä on vaikea sanoa, että mikä avoimen lähdekoodin järjestelmä on muodissa kahden vuoden päästä.
Avoimen lähdekoodin järjestelmiä markkinoidaan usein erityisesti laajalla tuen saatavuudella, mutta myös esimerkiksi Microsoftin teknologioihin nojaavat MOSS, EpiServer, DotNetNuke ym. omaavat Suomessa varsin laajan osaajapohjan. Avoimen ja suljetun koodin välinen raja-aita ei julkaisujärjestelmien kohdalla enää olekaan kovin korkea. Isommatkin toimijat kasailevat kokonaispaketteja yhdistellen joustavasti suljettua ja avointa koodia. Lisäksi monet “tuotteet” ovat alalla vain uudelleenbrändättyjä kokoelmia avoimen lähdekoodin komponenteista. Tämä ei tietysti ole huono asia, mutta asettaa esimerkiksi lisenssiehdot tarkemman tarkastelun alle.
Ylipäätään julkaisujärjestelmämarkkina on kovin epäkypsä ja edellyttää ostajalta paljon tietoa omien sisältöjen vaatimuksista ja ymmärrystä niistä ominaisuuksista mitä järjestelmältään edellyttää. Omalle organisaatiolle hyvin istuvan järjestelmän löytämiseksi kannattaa tehdä ensin kotiläksyt ja sitten tutkia avoimesti markkinaa. Hyvään lopputulokseen voi päästä montaa reittiä – huonoon sitäkin helpommin.
—
Aiheeseen liittyvät artikkelit Vierityspalkissa vuonna 2008:
- Naviatech hylkää oman järjestelmän ja valitsee eZ Publishin? (4.8.2008) / Perttu Tolvanen
- Kotisivukone hyrrää pian kunnallisvaalisivujen alla (12.8.2008) / Tuija Aalto
- Puolueet, ehdokkaat ja julkaisujärjestelmät (26.10.2008) / Perttu Tolvanen
- Mitä julkaisujärjestelmältä tulee vaatia parhaan hakukonenäkyvyyden saamiseksi? (17.11.2008) / Perttu Tolvanen
- Naviatech vaihtoi eZ Publish -sisällönhallintajärjestelmään (7.12.2008) / Perttu Tolvanen
Useimmat julkaisujärjestelmät ovat riittävän monipuolisia yksinkertaisen verkkosivuston ylläpitoon, jossa lähinnä päivitetään olemassa olevien sivujen sisältöä tai lisätään uutisia.
Kun tavoitteena on verkkopalvelu, joka on oleellinen osa yrityksen liiketoimintaa, niin kannattaa valita julkaisualusta (ja toimittaja) huolella. Ymmärtääkö toimittaja asiakkaan todelliset tarpeet ja tavoitteet? Eihän järjestelmä aseta rajoituksia ulkoasun suhteen? Onnistuuko verkkosivuston jatkokehitys miten helposti? Miten omien sovellusten räätälöinti? Entäs Flash, AJAX, GoogleMaps, YouTube…?
Ja kannattaa tietysti varmistaa, että julkaisujärjestelmä tuottaa hakukoneystävällisiä www-sivuja!
Reallyn julkaisujärjestelmä ToimiSait jäi listalta pois…
Hei Sara. Kiitos täydennyksestä.
Minun näkökulmani onkin juuri se, että ns. perustarpeisiin riittää hyvin kevyt työkalu, kuten Kotisivukone tai jokin avoimen koodin tuote joka on kevyempi kuin listalla mainitut (vaikkapa WordPress, vaikka sekään ei mikään kevyt tuote ole). Listalla mainitut ovat tuotteita jotka taipuvat vähän monipuolisempiinkin juttuihin, eli juttuihin jotka tuottavat jotain kilpailuetua, eli ovat muutakin kuin yritysesittely, pari sivua palveluista ja uutisia.
Olen täysin samaa mieltä, että sitten kun haetaan noita asioita joita luettelit, niin järjestelmävalintaan kannattaa panostaa ihan eri tavalla.
Really ja Toimisait on nyt listalla. Kannattaisi muuten linkittää Reallyn saitilta tuohon Toimisaitin sivustoon. Oletin, että koko järjestelmä on kuopattu nimenvaihdoksenne myötä. Tästä syystä ei ollut alkuperäisellä listalla.
Hei,
Listalta puuttuu yrityksemme SiteDesk-julkaisujärjestelmä.
Olisiko mahdollista lisätä?
Hei Joose. Listalta puuttuu myös noin 200-800 muuta julkaisujärjestelmää joita tarjotaan eri puolilla Suomea. Ehdotuksia listalle voi laittaa juuri näin, eli kommentoimalla tähän ketjuun (artikkeli voi saada jatkoa myöhemmin, jolloin muitakin mainitaan sitten). Artikkelin listalle on valittu melko vakiintuneita ja tunnettuja toimijoita alalta ketkä myös aktiivisesti markkinoivat omia järjestelmiään ja ovat saaneet jo merkittäviä referenssiasiakkaita.
Julkaisu Järjestelmiä ei ole oikeasti olemassakaan. Tyypit jotka tekevät tai käyttävät Julkaisu Järjestelmiä, voisivat mennä autokaupan sijaan peltihevoskauppaan. Historiallista taustaa kai lienee syytä selvittää, koska nimityskin on aika antiikkinen.
Kyseinen ohjelmistogenre sai nimensä Uus Median kolmannen aallon aikaan lähinnä siksi, että Media Teollisuudessa harrastettiin usein Julkaisu Toimintaa. Ja koska silloin vielä ei ymmärretty, mikä Uus Median todellinen lupaus on – ei, se ei ole perinteinen broadcast- ja julkaisumaailman prosessien digitalisoiminen, keikka tuli kustua.
Vähän näkemystä, pliis. Vai onks Suomen Uus Media Skene tosiaan näin helvetin pihalla?
Hei!
Listalta puuttuu myös meidän yrityksemme julkaisujärjestelmä Synergia Foxy. Olisiko tuo mahdollista lisätä listalle?
Helsingin seurakuntien interaktiivisempi sivusto toimii Zope/Plonella (tosin kauppanimellä PrimaControl).
Uusin Liferay 5.0 hakkaa MOSSin mennen tullen. Liferay vaikuttaa designerin näkökulmasta kiintoisammalta (teemat saa kohtuu hyvin ojennukseen yms. ). Pari projektia on tullut tehtyä MOSSilla, ja siihen en enää mielelläni koske.
Hieman yllättynyt olen ettei mm. Teknillisen korkeakoulun, Luottokunnan, Amerin ja STT:n käyttämä avoin julkaisujärjestelmä Midgard (www.midgard-project.org) ole listalla.
Sitä suomessa toimittavat ainakin Nemein ja Protie.
Johtuu siitä, että avoimen lähdekoodin järjestelmistä tulee erillinen lista joka kyllä linkitetään sitten tähän artikkeliin. Midgard tullaan huomioimaan siinä artikkelissa.
Protie ei ollutkaan tuttu. Noita avoimen lähdekoodin järjestelmiä toimittavia yrityksiä on tässä maassa n+1, joten sitä listaa ei varmasti pääse kuin raapaisemaan yhdessä artikkelissa.
Listalta puuttuu myös surfAce:n wedit joka on hyvin laaja kokonaisuus ja käytettävyydeltään huippuluokkaa. Wedittiin on liitettävissä lähestulkoon mitä materiaalia tahansa flashistä ulkoisiin lähteisiin kuten YouTubeen Sekä myös ulkoisia CRM järjestelmiä. Kehitystyötä tehty yli 6 vuotta ja päämääränä on ollut kehittää erittäin helppokäyttöinen ja luotettava järjestelmä asiakkaiden korkean vaatimustason takia.
[...] voi todeta, että kärkikaksikko oli aivan omilla luvuillaan muihin artikkeleihin verrattuna. Julkaisujärjestelmät ja 2ndhead kiinnostivat selvästi eniten alkuvuonna [...]
Superhyvä että tämä artikkeli nousi listauksessa uudelleen esiin, on jostakin syystä mennyt minulta täysin ohi ja oli ansiokas tiivistys aiheesta.
Monen julkisen ja yksityisen organisaation (laajan tieto- ja viestintäpainotteisen) sivuston sisällönhallintatarpeet nähtyäni minua välillä ihmetyttää se ettei sisällönhallintajärjestelmiä ole tuotteistettu nykyistä pidemmälle. Vaatimusten setti kun tuntuu olevan aika vakioinen:
1) Matala oppimiskynnys joka artikkelissa mainittiinkin. Hajautetussa sisällöntuotannossa ylläpitäjät tekevät päivityshommia usein esim. kerran kuussa, jolloin ylläpitojärjestelmän on pakko olla intuitiivinen. Muussa tapauksessa sisällön laatu ja ajantasaisuus alkaa kärsiä siitä, että ylläpito tuntuu hankalalta ja siihen on vaikea tarttua.
2) Hyvät luokittelu- tai tägäysominaisuudet, joiden perusteella erityyppisiä sisältöjä pystytään automaattisesti linkittämään toisiinsa palvelun sisällä. Nyt järkevää sinänsä halutaan että kun olet löytänyt palvelusta yhden tietyn aiheeseen liittyvän sisällön, löydät myös muut.
3) Kuvankäsittelyn perustoiminnallisuudet. Kaikki haluaisivat lisää kuvia palvelunsa sisältöihin mutta niiden rajaaminen ja pienentäminen sopiviksi on yllättävän iso organisatorinen osaamiskynnys. Niinpä julkaisujärjestelmän toivottaisiin poistavan tämä kynnys.
4) Muistutus- ja hyväksymistyönkulut. Ihmiset eivät muista päivittää otona vastuulleen kuuluvia sisältöjä ellei joku siitä heitä muistuta, ja substanssiasiantuntija ei voi olla verkkokirjoittamisen ammattilainen.
5) Hyvä löydettävyys (hakukoneilla) saavutettavuus mobiiliselaimilla ja erityisryhmien käyttäjille. Tämä siis julkaisujärjestelmän tuottaman tavaran ominaisuutena.
Tuntuu siis että tämä perussetti löytyy joka ikisen organisaation julkisen verkkopalveluin vaatimusmäärittelystä, ja siitä huolimatta näitä vaatimuksia tunnutaan ratkovan jokaisen toimittajan kanssa ihan erityislaatuisina ongelmina. Se tuntuu rahan ja vaivan haaskaukselta.
Itse näiden järjestelmien kanssa päivittäin työskentelevänä on pakko todeta, että ihan asiaa puhut. Paljon on vielä tehtävää kehityksessä.
Itse näen nykytilanteelle kaksi (2) keskeistä aiheuttajaa: 1) Internetin nopea kehitysvauhti ja 2) Sisällönhallintajärjestelmämarkkinan suhteellisen nuori ikä.
Vaikka siis haasteet ovat olleet jo varsin pitkään, niin julkaisujärjestelmien kehittäminen ei ole kuitenkaan ollut mikään iso alue kovin pitkään vielä. Pioneereja lukuun ottamatta voi sanoa, että järjestelmien kehitys on alkanut vasta uusmediakuplan puhkeamisen jälkeen. Ja vasta nyt on alkanut taas asiakkailla olla rahaa laittaa verkkoon uudestaan. Ei viidessä-kuudessa vuodessa vielä viedä kokonaista markkinaa kovin pitkälle. Monet tällä hetkellä vahvat julkaisujärjestelmät on saatettu laittaa alulle 2004 tai 2005. Täten ne eivät ole vielä edes murrosiässä (esim. tällä hetkellä kovin trendikäs Drupal).
Internet myös menee eteenpäin niin kovaa vauhtia, että “hyvien ratkaisujen” tekeminen webin ongelmiin on yllättävän vaikeata ja työlästä. Tästä hyvänä esimerkkinä käy vaikkapa wysiwyg-editorien tilanne. Edes kuusinumeroisia summia maksavat sisällönhallintajärjestelmät eivät yleensä pysty tarjoamaan sellaista wysiwyg-editoria johon viestintäosasto olisi tyytyväinen. Ja kyse ei ole halusta, vaan kyse on siitä että ongelma on varsin haastava. Web menee eteenpäin niin hurjaa vauhtia eikä standardoitumisesta ole tietoakaan. Järjestelmäkehityksen tekeminen tällaisessa ympäristössä on sitä kuuluisaa lentokoneen rakentamista kun lentokone on jo päätetty ottaa reittiliikennekäyttöön.
Mielelläni myös kommentoin hieman tarkemmin noita esittämiäsi vaatimuksia:
#1 Olen samaa mieltä, että moni järjestelmä on varsin hankala käyttää sellaiselle joka käyttää kerran kuukaudessa. Muutamissa kalliimmissa järjestelmissä on jo erillisiä käyttöliittymiä tällaisille sisällön muokkaajille. Järkevämpi vaihtoehto on kuitenkin usein tehdä vaikkapa videotutoriaali näille henkilöille jonka he voivat vilkaista muistinvirkistykseksi ennenkuin ryhtyvät hommiin. Kaikkea ei pidä vaatia järjestelmältä (eikä kannata).
Useimmat järjestelmät on optimoitu käyttäjille jotka käyttävät järjestelmää edes kerran viikossa. Web-julkaisu vaatii osaamista ja ymmärrystä sen verran, että jos käyttää kerran kuukaudessa niin silloin unohtaa jo paljon muutakin. Tämä tuskin tulee siis muuttumaan lähivuosina. Kerran kuukaudessa käyttäviä tyyppejä ei vain yksinkertaisesti _kannata_ lähteä tukemaan.
#2 Luokittelu ja tägäys löytyy jo monesta järjestelmästä. Luokittelu ja tägääminen ei vain ole oikeastaan ollenkaan tekninen haaste vaan pääosin suunnitteluhaaste. Eri organisaatiot haluavat niin erilaisia juttuja. Tähän ei todellisuudessa ole mitään ‘out-of-the-box’ toiminnallisuutta vaikka monet toimittajat niin sanovatkin. Joku konsultti sitä metatietomääritystä tekemään pitää kuitenkin palkata (ennen tai jälkeen järjestelmän käyttöönoton…), koska se on paljon isompi juttu kuin yleensä ymmärretään.
Tässä kohtaa toivoisi oikeastaan, että asiakkaat ymmärtäisivät paremmin kuinka isosta asiasta on metatietomäärittelyjen kohdalla kyse.
On suoraan upeata, että vaativia juttuja osataan vaatia, mutta pitää olla myös realistinen. Olen itsekin kuullut usein vaatimuksen: “Haluamme, että meidän webbisivumme tekevät kuten Google/amazon: “tarkoititko kenties tätä….” tai “kävijät jotka katsoivat tätä sivua katsoivat myös tätä…” – tarjoaahan järjestelmänne tämän ominaisuuden valmiina?”.
Google ja Amazon ovat ehkä kumpikin laittaneet muutaman sata miljoonaa euroa siihen, että ovat saaneet nuo ominaisuudet toimimaan edes jokseenkin järkevästi. Vaatimukset kannattaa suhteuttaa budjettiin ja jos ei tiedä mitä jokin maksaa niin kannattaa kysyä.
#3 Kuvankäsittelyominaisuuksia kohtaan olen varsin kriittinen vaikka ymmärränkin sen tuomat edut. Monesti parempi ratkaisu on tehdä viestintäosaston toimesta hyvä kuvakirjasto jonka kuvat ovat jo valmiiksi oikeassa koossa. Tämä on ainut tapa millä brändin visuaalinen ilme oikeasti hallitaan.
Sitten jos puhutaan vaikka intrasta tai jostain yhteisöstä jossa esimerkiksi moni työntekijä pitää blogia, niin sitten ymmärrän kyllä vaatimuksen. Mutta ei kannata olettaa, että tämä olisi jotenkin “perusominaisuus”. Sitä se ei todellakaan ole. Esimerkiksi WordPress sai tämän ominaisuuden vasta hiljattain ja tässäkin se on erittäin kankea ominaisuus. Sellaista “viestintäosaston haluamaa” ominaisuuspalettia en ole edes vielä nähnyt vaikka esim. Microsoft Sharepoint + Microsoft Word pääseekin aika lähelle (eli kuvan voi vaikka raahata sisään ja säätää kohdalleen Wordissa ja kun painaa “Julkaise” niin järjestelmä hoitaa skaalaukset ja tallennukset ym).
Ylipäätään koko kuvien hallinta on 90% koulutukseen ja ohjeistukseen liittyvä haaste. Vaikka järjestelmä olisi kuinka hieno, niin sisällöntuottaja todennäköisesti voi “sotkea kaiken” silti. Ei siis kannata odottaa, että tämäkään ongelma ratkeaisi lähivuosina julkaisujärjestelmien toimesta.
Teknistä ratkaisua odotellessa voi kuitenkin hankkia ne Photoshop Elementsit henkilökunnalle, pitää päivän koulutuksen kuvamateriaalien tuottamisesta ja toimittaa vielä pikaohjeet vaikka videotutoriaaleina jengille. Aivan varmasti paljon halvempaa ja tehokkaampaa kuin pyytää kuvankäsittelyohjelmaa lisättäväksi omaan julkaisujärjestelmään.
#4 Työnkulkuominaisuudet täytyy löytyä jokaisesta järjestelmästä joka kutsuu itseään julkaisujärjestelmäksi tai sisällönhallintajärjestelmäksi. Jos ei löydy, niin kyseessä on ‘webbisivujen päivitystyökalu’.
Näiden määrittelyyn kannattaa toki varata aikaa. Eri organisaatiot vaativat kovin erilaisia asioita myös työnkuluilta ja hälytyksiltä.
#5 Hyvä löydettävyys on sellainen jossa on pakko olla kanssasi täysin samaa mieltä. Julkaisujärjestelmien kehittäjät ovat nukkuneet tämän osalta pommiin ja pahasti. Niin moni julkaisujärjestelmä vieläkin vaikeuttaa löydettävyyttä ja käyttää ratkaisuja jotka ovat täysin soveltumattomia moderniin verkkopalveluun. Onneksi muutos on tapahtumassa varsin nopeasti, koska tätä osataan jo vaatia.
Yhteenvetona: Olen kanssasi varsin samaa mieltä siitä, että on paljon ominaisuuksia ja toimintoja jotka olisi kätevää olla julkaisujärjestelmissä. Myös tuotekehityksen puolella olleena henkilönä on todettava kuitenkin, että ei kannata odottaa ihmeitä vielä lähivuosina. Markkina on kovin epäkypsä ja moni ongelma on paljon enemmän koulutukseen ja ohjeistukseen liittyvä kuin teknologinen ongelma.
Vaikka järjestelmä osaisi mitä, niin moni ongelma jäisi silti.
Juu, helppo kompata noita ajatuksia. Kommentoin vielä paria kohtaa:
#1 Tässä ongelmana on, että kerran kuukaudessa päivittävät muodostavat monessa kohtaa sen sisältöjen ajantasaisuuden kriittisen massan, siis että organisaation toiminnot eivät yksinkertaisesti tuota tätä useammin sisältöjä. Niinpä on keksittävä jokin keino siihen, että ylläpitäminen tuntisi heistä vaivattomalta (jotta he tekisivät sitä aina tarvittaessa). Ehkä tosiaan ratkaisuna voisi olla videotutoriaali, ja ehkä lisäksi joku helpdesk-tyyppinen resurssi jonka tehtävistä pääosan muodostaisi sisällöntuottajien tukeminen.
#2 Aamen :)
#3 Täsmälleen samaa mieltä siitä että haaste liittyy eniten koulutukseen. Mutta _olishan se kiva_ jos tähän pystyttäisiin vastaamaan sisällönhallintajärjesetelmällä :) Mutta esim. laatuongelmia ei voisi tietenkään julkaisujärjestelmällä ratkaistakaan, tarvittaisiin vähintään hyväksymistyönkulkuja siihen että kuvat saataisiin pidetyksi järkevässä kuosissa.
Kiitos hyvästä keskustelusta!
[...] elokuu 2008 PerttuT Julkaisujärjestelmien markkinakatsauksessakin mainittu, suomalainen Naviatech, on ilmestynyt kaikessa hiljaisuudessa norjalaisen eZ Publish [...]
WordPress. Parempaa ei ole!
“Teknistä ratkaisua odotellessa voi kuitenkin hankkia ne Photoshop Elementsit henkilökunnalle, pitää päivän koulutuksen kuvamateriaalien tuottamisesta ja toimittaa vielä pikaohjeet vaikka videotutoriaaleina jengille. Aivan varmasti paljon halvempaa ja tehokkaampaa kuin pyytää kuvankäsittelyohjelmaa lisättäväksi omaan julkaisujärjestelmään.”
Koulutusta ja koulutusta… Kerran osallistuin talon johdon hankkimaan ja konsultin vetämään koulutukseen, jonka aiheena oli kuvien purku digikameran flash-kortilta sisältäen mm. exif-tietojen muuttaamisen.
Kaikki eivät tuota oppineet. Valitettavasti kameran käyttöä ei opetettu – saati kuvausta. Edellisestä johtuen taittajat, jotka sitten purkivat kuvat kortilta, saivat ruudulleen yhden megapikselin kameran pienimmällä resolla otetuja kuvia, joista olisi tullut aikakauslehteen sellainen yhden palstan kuva vähän fotarissa rääkkäämällä.
Voitte kuvitella, millainen urakka kuvankäsittelyn opettaminen olisi tuolta hyvin tavalliselta pohjalta. RGB:t, jpg:t, terävöinnit, resoluutiot, kirkkaus, kontrasti, rajaus, pakkaussuhde ja kuvan tiedostokoko – siis aivan perusasiat pitäisi selittää kullekin kädestä pitäen. Ja kerrata päälle.
Parempi – oikeastaan välttämätöntä – on, että julkaisujärjestelmässä on muutama kuvankäsittelytoiminto, joilla kuvan kokoa voi muuttaa, kuvaa voi rajata ja säätää kirkkautta. Enempi on ihan liikaa. Tai jos on se neljäskin toiminto, sen voi hyvin disabloida tai muuten täytyy ainakin viidesti kerrata ja lohduttaa, että älä koske siihen, jos tunnet itsesi epävarmaksi, olet nukkunut huonosti tai riidellyt puolisosi kanssa: “Kuva on ok muutenkin noilla kolmella nappulalla, muistathan sinä ne, muistathan?”
Ja vinkki: jos olet toimittaja, opettele nuo fotariasiat mutta ÄLÄ KOSKAAN kerro muille, mitä osaat. ÄLÄ TUHOA SILLÄ URAASI! Toimituksissa on näet sellainen henki varsinkin esimiesportaassa, että jos joku on niin selväjärkinen, että osaa vaikka purkaa kuvan kameran kortilta manuaalia lukemalla, hän on “nörtti”.
Kohta “nörtiltä” kysytään yhtä ja toista. Koska hän on avuliaana vastaamassa, hänen luullaankin olevan kiinnostuneen tekniikasta: “Ei se muusta ainakaan mulle puhu, määh! Ja siitä ei ole kuin pieni kukonaskel, yksi naksahdus ultrabimbon päällikön päässä, siihen luuloon, että olet niin tekniikkaorientoitunut, että oletkos toimittaja ollenkaan, joku insinööri tai muu ei-humanisti. Heterokin saatat olla…
Muista siis näytellä avutonta ja kysy tyhmiä, jos sellainen kompastuskivi kuin fotarikurssi sattuu eteesi. Pelastin juuri urasi.
Omani on manuaalinlukutaidon turmiollisesta vaikutuksesta kovasti vaakalaudalla. Ja kukaan muu ei inhoa tekniikkaa ja säätämistä niin paljon kuin minä. Silti otsaani ollaan tarjoamassa “nörtin” leimaa. Siis jo vanhenemassa olevalle toimittajanjäärälle, joka talossa ainoana saa juttunsa isoon julkisuuteen kerta toisensa jälkeen ja jota valtamedia seuraa sekä lainaa ainakin useahkosti. Vituttaa.
[...] ymmärtämättä teknologiaa ja sitomatta asiakkaita itseensä ylläpitosopimuksilla. Myös kaikkia julkaisujärjestelmätuotteita voidaan varmasti pitää HammerKitin kilpailijoina, vaikka HammerKitin lähestymistapa onkin jonkin [...]