Mikä on Adobe Fireworks

Adobe Fireworks julkaistiin vuonna 1998 Macromedia tuoteperheeseen (mm. Flash, Dreamweaver ja Freehand) verkkografiikan luontiin. Fireworks on pikseligrafiikan ja vektorimuotojen ainutlaatuinen hybridi; vektorit visualisoidaan reaaliajassa suoraan pikseleinä. Pohjimmiltaan Fireworks on vektorityökalu, jonka tasohierarkiassa rasteroitu kuvagrafiikka ja polkumuotoiset vektorit ovat sulassa sovussa omina layereinaan.

Yleinen työnkulku verkkosivustojen ulkoasujen luonnissa tapahtuu Photoshopin ja Illustratorin kesken. PS ja AI kehitettiin jo ennen internetin valtavirtaistumista ja molempien työkalujen yhteensopivuus ruudulle suunniteltavan grafiikan kanssa on enemmänkin sovellettua kun vastaavasti Fireworks on kehitetty nimenomaan verkkografiikan ympärille. Printtimateriaalin työstöä Fireworksilla ei kannata edes miettiä, sillä 300dpi ja CMYK ovat myrkkyä Fireworksille.

Fireworksin ydinalueita ovat verkkografiikan (leiskaaminen, ikonit, bannerit) lisäksi vahvasti myös käyttöliittymäsuunnittelu (Wireframes, UI-prototyping) sekä verkkosivujen teknisen totetuksen tarvittavat viipalointi ja optimointi (Slicing, Export).

Fireworksin toimintaperiaate

Fireworks on objektipohjainen työkalu, jossa jokainen dokumentissa esiintyvä elementti löytyy myös Photoshopin tapaan Layers-paneelista. Erona on lähinnä nimeämiskäytäntö, Photoshopin termit Folders ja Layers tottelevat Fireworksissa nimiä Layers ja objects.

Properties Panel

Fireworksin ydin on Properties Panel. Kun käyttäjä valitsee ruudulta tai Layers-paneelista objektin, Properties Panel (PI) muuttaa näkymänsä vastaamaan kyseisen objektin ominaisuuksia. Vastaava paneeli löytyy myös Flashista ja Dreamweaverista.

Valittu elementti voi olla tekstiä, valokuva, vektoripolku, Group, symboli, maski tms. Shift-pohjassa voi valita monta objektia, jolloin PI näyttää yhteenvedon valituista objekteista. Vaikka elementtien parametrit vaihtelevat yksilöllisesti, PI näyttää aina valitun elementin koordinaatit dokumentissa, leveys/korkeus-tiedot pikseleinä sekä mahdolliset tehosteet (Filters).

Tools Panel

Yhtenäinen elementti muiden Adobe ohjelmien kanssa Layers-paneelin lisäksi on Työkalu-paneeli. Fireworksin työkalupaneelista löytyvät välineet rasteroidun bitmap-grafiikan, vektorimuotojen, tekstin muokkaamiseen sekä webbileiskan pilkkomistyökalut.

Fireworksin työkalut ovat yksinkertaisia, mutta tekevät tehtävänsä omassa lajissaan. Vakavempaan kuvankäsittelyyn sopii ehdottomasti Photoshop ja haastavaan kuvitukseen soveltuu Illustrator, mutta Fireworks kykenee myös selviytymään molemmista tehtävistä kunnialla.

Tuttua ja tuntematonta

Fireworks pystyy tallentamaan ja lataamaan tuttuja PSD ja AI tiedostomuotoja. Fireworksin oma tallennusformaatti on PNG, joka voi aiheuttaa hämmennystä; Macromedian insinöörit keksivät ujuttaa PNG-tiedostomuotoon lisää metatietoja , sisältäen kaikki layerit, objektit yms. dokumentista löytyvän datan. Fireworksin PNG-lähdetiedostoja voi katsastella millä tahansa kuvaformaatteja toistavalla ohjelmalla, kuten esim webbiselaimessa.

Symbolit

Fireworks ei tue Smart Objecteja, mutta tarjoa tilalle Indesignista ja Flashista tutut Symbolit. Verkkosivulla toistuvien elementtien käyttöön tarkoitettu Symbolit antavat mahdollisuuden luoda nopeasti vaikkapa rautalankamallin sivustosta. Symboliin tehdyt ulkoasu-muutokset päivittyvät monisivuisessa Fw-dokumentissa kerralla. Leiskoissa yleisimmät Symbolin käyttötapaukset ovat lomake-elementeissa, napeissa ja tehokkaimillaan kokonaisissa Footer/Header alueissa.

Styles

Symbolien lisäksi Fireworks tarjoaa edistyneen Styles-toiminnon, jossa käytetty tyyli (Style) kattaa koko dokumentin CSS-tyylitiedostojen tapaan. Jos otsikolle tai leipätekstille on luotu oma Style, voidaan samaa Styleä käyttää jokaisella sivulla ja tarvittavat muutokset päivittyvät jokaiselle sivulle automaattisesti.

Ripeään työskentelyyn Fireworks tarjoaa ruudulta elementtien leikkaa-liimaa (copy/paste) toiminnallisuuden eri Adobe ohjelmien välillä. Fireworksissa luodun Symbol-objektin copypasteaminen Flashiin siirtyy muuttumattomana vilauksessa tai vektorielementin kopioiminen Illustratorista Fireworksiin onnistuu vaivatta.

Filters

Photoshopissa layeriin liittyvät tehosteet löytyvät Layer Style paneelin alta, Fireworksin vastaavanlaiset tehosteet löytyvät Properties Paneelin Filter-kohdasta. Filtereitä voi pinota miltei loputtomasti päällekkäin ja voidaan kytkeä päälle/pois, “flattaamatta” koskaan niitä itse objektiin.

Yhteenveto

Fireworks on tehokas työkalu, mutta tietoisuus ja yleisyys tästä on jäänyt Adoben lippulaivatuotteiden alle. Fireworksin tulevaisuus silti näyttää valoisalta – ketterän leiskaamisen, mobiili UI-suunnittelun ja CSS3-tekniikoiden myötä Fireworksin käyttäjäkanta kasvaa joka päivä.

Vakiintunelle Photoshop-käyttäjälle Fireworks saattaa vaikuttaa omituiselta, mutta modernissa webbisuunnittelussa on ihan tervettä oppia uusia hyödyllisiä asioita

Linkkejä aiheesta

10 Reasons Why I Prefer Fireworks CS4 To Photoshop For Web Design
50 reasons NOT to use Photoshop for Web Design
The Endless Fireworks vs. Photoshop Battle
Why I Prefer Adobe Fireworks over Photoshop for Designing Websites
Is Fireworks Better Than Photoshop?

Verkkotekstin rakenne – selkeä jäsentely helpottaa lukijaa

Koska kävijä lukee nettisivuja silmäillen, selaa sivuja nopeasti ja tarttuu vain itseään kiinnostavaa aiheeseen, on tekstin rakenteen palveltava surffailijaa. Hyvä verkkoteksti rakentuu kiteyttävistä otsikoista ja väliotsikoista, lyhyistä kappaleista sekä listoista.

Koukuttava pääotsikko: Yksittäisen sivun pääotsikon tulisi kuvata koko sivun aihetta. Mielenkiintoisella otsikolla saat kävijän tarttumaan syöttiin eli tutustumaan sisältöön tarkemmin.

Lyhyitä kappaleita: Jaa teksti kappaleisiin siten, että kussakin kappaleessa kerrotaan vain yksi asiakokonaisuus. Tärkein asia ensimmäiseen kappaleeseen ja tarkentava sisältö seuraaviin kappaleisiin.

Kiteyttäviä väliotsikoita: Hyvä väliotsikko kiteyttää kappaleiden sanoman. Väliotsikko toimii lukijalle tärppinä kiinnostavaan tietoon.

Listoja: Nyrkkisääntönä voidaan pitää, että yli kolmen kohdan luetteloissa tulisi käyttää listamerkkejä. Listaus auttaa lukijaa poimimaan luettelosta olennaisen ja hahmottamaan kokonaisuuden paremmin.

Kirjoitustyylistä ja verkkosivujen sisällöstä

Kenelle kirjoitat? Kohderyhmä huomioon

Keitä ovat yrityksen asiakkaat, entä kotisivujen kävijät? Täytyykö asia vääntää rautalangasta asiasta mitään tietämättömälle vai voidaanko käyttää ammattisanastoa, koska teksti on kohdennettu asiantuntijoille.

Tee tekstistä helppotajuista: anna esimerkkejä ja vältä abstrakteja sanoja

Verkkotekstin tulee olla helposti ymmärrettävää.  Käytä mieluummin konkreettisia sanoja kuin abstrakteja ilmauksia. Sanoja, jotka tuovat lukijalle mieleen jonkin asian tai esineen. Lyhyet virkkeet pitävät huolen, että lukija ymmärtää tekstin ensi lukemalta.

Vaikeampitajuisetkin asiat aukeavat esimerkin avulla. Jos kirjoitat palvelukuvausta AdWords-mainonnasta voi hyvänä esimerkkinä toimia kuvitteelliselle yritykselle toteutetun kampanjan kuvaus: suunnitteluvaihe, toteutusvaihe ja tulokset kuvaesimerkein höystettynä.

Puhuttele lukijaa – vältä passiivia

Saat verkkotekstiin tehokkaamman otteen, kun sinuttelet lukijaa.

Kirjoita näin: Toteutamme yrityksellesi vaikuttavat markkinointimateriaalit niin Internetiin kuin printtipuolellekin.

> Pyydä tarjous!

Ei näin: Suunnittelemme asiakkaillemme markkinointimateriaalia niin Internetiin kuin printtipuolellekin.

> Tarjouspyyntö

Verkkokirjoittamisen 3 sääntöä: tiivistä, tiivistä ja tiivistä

Web-käytettävyyden asiantuntija Steve Krug toteaa kirjassaan Dont’ make me think! suunnilleen näin: ”Poista verkkotekstistä ensin puolet ja karsi jäljelle jäänyt vielä puoleen.”

Jos avaat umpimähkään 10 eri yrityksen verkkosivut, saat lukea puolen näistä yrityksistä olevan luotettavia ja heidän tuotteidensa laadukkaita ilman sen kummempia perusteluita.  Verkkotekstissä ei ole sijaa ylimääräiselle jaarittelulle. Pitäydy faktaan ja poista tekstistä mitäänsanomattomat lauseet.

Vältä mm. näitä adjektiiveja: luotettava, laadukas, ammattitaitoinen, innovatiivinen, asiakaslähtöinen ja kustannustehokas

Korosta hyötyjä

Pohjimmiltaan asiakas ei osta palvelua, vaan palvelun tai tuotteen tuomaa hyötyä. Tuo siis myös palvelu- tai tuotekuvauksissa esille seikat, joiden takia asiakkaan kannattaa ostaa. Tekniset tiedot eivät yksistään riitä vakuuttamaan asiakasta.

Hyötyjä voivat olla esimerkiksi helppokäyttöisemmän ohjelmiston tuoma ajansäästö työaikaan tai hyvin hakukoneoptimoidun sivuston tuomat uudet asiakkaat ja noussut liikevaihto.

Herätä teksti henkiin, tee toisin kuin kilpailijat

Hyvä verkkoteksti on paitsi konkreettista myös ilmaisultaan rikasta. Tekstisi saa heti piristystä, kun vältät latteuksia ja käytät harvemmin hyödynnettyjä ilmauksia ja adjektiiveja. Värikäs teksti on oiva keino erottua kilpailijoista.

Esimerkkiä voit lukea Edisteen sivuilta

Suosittelun voima – referenssit näkyviin

Mikään ei toimi tehokkaammin kuin jo ostaneen suositus. Laita siis referenssit näkyvästi esille ja kerro, millainen ongelma asiakkaalla oli ja miten yrityksen palvelut tai tuote sen ratkaisi. Asiakkaan kuva ja kommentti ovat plussaa.

Oikolue. Pyydä kommentteja. Tee korjauksia.

Sisällöntuottajan on syytä osata peruskielioppi: isot alkukirjaimet, yhdyssanojen oikeinkirjoitus ja pilkkusäännöt. Pronominiviittausvirheistä tai lauseenvastikkeen väärästä käytöstä marmattamisen voi suosiolla jättää äidinkielenopettajille.

Pyydä siis muutamaa henkilöä oikolukemaan teksti ja kommentoimaan tekstin ymmärrettävyyttä ennen julkaisua.

Mitä yrityksen nettisivujen pitäisi sisältää?

Ainakin nämä

• Yhteystiedot ­– selkeästi näkyville.
• Tiedot palveluista ja tuotteista – yrityksen toimiala näkyviin heti etusivulla.
  Korosta hyötyjä!

Syvennä sisältöä

• Tietoa yrityksestä – yrityksen historiaa, toimintatapoja, henkilöitä
• Henkilöiden kuvat yhteystietoihin – juttu luistaa, kun puhelukumppanin naama on tiedossa
• Ajankohtaista-osio – ainoastaan jos päivityksestä huolehditaan säännöllisesti.

Näillä vakuutat

• Referenssit ja casekuvaukset – miten yritys on ratkaissut muiden asiakkaiden ongelmia.  Asiakkaan kommentti, nimi ja kuva plussaa. Muista linkittää case oikean palvelukuvauksen yhteyteen.
• Taustatietoja yrityksen avainhenkilöistä ­– erityisesti asiantuntijayrityksen verkkosivuilla!
• Maistiaisia yrityksen osaamisesta: asiantuntija-artikkeleita, ladattavia pikaoppaita, kysy & vastaa –palsta, blogi, videoita….

Ohjelmavinkki kirjoittajalle ja sisältösuunnittelijalle

XMind on työkalusi tekstin suunnitteluun, jos sanot miellekartoille kyllä ja naputtelet mieluummin näppäimistöä kuin tartut kynään. Lyhyellä ohjelmaperehtymisellä luot helposti muokattavia ajatuskarttoja ja rakennekaavioita. Perusversio on ilmainen – maksullisella versiolla saa lisäominaisuuksia käyttöön.

XMind soveltuu mainiosti myös nettisivujen sivukartan ja sisältöaiheiden suunnitteluavuksi.

www.xmind.net

Netissä aiheesta

• Vierityspalkin artikkeli sisällöntuottamisesta hakukoneoptimoinnin näkökulmasta
• Anja Alasillan kirjoitusvinkkejä Facebookissa

Kirjallisuutta

• Steve Krug: Don’t Make Me think
• Anja Alasilta: Verkkokirjoittajan käsikirja
• Anja Alasilta: Blogi tulee töihin
• Marsa Luukkonen: Tekstiä tekemään, kirjoittajan opas
• Katleena Kortesuo: Tekstiä Ruudulla, kirjoitamme verkkoon

Löytyykö Sinulta hyviä ajatuksia ja ideoita mitä palvelun tulisi jatkossa sisältää? Nyt on täydellinen aika jakaa ajatuksia ja päästä vaikuttamaan tulevaan palveluun. Kommentoi tai kerro niistä meille sähköpostitse osoitteeseen info@gfx.fi.

XSS-haavoittuvuudet ovat yllättävän yleisiä ja myös melko helposti löydettävissä. Kaikesta huolimatta niihin suhtaudutaan usein liiankin kevyesti.

Kesäkuussa Mikko Hyppönen kirjoitti F-Securen blogissa XSS-haavoittuvuudesta, joka oli löytynyt heidän omalta sivustoltaan. Tämän johdosta päätin kirjoittaa artikkelin tietoturvaongelmasta, jota mielestäni aliarvioidaan.

Hyppönen tiivisti ongelman ytimen erinomaisesti toteamalla “Jos edes tietoturvayhtiöt eivät saa omia sivujaan täysin aukottomiksi, niin minkälaista toivoa on yhtiöillä, joiden erikoisosaamisala ei ole tietoturva?”.

Allekirjoitan Hyppösen väittämän täysin: kirjoittaessani tätä artikkelia kävin läpi 15 satunnaista sivustoa Suomen 25 vierailluimmasta sivustosta. Lyhyehköillä, manuaalisilla testeillä löysin XSS-haavoittuvuuden yhdeksästä eri palvelusta. Kahdeksassa näistä palveluista on käyttäjäosio, kahdessa palvelussa liikkuu oikea raha.

Tässä artikkelissa käyn läpi XSS-haavoittuvuuksien eri muotoja, mitä ne todellisuudessa mahdollistavat, ja yhtälailla sitä, mitkä ovat XSS:n heikkoudet. Käyn läpi myös yhden kuvitteellisen esimerkin, jonka tarkoituksena on havainnollistaa tarkemmin XSS:n käyttöä todellisessa tilanteessa.

Artikkeli ei tarjoa neuvoja XSS-haavoittuvuuksien torjumiseksi, sillä aihe on monin osin teknologiariippuvainen. Artikkelin lopussa on kuitenkin listattuna muutama hyödyllinen linkki, jotka osaltaan antavat vinkkejä myös torjumiselle.

Mistä oikeastaan on kyse?

• XSS-haavoittuvuuksien määrän on arvioitu olevan noin 80% kaikista tietoturvahaavoittuvuuksista (Symantec, 2007),
• OWASP (The Open Web Application Security Project) listaa XSS-haavoittuvuudet vuoden 2010 toiseksi pahimmaksi tietoturvauhkaksi,
• XSS-haavoittuvuuksia on esiintynyt myös erittäin tunnetuilla sivustoilla, kuten Facebook, Twitter tai Wikipedia.

Lyhyenä johtopäätöksenä voidaan todeta, että XSS on laaja ja vakavasti otettava uhka, jolta edes suuret toimijat eivät voi välttyä.

XSS-haavoittuvuuksien muotoja

XSS-haavoittuvuuksia on olemassa ainakin neljää eri muotoa:

1. URL:n välityksellä suoritettava haavoittuvuus,
2. Sivustolle lähetetyssä syötteessä esiintyvä haavoittuvuus,
3. Selainpuolen logiikassa esiintyviä virheitä hyödyntävä haavoittuvuus,
4. Ulkoista syötettä hyödyntävä haavoittuvuus,

Lisäksi viidentenä uhkana on syytä listata “käyttäjän itsensä ajama haittakoodi”.

1) URL:n välityksellä suoritettava haavoittuvuus

Tämä lienee yleisin muoto haavoituvuudelle. Osoitteen välityksellä suoritettu haavoittuvuus on myös lyhytikäinen ja helpoiten havaittavissa.

Jos sivusto ei osaa validoida oikein URL:ssa välitettyjä parametreja, niin tämän haavoittuvuuden hyödyntäminen on helppoa. Tällöin URL voisi näyttää esimerkiksi tältä: http://www.domain.tld/?page=Main”%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e.

Uskallan väittää, että keskivertokäyttäjä (keskiverto, et siis sinä) ei näe tässä mitään epäilyttävää. Lisäksi keskivertokäyttäjän selain näkee tässä harvemmin mitään epäilyttävää. Ja vaikka näkisikin, niin sen kiertämiseksi on yleensä keinoja. Tämän lisäksi URL:n lyhennystä tarjoavat palvelut tarjoavat mahdollistavat käyttäjän hämäämisen.

2) Sivustolle lähetetyssä syötteessä esiintyä haavoittuvuus

Tämä tapaus on astetta vakavampi, sillä kyseessä on sivustolla pysyvästi esiintyvä haavoittuvuus.

Perusideana on löytää sivuston lomakkeista kenttiä, joiden kautta haittakoodi on lisättävissä. Esimerkkinä mainittakoon, että tällainen haavoittuvuus löytyi mm. Facebookista vielä muutama kuukausi sitten, jossa ryhmän nimeä ei validoitu, kun se esitettiin dynaamisissa hakutuloksissa.

Nykyään monet sivustot ovat rakennettu valmiiden tuotteiden tai frameworkien päälle, joissa tämänkaltaiset haavoittuvuudet on lähes poikkeuksetta estetty.

3) Selainpuolen logiikassa esiintyvät virheet

Tämä haavoittuvuuden muoto on idealtaan samankaltainen kuin kohdan #1 haavoittuvuus. Tässä tapauksessa haittakoodia ei lisätä HTML-rakenteeseen vaan se suoritetaan jo olemassa olevan Javascript-koodin avulla.

Tällainen haavoittuvuus esiintyy harvemmin. Tilanteissa, joissa sivustolle lisätään skriptejä dynaamisesti, suoritetaan eval() funktio tai muulla tavoin manipuloidaan DOM-rakennetta hyödyntäen suoraan URL:ssa välitettyjä parametreja, on tämän haavoittuvuuden hyödyntäminen täysin mahdollista.

4) Ulkoista syötettä hyödyntävä haavoittuvuus

Tämä haavoittuvuus on harvinaisempi ja esiintyy lähinnä silloin, kun ollaan toimittu todella ajattelemattomasti.

Esimerkkinä on tilanne, jossa sivustolla julkaistaan Twitter-feed jonkin hash-tagin perusteella kuitenkaan validoimatta feediä, tai käsittelemällä feediä selainpuolella (kohta #3). Näin kävi muun muassa tapauksessa #cashgordon.

5) Käyttäjän itsensä ajama haittakoodi

Tämä haavoittuvuus on ikävä siitä syystä, että sivuston ylläpitäjällä ei käytännössä ole vaikutusmahdollisuuksia haavoittuvuuden esiintymiseen. Haavoittuvuus perustuu sille, että käyttäjä saadaan itse ajamaan JavaScriptiä selaimessaan.

Mutta miksi käyttäjä ajaisi selaimessaan JavaScriptiä?

Tämä haavoittuvuus perustuu kolmeen asiaan: 1) peruskäyttäjä ei tiedä tämän olevan kovin vaarallista, 2) suositus haittakoodin ajamiseksi tulee monesti muilta, yleensä tutuilta ihmisiltä ja 3) uteliaisuus ei ole synti.

Asetelma on käytännössä hyvin samanlainen kuin sähköposteilla leviävien matojen ja viruksien osalta.

Moni meistä on nähnyt tämän tapahtuvan esimerkiksi Facebookissa. Kuvitellaan skenaario: luodaan ryhmä, jossa kerrotaan dislike-toiminnon saamisesta käyttöön ajamalla yksinkertainen komento selaimen osoitepalkissa. Tämän avulla lisätään sivulle skripti, joka tekee automaattisen status-päivityksen, jolloin huijaus leviää.

Tämä skenaario on itse asiassa totta. Tällä tavoin huijausta saatiin levitettyä satojen tuhansien Facebook-käyttäjien keskuudessa. Enkä yhtään ihmettele.

XSS tarkoittaa aina ongelmia

Alla on listattuna muutama ongelma, jotka ensimmäisenä tulevat mieleeni XSS-haavoittuvuuksista:

Käyttäjän syöte on selkokielistä

Tärkeimpänä huomio on, että injektoitu sivu voi kerätä talteen selkokielisenä kaiken, mitä käyttäjä sivulle syöttää. Käyttäjä voi luulla normaalisti kirjautuvansa palveluun syöttäen tunnuksen ja salasanan ollen täysin tietämätön, mihin tiedot todellisuudessa päätyvät.

Käyttäjä luottaa tuttuun sivustoon

Toinen tärkeä huomio on, että XSS mahdollistaa toimimisen ympäristössä, johon käyttäjä luottaa. Tämä madaltaa kynnystä sille, että käyttäjä on valmis luovuttamaan arkaluontoisia tietoja. Kun tutun palvelun ruudulle ilmestyy dialogi, joka luotettavasti esittää syitä, miksi käyttäjän on syötettävä tunnuksensa ja salasanansa, ei käyttäjä välttämättä osaa epäillä mitään.

XSS-haavoittuvuus indikoi myös muista tietoturvaongelmista

Jos sivustolta löytyy XSS-haavoittuvuus, niin ei ole epäkohteliasta olettaa sivustolla olevan myös muita puutteita tietoturvassa. XSS-haavoittuvuus antaa usein viittaukseen siihen, että sivusto ei ole rakennettu valmiin tuotteen päälle, jolloin tietoturvaan liittyvät seikat on täytynyt miettiä erikseen. Vaikka sivusto olisikin tehty hyödyntäen valmista frameworkia, niin tällöin on tehty auttamattomasti väärin.

Joka tapauksessa on varmaa, että XSS-haavoittuvuus houkuttelee ei-toivottuja vieraita sivusto(i)lle.

Virheillä on tapana toistua

Kun sivuston luonut taho on tiedossa, syntyy uudenlainen ongelma: googlaamalla tai vierailemalla tahon oman sivustolla on usein löydettävissä muut saman tahon luomat sivustot, joilla samat tietoturvaongelmat mahdollisesti toistuvat.

Käyttäjän silmissä jokainen haavoittuvuus on yhtä vakava

Kun käyttäjä kuulee sivustolla olleen tietoturvaongelmia, hänen luottamus sivustoa kohtaan on usein menetetty. Sillä on harvemmin väliä, onko joku onnistunut saamaan haltuunsa yksittäiset tunnukset, viemään koko tietokannan tai tehnyt vain pientä kiusaa XSS-haavoittuvuuden avulla. Peruskäyttäjiä ei niinkään kiinnosta tekniset yksityiskohdat tai sivuston ylläpitäjän selitykset tietoturvaongelmien eri vakavuusasteista.

Kuvitteellinen esimerkki XSS-haavoittuvuudesta

Tämän esimerkin tarkoituksena on havainnollistaa, minkälaisen tilanteen XSS-haavoittuvuus voi mahdollistaa.

Alkutilanne

Olemme löytäneet XSS-haavoittuvuuden hyvin suositulta keskustelupalstalta. Haavoittuvuus voidaan ajaa lisäämällä haittakoodi yhdessä keskustelusäikeen tunnisteen parametrissä: http://www.foobarforum.com/?threadID=42%27%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e

Valtaosa merkeistä on UTF-8 formaatissa. Osoitteen lyhentämiseksi voimme toimia myös siten, että muutamme vain osan merkeistä UTF-8 formaattiin. Vaihtoehtoisesti voisimme käyttää URL:n lyhentäjiä.

Valmistelut

Olemme siis luoneet keskustelun, jonka ID on 42. Lisäksi olemme luoneet skriptin, jota kutsumme. Tämä skripti ajaa haittakoodin sekä tekee tarvittavat muutokset, jotta loppuvaikutelma on luotettava.

Olemme aiemmin luoneet käyttäjätunnuksia muille suosituille keskustelupalstoille sekä kirjoittaneet muutamia viestejä, jotta luodut tunnukset ovat muiden käyttäjien silmissä luotettavampia.

Tämän jälkeen luomme viestejä muille keskustelupalstoille, joissa viittaamme XSS-haavoittuvuuden sisältävälle keskustelupalstalle:

Olemme kirjoittaneet viestin työajan ulkopuolella, kuitenkin keskustelupalstojen käyttäjien ollessa vielä aktiivisia. Eli keskustelupalstoilla vierailevien käyttäjien määrä on suuri, mutta ylläpitäjän viive haavoittuvuuden korjaamiseksi voidaan olettaa olevan pidempi.

Viestin tarkoitus on olla riittävän houkutteleva, mutta samalla uskottava. Keskustelupalstat ovat usein rakentuneet jonkin teeman ympärille (tekniikka, musiikki, perhe, jne.), jolloin houkuttelevien palkintojen ja muiden lupausten keksiminen on hyökkääjän kannalta triviaalia.

Hyökkäyksen kannalta on ongelmallista, että ennemmin tai myöhemmin joku käyttäjistä huomaa linkin hyödyntävän XSS-haavoittuvuutta – ilmoittaen asiasta sekä keskustelupalstalle että kohdesivuston ylläpitäjälle. Olemme kuitenkin jakaneet linkkiä useilla eri sivustoilla, jolloin vierailevia käyttäjiä tulee useista lähteistä.

Varsinainen ongelma

Koska olemme kiinnostuneet käyttäjätunnuksista, meidän on ylläpidettävä tarinaa, joka saa käyttäjän kirjautumaan tai rekisteröitymään palveluun. Lisäksi meidän on huolehdittava siitä, että käyttäjä ei välillä poistu injektoidusta dokumentista:

Olemme muokanneet dokumentin sisältöosiota jättäen ympäröivä rakenne alkuperäiseen muotoonsa, pois lukien sivuston oma kirjautumisosio (1). Kerromme käyttäjälle aiemmin kuvaillulla tavalla, että sivustolle on kirjauduttava sisään, jotta (kilpailu)viesti on nähtävissä. Samalla tarjoten myös toista lomaketta (2) sisäänkirjautumista varten.

Kumpikaan kirjautumislomakkeesta ei todellisuudessa ohjaa uudelle sivulle vaan ainoastaan lähettää syötetyt tiedot hyökkääjän palvelimelle sekä näyttää “väärä käyttäjätunnus tai salasana” -ilmoituksen haavoittuneessa dokumentissa.

Jos käyttäjä on jo rekisteröitynyt palveluun, on myös mahdollista, että hänellä on käytössään selaimen suorittama tunnuksen ja salasanan esitäyttö sivuston omaan sisäänkirjautumislomakkeeseen. Tässä tilanteessa saamme suoraan poimituksi tunnuksen ja salasanan.

Lisäksi tarjoamme rekisteröitymismahdollisuutta (3), joka tässä tapauksessa avaa täytettäväksi dynaamisesti luodun dialogin. Samoin menettelemme myös “unohtuneen salasanan” (4) kohdalla.

Hyökkäyksen elinkaaren kannalta on tärkeää saada käyttäjä pidetyksi haavoittuneessa dokumentissa mahdollisimman pitkään.

Jokaiselta löytyy (tai ainakin pitäisi löytyä) useampia eri salasanoja, joita käyttää eri palveluissa. Tämän myötä on aivan mahdollista, että jo rekisteröitynyt käyttäjä tulee kokeilleeksi useampia käyttämiään salasanojaan yrittäessään kirjautua palveluun. Käyttäjän pyytäessä uutta salasanaa on varsin tavallista tiedustella käyttäjän sähköpostiosoitetta sekä mahdollisesti vastausta johonkin turvakysymykseen. Tämä mahdollistaa jälleen uusien, arkaluontoisten tietojen keruun.

Tämän kaiken lisäksi on mahdollista, että löydämme meitä hyödyttävää tietoa myös evästeistä tai muista sivustolla käytettävistä muuttujista.

Lopputulos

Tarjoamme käyttäjälle useamman mahdollisuuden syöttää joko olemassaoleva tunnus ja salasana palveluun tai rekisteröityä palveluun, jolloin voimme pyytää käyttäjältä muita henkilökohtaisia tietoja.

Vaikka lopputuloksena olisi se, että emme saisi yhdenkään käyttäjän tunnuksia, niin vahinko on jo tapahtunut. Vähintä (tai järkevintä), mitä haavoittuneen sivuston ylläpitäjä voi tehdä, on kertoa tilanteesta ja kehoittaa kaikkia käyttäjiä vaihtamaan salasanansa omassa palvelussaan sekä myös muissa palveluissa, joissa on käytössä sama salasana.

Johtopäätös

Kuten aiemmin totesin, XSS-haavoittuvuuksia löytyy jatkuvasti niin pieniltä kuin suurilta sivustoilta. Tein itse vain pienen pintaraapaisun käydessäni läpi joitakin Suomen suosituimpia sivustoja todeten, että yli puolessa palveluista löytyy haavoittuvuus. Kaiken kaikkiaan olen tänä vuonna raportoinut reilu viisikymmentä haavoittuvuutta, näiden tapausten ollessa yleensä todella ilmeisiä.

Olen valmis tekemään johtopäätöksen, että XSS-haavoittuvuuksiin joko suhtaudutaan verkkopalveluiden ylläpitäjien näkökulmasta liian kevyesti tai tietoisuus tästä haavoittuvuuden muodosta on aivan liian vähäinen. Toisena johtopäätöksenä on, että loppukäyttäjän ei voida koskaan olettaa olevan riittävän valveutunut tai vastuussa haavoittuvuuteen lankeamisesta, vaan vastuu on aina sivuston ylläpitäjällä.

XSS-haavoittuvuuksien hyödyntäminen vaatii jonkin verran luovuutta ja mielikuvitusta, eli “ei se tarina, vaan miten se kerrotaan”. Jos tavoitteena todella on aiheuttaa haittaa, niin keinojen keksiminen ei viime kädessä ole ongelma.

Luettavaa

• Wikipedia: Cross Site Scripting
• XSS Cheat Sheet
• XSSed – Cross Site Scripting attacks information and archive
• “alert(‘xss’) – The slow death of XSS”
• Opera Dev Community: JavaScript for Hackers
• Video: JavaScript: The Evil Parts (Billy Hoffman, JSConf 2010)
• Listaus XSS-haavoittuvuuksista Suomessa (päivitetty viimeksi 19.4.2008)

Katso demo

Lataa tiedostot

Tämä opas on henkinen jatko-osa jutulle nimeltään Ajax:in alkeet jQueryn avulla. Demosivu muistuttaa pitkälti edelliskertaista sivua, mutta joitakin muutoksia on tullut:

index.html:

<!DOCTYPE html>
<html lang="fi">

<head>
	<meta charset=utf-8>
	<title>Otsikko</title>

	<script src="http://www.google.com/jsapi"></script>
</head>

<body>

	<h1>Otsikko</h1>

	<ul id="navigointi">
		<li><a id="etusivu" href="#">Etusivu</a></li>
		<li><a id="uutiset" href="#">Uutiset</a></li>
		<li><a id="yhteystiedot" href="#">Yhteystiedot</a></li>
	</ul>

	<div id="sisalto">

	</div>

</body>
</html>

Nyt navigointilinkit eivät johda mihinkään ja sivun varsinainen sisältö on poistettu, sillä tulemme hoitamaan tämän kaiken jQueryn ja Ajaxin avulla. Näinhän ei tietenkään oikealla sivulla koskaan tulisi toimia, mutta jotta juttumme pääasia tulisi mahdollisimman selväksi, oiotaan mutkia tältä osin hiukan.

Kaikki sisältö on siirretty yhteen dokumenttiin nimeltään ajax.html, jotta jatkossa osioiden käsittely jQueryllä olisi hiukan helpompaa. Heitetään soppaan vielä mukaan pieni kuvagalleria jokaiselle osiolle:

ajax.html:

<div id="etusivu">
	<h2>Etusivun jutut</h2>

	<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

<div id="uutiset">
	<h2>Uutiset</h2>

	<p>Päivän tärkeimmät tapahtumat.</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

<div id="yhteystiedot">
	<h2>Yhteystiedot</h2>

	<p>Osoite, puhelinnumero yms...</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

Galleriat sisältävät kolme ”kuvaa” jotka tulevat päivittymään #sisalto-divin sisällä dynaamisesti käyttäjän klikkaillessa kuvalinkkejä. Tässä esimerkissä simuloimme kuvia tyhjillä diveillä. Kuvat on oletuksena piilotettu näkyvistä display: none; -määreellä.

Kirjoitetaan navigoinnista vastaava jQuery uusiksi:

google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Ladataan etusivun sisällöt näkyviin
	$('#sisalto').load('ajax.html #etusivu');

	// Vaihdetaan näkymää klikatun linkin mukaan
	$('#navigointi a').click( function() {

		$('#sisalto').load('ajax.html #' + $(this).attr('id'));

		return false;

	});

});

Ensimmäinen jQuery-loitsu on varmaankin aika selvä. Toisessa pätkässä lataamme klikatun linkin id:tä vastaavan div:in ajax.html:stä.

Seuraavaksi voimmekin jatkaa edellisen perään galleriamme toiminnallisuus. Logiikka on pitkälti sama, kuin aiemminkin:

google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Ladataan etusivun sisällöt näkyviin
	$('#sisalto').load('ajax.html #etusivu');

	// Vaihdetaan näkymää klikatun linkin mukaan
	$('#navigointi a').click( function() {
		$('#sisalto').load('ajax.html #' + $(this).attr('id'));
		return false;
	});

	// Avaa klikattu kuva ja piilota edellinen
	$('#kuvalinkit a').click( function() {

		$('#galleria .' + $(this).attr('class')).show('slow')
		.siblings()
		.hide('slow');

		return false;

	});
});

Kaiken järjen mukaan edellisen koodin pitäisi toimia aivan kuten navigoinninkin, mutta klikatessa kuvalinkkejä kuvat eivät kuitenkaan aukea. Mitä oikein tapahtui?

Ken vanhoja muistaa, sitä tikulla silmään

Kun selain on saanut ladattua sivun rakenteen, DOM:in, jQuery käy sen läpi ja lisää mm. klikkausten tapahtumakäsittelijät (click event handlers) vaadituille elementeille, meidän tapauksessamme kuvalinkeille. Kun lataamme Ajax-kutsulla #sisalto-diviin jonkin sisältönäkymistä, muokkaamme tätä rakennetta jälkeenpäin. jQuery ja JavaScript ovat tällä hetkellä hieman ulalla, sillä kukaan ei ole kertonut heille, että sivuilla on jotain tapahtunut. Meidän täytyy siis kertoa JavaScriptille jotenkin, että sivu on päivittynyt ja sen täytyy ottaa huomioon myös uusi sisältö.

Kun ei homma itseltä onnistu, delegoidaan

jQueryn tuorein päivitys, 1.4.2, toi mukanaan uuden .delegate()-metodin, jolla saamme ongelmamme ratkaistua. Delegate-metodin toimintaperiaate ei välttämättä aukea aivan heti kaikille joten otetaanpa alkuun pieni annos JavaScriptin teoriaa:

Tapahtumien kupliminen, tai event bubbling, on olennainen osa koko JavaScriptin filosofiaa. Kun käyttäjä klikkaa elementtiä sivuilla, alkaa taustalla erikoinen tapahtumaketju. Katsotaan vaikka esimerkiksi demosivumme linkkilistaa: Klikatessa linkkiä listassa, laukeaa klikkaustapahtuma tässä kyseisessä HTML-elementissä. Tämän jälkeen linkkielementti ”mainostaa” tätä tapahtumaa isäntänään olevalle LI-elementille. LI-elementti taas heittää tämän viestin ylöspäin UL-elementille ja näin jatketaan ylöspäin aina dokumenttipuun alkuun asti, ellei kuplimista jostain syystä erityisesti haluta katkaista.

Delegate-metodin temppuna on hakea jokin ylempi elementti sivuilta ja sitoa kuplimisen kautta jonkin alempana dokumenttipuussa olevan elementin tapahtuma, tässä tapauksessa klikkaus, siihen. Jotta saisimme delegate-metodin käyttöömme, pitää meidän valita sivuilta jokin kaikille linkeille yhteinen elementti, jota ei päivitetä Ajax-kutsuja tehdessä. Body on useasti aika varma valinta. Käytämme body:a hyväksemme kierrättämällä klikkaustapahtumat sen kautta ja delegoimme tapahtumat alaspäin uusille, Ajax:lla tuoduille elementeille.

Muutetaan alkuperäisiä kuvanvaihtolinkkiemme tapahtumakäsittelijöitä hiukan niin, että otamme delegate-metodin mukaan leikkeihin:

// Avaa klikattu kuva ja piilota edellinen
$('body').delegate('#kuvalinkit a', 'click', function() {
	$('#galleria .' + $(this).attr('class')).show('slow')
	.siblings()
	.hide('slow');
	return false;
});

Nyt kuvalinkit pelaavat kaikissa alinäkymissä kauniisti. Olisimme voineet sitoa delegoinnin myös lähemmäksi kuvalinkkejä demosivullamme, esimerkiksi #sisalto-diviin, mutta suorituskyvyllisesti tällä ei näin pienessä demossa ole merkitystä.

Mitä suuremmaksi Ajax-projektit kasvavat, sitä arvokkaammaksi suorituskyvyn parantajaksi delegate nousee. Vanhemmissa jQuery-versioissa käytetty live()-metodin perusidea on pitkälle sama, kuin delegatella, mutta se sitoo tapahtumakäsittelijät aina dokumentin alkuun. Delegatella voimme sitoa klikkausten seurannan mahdollisimman lähelle klikkauksen alkujuuria ja näin vähentää selaimen taakkaa JavaScriptin käsittelyssä.

jQueryn ja JavaScriptin optimoinnista syvemmin kiinnostuneiden kannattaa katsoa Paul Irish:in esitelmä aiheesta: jQuery Anti-Pattern for Performance.

Valmiin demon voit katsastaa täältä.

Lataa tiedostot

Katso demo
Lataa tiedostot

Monille ensimmäinen kosketus dynaamisten sivujen rakentamiseen on PHP:n include-ominaisuus jolla HTML-sivu voidaan koostaa useammasta pienemmästä kappaleesta. Näin esimerkiksi sivun navigointia ei tarvitse ei tarvitse toistaa HTML-koodissa uudestaan joka sivulla, vaan se voidaan hakea yhdestä tiedostosta joka kerta.

Tänä päivänä sivulle voi helposti tuoda sisältöä myös sivun latauksen jälkeen. Tähän käytetään AJAX-tekniikkaa, joka mahdollistaa sivun sisällön päivittämisen ilman, että koko sivu ladataan uudelleen.

Käytän esimerkeissä jQuery JavaScript-kirjastoa, joka harmonisoi mukavasti selainten erilaisen käyttäytymisen JavaScriptin kanssa, sekä helpottaa ja nopeuttaa kaiken kaikkiaan koodin kirjoittamista.

Tehdään alkuun yksinkertainen mallisivu, jolla on vain pieni navigointi ja yksi div-elementti, johon dynaaminen sisältö ladataan. Ei mitään liian jännää:

<h1>Otsikko</h1>

<ul>
 <li><a id="etusivu" href="index.html">Etusivu</a></li>
 <li><a id="uutiset" href="uutiset.html">Uutiset</a></li>
 <li><a id="yhteystiedot" href="yhteystiedot.html">Yhteystiedot</a></li>
</ul>

<div id="sisalto">
 <h2>Etusivun jutut</h2>
 <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>
</div>

Seuraavaksi voimme tehdä navigointia vastaavat sisältöosiot omiin tiedostoihinsa:

uutiset.html

<h2>Uutiset</h2>

<p>Päivän tärkeimmät tapahtumat.</p>

yhteystiedot.html

<h2>Yhteystiedot</h2>

<p>Osoite, puhelinnumero yms...</p>

Lisää vielä seuraava rimpsu sivusi head-osioon:

<script src="http://www.google.com/jsapi"></script>

Edellinen koodinpätkä mahdollistaa jQueryn käytön suoraan Googlen palvelimelta, joten sinun ei tarvitse asentaa kirjastoa välttämättä itsellesi.

Nyt meillä on kaikki tarvittava sisältö ja voimme alkaa rakentamaan JavaScriptiä, joka hoitaa sisällön hakemisen #sisalto-diviin kun käyttäjä klikkaa navigoinnin linkkiä. Käytämme jQueryn .load()-metodia, jonka syntaksi on hyvin yksinkertainen:

// Ladataan jQuery Googlen palvelimelta ja ajetaan JS vasta kun
// koko dokumentti on latautunut.
google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Kun Uutiset-linkkiä klikataan:
	$('#uutiset').click( function() {

		// Lataa uutiset.html-tiedoston sisältö 'sisalto'-divin sisään.
		// Samalla vanha sisältö pyyhkiytyy pois.
		$('#sisalto').load('uutiset.html');

		// Lopuksi estämme selainta turhaan seuraamasta linkkiä
		// klikattuun osoitteeseen.
		return false;

	});

	// Toistetaan sama temppu yhteystiedoille
	$('#yhteystiedot').click( function() {
		$('#sisalto').load('yhteystiedot.html');
		return false;
	});

});

Tällä hetkellä emme ole vielä tehneet mitään etusivulle vievälle linkille ja tässä yksinkertaisessa esimerkissä kaikki toimii jo nyt ok, mutta voimme ladata myös etusivun sisältöosuuden uudestaan etusivulle.

	// Ladataan etusivun sisällöt takaisin näkyviin ilman
	// koko sivun uudelleen päivittämistä
	$('#etusivu').click( function() {
		$('#sisalto').load('index.html #wrapper');
		return false;
	});

Syntaksi on hiukan muuttunut tällä kertaa. Koska etusivun jutuille ei ole olemassa omaa erillistä HTML-tiedostoaan, vihreiden arvojen kunniaksi kierrätämme index.html-tiedoston uusiokäyttöön, mutta otamme siitä vain tarvitun osan, eli sisällön:

$('#sisalto').load('index.html #wrapper');

Jos yrittäisimme käyttää edellisten esimerkkien koodia ja lataisimme vain suoraan #sisalto-divin vanhan #sisalto-divin sisään tapahtuisi aika epätoivottu reaktio:

<div id="sisalto">
 <div id="sisalto">
 <h2>Etusivun jutut</h2>
 <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>
 </div>

</div>

Koska Yo Dawg-efekti ei ole tavoitteissamme, lisäämme alkuperäiseen index.html-tiedostoon ylimääräisen wrapperin heti #sisalto-divin jälkeen. Ylimääräisen HTML:n lisääminen ei ole kovin elegantti ratkaisu, mutta jokainen voi kotitehtävänä miettiä, miten edellä esitetty ongelma kierretään tyylikkäämmin.

Valmiin demon voit katsastaa täältä.

Lataa tiedostot

Mikä Savalanche?

Savalanche on uudenlainen verkkokauppapalvelu, joka rakentuu Internetin sosiaalisen median palveluiden päälle – tai oikeastaan niiden sisälle. Savalanchessa kuka tahansa voi perustaa kaupan, jopa ilman omia tuotteita. Kaupassa voi nimittäin myydä muiden tahojen maahantuomia tai valmistamia tuotteita, näin esimerkiksi suositun blogin tai keskustelupalstan ylläpitäjä voi helposti ansaita lisätuloja.

Savalanche on periaatteessa tavanomainen täyden palvelun verkkokauppapalvelu, jolla yritys voi viedä tuotteensa myyntiin web-sivuilleen ja esim. Facebookin kaltaisiin sosiaalisiin medioihin. Juju piileekin siinä, että Savalanchea hyödyntäen kuka tahansa voi rakentaa laajan, monikanavaisen verkkokauppaverkoston. Lisäksi palvelulla voidaan myös kerätä varoja esim. hyväntekeväisyyteen tai urheiluseuroille.

Kolme muskettisoturia

Savalanche palvelun takana ovat kolme suomalaista IT-alan konkaria, jotka aikaisemmassa elämässään ovat olleet suunnittelemassa, rakentamassa ja myymässä suuria tietojärjestelmiä ja ohjelmistoja matkapuhelinteollisuuden tarpeisiin. He muodostavat yhdessä Vuole Digitalin.

Apuja kehitystyöhön on löytynyt omien alojensa asiantuntijayrityksistä. Palveluun uskovat muutkin, sillä tuotekehitystä ovat olleet tukemassa mm. Tekes ja Finnvera.

Kuinka palvelu erottuu tavanomaisista verkkokaupoista?

Savalanchessa verkkokaupan voi perustaa ilman ainuttakaan omaa tuotetta. Kuulostaa ehkä kummalliselta, mutta tämä on juuri se todellinen oivallus, sillä myymällä tuotteita muiden valikoimista voi ansaita provisiota ilman omaa varastoa tai muuta päänvaivaa. Sen lisäksi käyttäjät voivat myydä myös omia tuotteitaan kuten normaalissa verkkokaupassa. Laajuudeltaan tuotevalikoima voi olla muutamasta kappaleesta satoihin.

Kuulostaisiko ura verkkokauppiaana hyvälle? Kohta se on helppoa kuin heinänteko. Savalanche on rakennettu toimimaan yhdessä Facebookin kaltaisten sosiaalisen median palveluiden kanssa. Kuka tahansa voi perustaa verkkokaupan Facebook-sivuilleen muutamassa minuutissa.

Savalanchen avulla käyttäjät voivat halutessaan kerätä rahaa myös hyväntekeväisyyteen tai yhdistyksille, urheiluseuroille, koululuokille jne. Tärkeän työn tukeminen on entistä helpompaa.

Savalanche on muutamasta markkinoilla olevasta social shopping -palveluista poiketen voimakkaammin social selling -palvelu, jossa ihmiset luovat ystäväpiiriään ja samanhenkisiä ihmisiä kiinnostavia kauppoja ja valikoimia crowdsourcing -hengessä.

Savalanche käytännössä

Verkkokaupan perustaminen omille sivuilleen, Facebookiin tai blogiin tapahtuu Savalanche.com:ssa, tai suoraan Savalanchen Facebook-sovelluksessa. Kaupan perustaminen on täysin ilmaista ja vaikeustaso on samaa tasoa web-sähköpostipalveluun rekisteröitymisen kanssa. Tämän jälkeen käyttäjälle alkaa kertyä myyntituottoja sitä mukaa, kun hänen kaupastaan ostetaan tuotteita.

Savalanchen kautta esim. maahantuojat voivat listata tuotevalikoimansa tai varastonsa sisällön palveluun, jolloin kuka tahansa kiinnostunut voi myydä heidän tuotteitaan perustamassaan verkkokaupassa. Senkin pitäisi olla lupauksen mukaan nopeaa, helppoa ja ilmaista.

Kenelle Savalanche on suunnattu?

Savalanchen pitäisi soveltua periaatteessa kaikille. Palvelusta hyötyvät niin maahantuojat ja tuotteiden valmistajat kuin kuka tahansa Internetin aktiivi. Olennaisinta on tietysti se miten paljon lukijoita tai kavereita on palvelussa, sillä tuottomahdollisuudet kasvavat sen mukaan.

Helpotusta pitäisi tulla myös nuoremmalle väelle ja varsinkin heidän vanhemmilleen. Urheiluseurat, koululuokat, yhdistykset ynnä muut voivat hankkia lisävaroja tai korvata perinteisen (ja usein kovin turhauttavan) ovelta ovelle -myynnin keskittämällä varainkeruun Savalanchen avulla webbiin.

Savalanchesta on iloa myös tiskin toiselle puolelle. Selailemalla kiinnostavaa blogia tai ystävien kauppoja valikoimat vastaavat myös todennäköisesti omia tarpeita ja kiinnostuksen kohteita. Esimerkiksi maastopyöräilyaiheisen keskustelupalstan ylläpitäjällä on todennäköisesti erittäin hyvät valmiudet valita verkkokauppaansa sellaisia tuotteita, jotka kiinnostavat myös hänen lukijoitaan.

Kohti tulevaisuutta

Kuuleman mukaan Savalanche käynnistyy suljettuna pilottina kesän 2010 aikana. Palveluun tehdään silloin viimeiset säädöt ja varmistetaan, että luvattu helppokäyttöisyys ja selkeys toteutuvat myös käytännössä. Savalanchen pitäisi aueta kaikille suomalaisille syksyllä 2010. Gfx.fi toivottaa onnea uudelle lupaavalle palvelulle ja sen kehitystiimille. Jäämme odottamaan jännityksellä tulevaa syksyä.

P.S. Palvelun kehittäjät tarvitsevat kesän 2010 pilottiin vielä muutaman beta-testaajan. Heräsikö kiinnostus? Lisätietoja saat sähköpostilla osoitteesta info@savalanche.com.

Listalle on valittu 3. asteen opintopaikkoja ympäri Suomen – sisältäen ammattikorkeakouluja ja yliopistoja. Listalta löytyy mm. ohjelmointiin, graafiseen suunnitteluun ja viestintään liittyviä koulutusohjelmia. Lista on aakkosjärjestyksessä. Koulut ovat itse toimittaneet esittelymateriaalin koulutusohjelmistaan.

Jyväskylän ammattikorkeakoulu

Jyväskylän ammattikorkeakoulun Teknologiayksikössä olevalla ICT-tulosalueella on
kolme koulutusohjelmaa, joissa koulutetaan tietoverkkoihin liittyvää osaamista:

• Mediatekniikan koulutusohjelma, jossa opiskellaan mm. verkkomultimediaa
• Ohjelmistotekniikan koulutusohjelma, jossa aiheina ovat mm. web- ja mobiiliohjelmointi
• Tietotekniikan koulutusohjelma, jossa keskitytään tietoverkkojen suunnittelun ja ylläpidon koulutukseen.

Lisätietoja koulutusohjelmista

Kymenlaakson ammattikorkeakoulu

Alla tietoa Kymenlaakson ammattikorkeakoulun digialan koulutuksesta sekä sitä läheltä liippaavista suuntautumisvaihtoehdoista.

Viestintä

Kymenlaakson ammattikorkeakoulu tarjoaa viestinnän koulutusohjelmassa av-median, digitaalisen median sekä graafisen suunnittelun koulutusta.

• Av-median suuntautuminen tuottaa osaajia audiovisuaalisen alan toteutus- ja suunnittelutehtäviin.
• Monipuolinen verkko-osaajien suuntautumisvaihtoehto on Digitaalinen media, jossa suunnitellaan ja toteutetaansisältöjä 3D-, peli-, web-, ja mobiiliympäristöihin. Digitaalisen median sv:ssa opiskellaan muun muassa käyttöliittymäsuunnittelua, e-markkinointia, hakukoneoptimointia, sisällöntuotantoa, web-ohjelmointia sekä mobiili- ohjelmointia. Samoin tarjolla on pelituotantoon liittyvä opinto-osio. Sen painopiste on pelien suunnittelussa, konseptoinnissa, käsikirjoittamisessa sekä visuaalisten sisältöjen tuotannossa.
• Graafinen suunnittelija hallitsee kuvallisen viestinnän eri medioissa.

Lisätietoja koulutusohjelmasta

Tietotekniikka

KyAMK:n tietotekniikan koulutusohjelman ohjelmistotekniikan suuntautumisvaihtoehdon opiskelijat sijoittuvat valmistumisensa jälkeen ohjelmistojen ja web-palvelujen kehitystehtäviin. Koulutus keskittyy ohjelmointiin ja tapahtuu osittain Ohjelmistoakatemiassa oikeissa ohjelmistoprojekteissa. Eritysalana KyAMK:ssa on valinnainen peliohjelmoinnin koulutus (18 op), jonka toteutukseen osallistuu peliteollisuus.

Lisätietoja koulutusohjelmasta

HAAGA-HELIA AMK

HAAGA-HELIAsta löytyy mm. tietojenkäsittelyn koulutusohjelman opetusta.

Tässä linkki suomenkieliseen opetussuunnitelmaan ja tässä linkki opiskelijatöiden esittelysivustoon, jota kehitetään parasta aikaa.

Vaasan ammattikorkeakoulu

Vaasan ammattikorkeakoulussa (Vamkissa) on tarjolla mm. tietojenkäsittelyn ja tietotekniikan koulutusohjelmat.

Vaasan ammattikorkeakoulussa löytyy alan koulutusta tietojenkäsittelyn koulutusohjelman muodossa. Koulutusohjelmassa valmistutaan ict-alan tradenomiksi ja digitaaliset palvelut on yksi suuntautumisvaihtoehdoista. Tietojenkäsittelyn koulutusohjelman tiedot löydät täältä. Vastaava ruotsinkielinen ohjelma on informationsbehandling, josta löytyvät tiedot täältä.

Digitaalisen palvelun sisältö: Digitaaliset palvelut: graafisen tuotannon työkalut, sisällöntuotanto verkossa, Flash ja animaatiot, multimedian tuotannon työkalut, videokuvaus ja editointi, 3d-mallinnus ja animaatiot.

Tietotekniikkaa on tarjolla meillä suomenkielisessä koulutusohjelmassa  ja englanninkielellä Information Technology -koulutusohjelmassa.

Hämeen ammattikorkeakoulu

Alta löydät Hämeen ammattikorkeakoulun tietojenkäsittelyn ja liiketalouden
koulutusohjelmien tiedot ja linkit.

Kaikki käyttävät nettiä, me teemme sitä!
Opiskele tietojenkäsittelyn tradenomiksi Hämeenlinnassa Hämeen ammattikorkeakoulussa.

Asiakastyytyväisyys, innovatiivisuus ja yhteistyökyky!
Opiskele liiketalouden tradenomiksi Hämeenlinnassa Hämeen ammattikorkeakoulussa. Kurssisisältönä mm. Digital Enterprise 30 op.

Tampereen yliopisto

Tampereen yliopiston informaatiotieteiden tiedekunnassa on mm. seuraavia koulutuksia:

Interaktiivisen median maisterikoulutus

Tietojenkäsittelytieteiden koulutusohjelma:
Koulutusohjelmassa mm. käyttöliittymien ohjelmistokehitykseen tai vuorovaikutteiseen teknologiaan syventävät maisterikoulutukset

Vaasan yliopisto

Teknisen viestinnän koulutusohjelma.

Vuonna 1996 perustetun Teknisen viestinnän koulutusohjelman perusajatuksena on se, että viestintätieteiden ja tietotekniikan opiskelijat opiskelevat yhdessä koko koulutusohjelman ajan, vaikka he kuuluvatkin eri tiedekuntiin (filosofiseen ja teknilliseen) ja eri pääaineisiin.

Koulutusohjelman opiskelijoilla on yhteiset perus- ja aineopinnot sekä syventävät opinnot. Muut opinnot, kuten sivuaineet, suoritetaan oman
oppiaineen ja tiedekunnan vaatimusten mukaan. Myös tutkinnot ovat tiedekuntakohtaisia. Koulutusohjelmasta valmistuu humanististen tieteiden kandidaatteja, filosofian maistereita, kauppatieteiden kandidaatteja ja kauppatieteiden maistereita.

Koulutusohjelmasta valmistuneet opiskelijat työskentelevät mm. www-toimittajina, www-ohjelmoijina, teknisinä viestijöinä (projektipäälliköinä erilaisissa dokumentointiprojekteissa, visuaalisina suunnittelijoina, teknisinä kirjoittajina jne.).

Satakunnan ammattikorkeakoulu

Satakunnan ammattikorkeakoulussa (SAMK) liiketoiminnan ja kulttuurin alalla on kaksi koulutusohjelmaa, jossa käsitellään verkossa tapahtuvaa suunnittelu- ja tuotantotyötä:

Viestintä
Kuvataide

Koulutusohjelmien kuvaukset löytyvät yllä olevista linkeistä.

Oulun ammattikorkeakoulu

Alaan liittyviä koulutusohjelmia:

Viestintä
Tietojenkäsittely

Koulutusohjelmien kuvaukset löytyvät yllä olevista linkeistä.

Aalto-yliopiston taideteollinen korkeakoulu

Graafinen suunnittelu:
Opetusalueet kattavat graafisen viestinnän kaikki mediamuodot ja levityskanavat. Opiskelija saa valmiudet toimia erilaisissa alan työtehtävissä, kuten suunnittelijana, kuvittajana, taittajana, kirjagraafikkona, pakkaussuunnittelijana, mainosgraafikkona, informaatiosuunnittelijana sekä av- ja animaatiosuunnittelijana. Maisterin tutkinto kehittää valmiuksia konseptisuunnitteluun ja art director -tehtäviin sekä luo mahdollisuuksia tutkimuksen tekemiseen ja jatko-opintoihin siirtymiseen.

New Media ja Sound Design in New Media
(+ suuntautumisvaihtoehtona uusi Game Design and Production):
http://www.taik.fi/mela/ ja http://mlab.taik.fi/

Uuden median opetukseen ja tutkimukseen erikoistuneen Medialaboratorion opetusaloja ovat uusmedian sisältötuotanto, ‘tiedon design’, vuorovaikutteinen kerronta, virtuaaliympäristöt sekä tulevaisuuden mediaratkaisut.

Oulun Yliopisto

Oulun yliopistossa selkeiten digimedian kenttään osuvat seuraavat:

Tietotekniikka
Tietojenkäsittelytieteiden koulutusohjelma

Kajaanin ammattikorkeakoulu

Kajaanin ammattikorkeakoulussa on Suomen ainoa korkeakoulututkintoon tähtäävä koulutus pelikehityksen alalle. Lisätietoa koulutuksesta löytyy osoitteesta: http://www.kajak3d.com

Laurea-ammattikorkeakoulu

Digitaalisen median koulutusohjelma

Tietojenkäsittelyn koulutusohjelmasta valmistutaan tradenomiksi. Koulutus antaa valmiudet toimia laaja-alaisesti tietojenkäsittelytehtävissä. Mahdollisia tehtäviä ovat mm. verkkosivujen suunnittelu, ohjelmistokehitystyö, käytettävyystutkimus, visuaalinen suunnittelu, yritysviestinnän teknisten ratkaisujen kehittäminen.

Opintoihin kuuluu pakollisena osana niin tietojenkäsittelyn, liiketalouden kuin viestinnänkin perusopinnot. Verkkosivujen kehittämisen perusosaamista syvennetään ohjelmointiosaamisen sekä käyttäjäkeskeisen käyttöliittymä- ja ohjelmistosuunnittelun alueille. Osaaminen syvenee myös visuaalisen suunnittelun ja erilaisten mediaelementtien käytön osalta.

Eikä tässä kaikki…

Yllä oleva lista on vain pieni osa mahdollisista opiskelupaikoista Suomen rajojen sisäpuolella. Jos huomaat tutun oppilaitoksen tai koulutusohjelman puuttumisen listalta niin lisää sen tiedot kommentin yhteyteen. Miten on – Häämöttääkö sinulla edessä opiskeleminen vai joko koulut on käyty?

CSS3-transitiot esiteltiin käytännössä loppuvuodesta 2007 Safarin toimesta. Tuohon aikaan, niihin viitattiin termillä “CSS Animations”, mutta terminologia muuttui Safarin esitellessä omat selainkohtaiset ominaisuutensa, joita nykyään kutsutaan CSS-animaatioiksi.

Olen jakanut tämän aiheen kahteen artikkeliin. Ensimmäisessä artikkelissa käsittelen CSS3 Transitioita yleisesti. Lisäksi esittelen perustason käyttötapauksia muutamien CSS-arvojen avulla, joita voi hyödyntää CSS3-transitioita ja -transformaatioita luotaessa.

Tämä artikkeli sisältää myös viittauksia erinomaisiin CSS3-artikkeleihin. Joten artikkelin luettuasi, voit niiden avulla päivittää ja parantaa tietouttasi CSS3-transitioista.

Kuten jo totesin, aihe on jaettu kahdeksi artikkeliksi. Ensimmäisen osan nimi on “CSS3 Transitiot – olemmeko jo perillä?”, tarjoten yleisen katselmuksen CSS3-transitioiden tämänhetkiseen tilaan. Toisen osan nimi on “CSS3 Transitions – ongelmatilanteet ja ratkaisut”, joka pureutuu syvemmälle transitioihin ja niiden eroihin eri selainten välillä.

Ensimmäinen artikkeli rakentuu seuraavista osista:

• Kuinka päästä alkuun – mitä sinulta täytyy löytyä
• Perusteiden perusteet – mitä sinun on hyvä tietää transitioista
• Perusteet – mitä sinun täytyy tietää transitioista (demo-osio)
• Johtopäätökset – eli olemmeko jo perillä vai emme?
• Ulkoiset viittaukset – missä sinun kannattaa vierailla artikkelin luettuasi

Kuinka päästä alkuun

Alkuun päästäksesi tarvitset ainakin yhden selaimen, joka tukee CSS3-transitioita:

• Apple Safari (tuettuna Safari 3.1:sta ja iPhone OS 2.0:sta lähtien)
• Google Chrome
• Mozilla Firefox 3.7 alpha (tunnetaan myös Minefield:ina)
• Opera 10.5x (tuettuna myös Opera Mobile 10 beta 2)

Entä Internet Explorer?

Tällä hetkellä on ilmoitettu, että edes Internet Explorer 9 ei tule tukemaan CSS3-transitioita. Paras tuki Internet Explorerin transitioille ja transformaatioille voidaan luoda hyödyntämällä Matrix Filteria.

Lisäksi suosittelen lukemaan artikkelin Cross-Browser Animated CSS Transforms — Even in IE, jonka on kirjoittanut Zoltan “Du Lac” Hawryluk. Hän on myös cssSandpaperin luoja.

Perusteiden perusteet

Ikävä kyllä CSS3-transitioiden luomiseksi ei ole olemassa vain yhtä sääntöä. Itse asiassa, jokaisella selaimella on oma selainkohtainen tapansa kirjoittaa sääntöjä. Onneksi syötettävien arvojen syntaksi on eri selainten välillä keskenään samanlainen.

Mihin ominaisuuksiin transitiot vaikuttavat?

Valtaosa ominaisuuksista tukevat transitioita enkä lähde listaamaan niitä ykistellen. Selainten välillä on kuitenkin joitain eroja ja selkein niistä on tällä hetkellä se, että Firefox 3.7a ei tue ollenkaan transformaatioiden transitiointia.

Arvot transitioiden luomiseksi

Transitiot voidaan määritellä maksimissaan neljän eri arvon avulla:

Lyhyt muoto:

-webkit-transition: property_name duration timing_function delay;
-moz-transition: property_name duration timing_function delay;
-o-transition: property_name duration timing_function delay;
transition: property_name duration timing_function delay;

Voit myös määritellä jokaisen arvon yksityiskohtaisesti:

(Kohde)ominaisuus:

-webkit-transition-property: property_name;
-moz-transition-property: property_name;
-o-transition-property: property_name;
transition-property: property_name;

Kesto:

-webkit-transition-duration: duration;
-moz-transition-duration: duration;
-o-transition-duration: duration;
transition-duration: duration;

Kesto (kuten viivekin) voidaan syöttää joko sekunteina (esim. 0.5s) tai millisekunteina (esim. 500ms). On kuitenkin tärkeää huomata, että ilman määrettä transitio ei toimi laisinkaan.

(Liikkeen) ajoitus-funktio:

-webkit-transition-timing-function: timing_function;
-moz-transition-timing-function: timing_function;
-o-transition-timing-function: timing_function;
transition-timing-function: timing_function;

Käytössä olevat ajoitus-funktiot:

• cubic-bezier(cp1_x, cp1_y, cp2_x, cp2_y)
• ease – sama kuin cubic-bezier(0.25, 0.1, 0.25, 1.0).
• linear – sama kuin cubic-bezier(0.0, 0.0, 1.0, 1.0).
• ease-in – sama kuin cubic-bezier(0.42, 0, 1.0, 1.0).
• ease-out – sama kuin cubic-bezier(0, 0, 0.58, 1.0).
• ease-in-out – sama kuin cubic-bezier(0.42, 0, 0.58, 1.0).

Viive:

-webkit-transition-delay: delay;
-moz-transition-delay: delay;
-o-transition-delay: delay;
-transition-delay: delay;

Viive (kuten kesto) voidaan syöttää joko sekunteina (esim. 0.5s) tai millisekunteina (esim. 500ms).

Yleisesti ottaen transitiot kannattaa määritellä oletustason selektorille, ilman pseudo-luokkia. Tämän ansiosta transitio tapahtuu molempiin suuntiin, esimerkiksi vietäessä kursori elementin päälle ja pois elementin päältä.

Muista myös, että joudut syöttämään jokaisen ominaisuuden neljästi saavuttaaksesi kattavan selaintuen. Siksi on melkein aina parasta käyttää lyhyttä muotoa pitääksesi CSS-koodin siistinä.

Perusteet

Tässä vaiheessa on hyvä demonstroida muutamia transitioita. Sinun tulee joko viedä kursori elementin päälle tai klikata elementin alla olevaa painiketta, jotta transitiot toimivat.

Kaikki koodiesimerkit on kirjoitettu jättäen selainkohtaiset määritykset pois tilan säästämiseksi.

Perus-transitio: Ulottuvuudet ja skaalaaminen

Aloitan esimerkillä yksinkertaisimmasta transitiosta. Samalla tässä tulee demotuksi, mitä eroa on perusominaisuuksilla width+height sekä scale-transformaatiolla.

#widthHeight {transition:all 500ms;}
#widthHeight:hover {width:200px; height:200px; line-height:200px;}
#scale {transition:all 500ms;}
#scale:hover {transform:scale(2.0, 2.0);}

Kuten huomaat, leveys ja korkeus -arvot kasvattavat elementtiä normaalisti, mutta skaalaus vaikuttaa samoin kuin, jos elementti olisi suhteellisesti positioitu. Scale-transformaatiossa origo on keskellä, kun taas leveyttä ja korkeutta säädettäessä origo on vasemmassa yläkulmassa.

Transitio ajoitus-funktioilla

Alla on kaksi lohkoa, jotka pyörivät; ensimmäinen pyörii hyödyntäen linear ajoitus-funktiota käyttäen ja toinen käyttää ease ajoitus-funktiota.

#rotateLinear {position:relative; clear:both; left:0px; transition:all 2500ms linear;}
#rotateEasing {position:relative; clear:both; left:0px; transition:all 2500ms ease;}
#rotateLinear:target {left:200px; transform:rotate(360deg);}
#rotateEasing:target {left:200px; transform:rotate(360deg);}

Kuten luultavasti huomasit, elementtien liike oli keskenään erilaista, mutta itse transitio päättyy samaan aikaan (2500ms jälkeen).

Transitio viiveellä

Viiveestä on joskus hyötyä. Ja viiveen käyttöönottaminen transitioissa on vaivatonta:

#bgColorDelay {background-color:#12142B; transition:background-color 500ms linear 800ms;}
#bgColorDelay:hover {background-color:#336699;}

Peräkkäiset transitiot

Useita transitioita voidaan ajaa myös peräkkäin. Tälle ei ole olemassa mitään oletusarvoa, mutta “ketju” voidaan saada aikaiseksi hyödyntäen viivettä:

#widthHeightOpacity {transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}
#widthHeightOpacity:hover {width:200px; height:200px; opacity:0.1;}

Tässä on kuitenkin yksi miinus: transitio esitetään samassa järjestyksessä riippumatta siitä viedäänkö kursori elementin päälle vai pois sen päältä. Useimmissa tapauksissa, siinä ei ole mitään järkeä. Siksipä meidän tulee määritellä transitiot (aikaisempiin esimerkkeihin nähden) käänteisessä järjestyksessä:

#widthHeightOpacity {transition:width 500ms 1000ms, height 500ms linear 500ms, opacity 500ms linear;}
#widthHeightOpacity:hover {width:200px; height:200px; opacity:0.1; transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}

Muita transitioita?

Mahdollisesti on asioita, joita en tässä vaiheessa ymmärrä mainita. Mutta esimerkkien pääpaino on osoittaa kuinka yksinkertaista transitioiden käyttöönottaminen on (vaikka ne vaativatkin hieman lisätyötä kattavan selaintuen saavuttamiseksi).

Johtopäätökset

Olemmeko jo perillä? Kyllä, olemme ainakin yli puolen matkan. Transitiot ovat yleisesti ottaen todella tyylikkäitä, kunhan niitä käyttää oikeissa tilanteissa.

Olen kuitenkin henkilökohtaisesti hieman epäileväinen CSS3-transitioiden suhteen: tässä vaiheessa niihin ei voi täysin luottaa ja lisäksi ne vaativat läpikohtaista selaintestaamista. Tulen käsittelemään näitä ongelmakohtia seuraavassa osassa. Lisäksi tulen vertailemaan CSS3-transitioita Javascript-kirjastojen (tässä tapauksessa jQuery) tarjoamien animaatioiden välillä.

Jos kuitenkin olet tekemisissä alustan kanssa, joka hyödyntää puhtaasti WebKit:iä (kuten iPhone tai Adobe AIR) niin älä jää ihmettelemään, vaan ota kaikki ilo irti sekä CSS3-transitioista ja Webkit-animaatioista.

Ulkoiset viittaukset

Alla on listattuna hyviä viitteitä eri resursseihin, joita sekä selainvalmistajat että yksityishenkilöt ovat tuottaneet. Suosittelen ehdottomasti lukemaan ne.

• Safari CSS Visual Effect Guide: Transitions
• Mozilla CSS transitions – MDC
• Opera: CSS3 Transitions support in Opera Presto 2.3

• CSS3.info
• CSS3, Please! The Cross-Browser CSS3 Rule Generator
• CSS Fundamentals: CSS 3 Transitions | NetTuts+
• CSS Transitions 101 | Webdesigner Depot
• Going Nuts with CSS Transitions | 24 ways
• Safari CSS Visual Effect Guide: Animations

Kommentteja?

Kommentteja artikkelista otetaan mielellään vastaan. Lisäksi, jos sinulla on lähettää hyviä viitteitä CSS3-transitioita käsitteleviin artikkeleihin, niin näistä on varmasti suurta apua minulle ja lukijoille.

Kotisivujen jurakaudella kotisivubisnes oli totta tosiaan erilaista kuin tänä päivänä. Päivittäminen oli teknistä ja kallista puuhaa, joten sitä pyrittiin välttämään viimeiseen asti. Jos asiakas halusi sivuille päivitystä, täytyi pirauttaa mainostoimiston tekniselle kaverille, joka tuntihintaan lisäsi ajankohtaisen uutisen sinne, pilkun tänne.

Päivitystyötä helpottavien julkaisujärjestelmien esiinmarssi viimeisen kymmenen vuoden aikana on muuttanut tilannetta ratkaisevasti. Enää sisällönpäivityksessä ei ole kyse mustasta magiasta, vaan toimistot uskaltavat myydä asiakkailleen ihan oikeasti helppokäyttöistä ja käyttökelpoista päivitystyökalua. Kerrotaan järjestelmän eduista, ja luvataan että ”jos sulta tään Wordin ja Lärvikirjan käyttö onnistuu, niin osaat sää sitte tänkin, heh heh!”.  Hommanhan pitäisi olla nimenomaan näin, mutta kertoisiko joku miksi sitten niin moni julkaisujärjestelmällä varustettu sivu jää kaikesta tästä huolimatta päivittämättä?

Räätälöity tuote, only for you!

Eletään vuotta 2010. Voisiko olla, että hyvän ja elävän palvelun tuottamiseksi asiakas tarvitsisi muutakin apua kuin könttähintaan tuntien puitteissa pykätyn päivitysjärjestelmän? Jos asiakkaan asiakkaat ansaitsevat fiksut ja selkeät kotisivut, voisiko asiakas itse ansaita oikeasti helppokäyttöisen ja hänen tarpeitaan ajatellen säädetyn julkaisualustan? Saisiko asiakas peräti tietää, mitä kaikkea netissä voitaisiin ihan pienelläkin vaivalla tehdä?

Tulee ymmärtää, että lähes kaikki web-sivustoja päivittävät henkilöt tekevät päivitystä oman työnsä ohessa. Jokainen osaa konettaa käyttää, mutta kukaan heistä ei ole digialan ammattilainen. Jos yrityksen yhteystiedot muuttuvat, päivitetään uudet tiedot nettiin tietenkin vaikka hampaat irvessä, koska asia on niin tärkeä. Mutta mikäli päivityksessä jokin tökkii, ei aamupalaverissa pyydetä teknologiajohtajalta blogikirjoitusta, lisätä messuilmoitusta tai suunnitella kevätkampanjan esittelyä näyttävästi myös kotisivuilla.

Ihmiset innostuvat edelleen helposti nähdessään omaa kädenjälkeään julkiwebissä. Jos päivitys ei suju kuin tanssi, innostus hiipuu. Sivuston kehitystä ja päivitystyötä ei koeta tärkeäksi, jos se on hankalaa! Tämä korostuu eksponentiaalisesti silloin, kun asiakkaan ydinosaaminen ei rullaa webissä.

Onko julkkari aina vain julkkari?

Pieni pulma on siinä, että sanalla ”julkaisujärjestelmä” voidaan tarkoittaa lähes mitä tahansa. Järjestelmä voi olla WordPress, Joomla, Drupal tai digiyrityksen oma, vuonna 1999 lanseerattu ja sittemmin pintakuorrutettu muinaismuisto. ”Helppo päivitettävyys” voi tarkoittaa mitä tahansa. ”Yksinkertainen” voidaan käsittää usealla eri tavalla. Varsinainen ongelma tulee kuitenkin vastaan siinä, että edes käytetty julkaisualusta ei kerro vielä ollenkaan koko kuvaa lopullisesta tuotteesta. Ei edes valveutuneelle asiakkaalle, joka tietää eri järjestelmien erot ja ymmärtää omat tarpeensa täydellisesti!

Käsitteen hämäryys johtuu pitkälti siitä, että webbitoimistoissa julkkaritöitä tehdään monesti liukuhihnalta. Teknisen puolen kaveri vääntää yhden valmiiksi kuin kone, ja siirtyy sitten seuraavaan keissiin. Hommassa on sen verran kiire, ettei tekijää kiinnosta miten Maikki Mallikas 43v kokee työkalun nähdessään sen ensimmäisen kerran omalla koneellaan. Myynnin Pena hoitaa koulutuksen, mä teen niinku ennenki että sekin tajuu. Tekijän mielipide on se, että hommahan selvästi toimii – näin helppoa se on, katsokaas – ja se saa luvan riittää. Näitä on tullut tehtyä viime vuosina monia, ja valituksia ei ole kuulunut. Teen siis hyvää työtä.

Kuitenkin massatuotannossa käy usein niin, että julkaisujärjestelmään jää näkyville sellaisia toimintoja, joita ei yksittäisissä tapauksissa käytetä. Voikohan asiakkaalla mennä sormi suuhun? Mitähän nuo tiedostokategoriat ovat? Entä avainsanat? Keskustelun asetukset? Ei tällaisesta koulutuksessa puhuttu…

Asiakas ei ymmärrä, ja kokee ettei käsitä työkalusta kaikkea. Epävarmuus iskee aivan turhaan.

Harmi kyllä päivitystyökalujen ongelmat harvoin rajoittuvat vain siihen, että ylimääräistä informaatiota ei ole karsittu pois. Usein myös ominaisuudet toteutetaan tavalla joka kyllä toimii, muttei välttämättä ole kaikkein intuitiivisin. Budjetit ovat rajalliset, ja siitä syystä asioita ei ole varaa pyöritellä kaiken aikaa, vaan mennään siitä mistä aita on matalin. Mennään sieltä mistä on aiemminkin menty. Onko näin toimiminen kaiken aikaa järkevää bisnestä?

Sivujen koostajana paljon töitä tehneenä minua aina masentaa, kun poikkean kuukausia aiemmin toteuttamalleni saitille vain huomatakseni, että ensimmäisen ”Sivusto on julkaistu”-viestin jälkeen ajankohtaispalstalle ei ole ilmaantunut mitään. Viimeisin päivitys mihinkään on tehty viikko sivujen julkaisun jälkeen. Tiedän että sivut on kyllä maksettu, olen saanut palkan ja asiakas on ollut niihin ilmeisen tyytyväinen. Mutta väkisinkin mieleen hiipii ajatus: eikö tehtäväni alan ammattilaisena ole nimenomaan auttaa asiakasta kommunikoimaan webissä omien asiakkaidensa kanssa? Enkö ole jossain suhteessa tässä tavoitteessani nyt epäonnistunut?

Asiakasko tietää mitä tahtoo?

Kun asiakas hakee kotisivuilleen uutta ilmettä ja tyyliä vuonna 2010, hän hakee myös apua kiinnostavan sisällön tuottamiseen ja kävijöiden houkutteluun, ymmärsi hän sitä itse tai ei. Mainostoimisto ei useastikaan voi tuottaa asiakkaan sivujen sisältöä, vaan aloitteen on tultava asiakkaalta itseltään. Toimisto voi kuitenkin ehdottomasti miettiä tapoja opettaa asiakasta aktivoimaan kotisivuissa piilevät voimavarat.

On molempien tahojen yhteinen etu, kun asiakkaan web-presenssi elää ja voi hyvin. Tulee käsittää, että harva asiakas todella ymmärtää internetin mahdollisuuksia tiedonjakokanavana, varsinkaan jurojen punastelijoiden luvatussa maassa, Suomessa. Web on hieno asia! Asiakasta tulee innostaa kantamaan oman kortensa kekoon! Mikään ei ole typerämpi sijoitus kuin nettisivut, joilla ei ole mitään eikä koskaan vieraile ketään.

Kokemani perusteella web elää erittäin nopeasti, mutta asiakkaille suuremmat mullistukset tulevat aina pienellä viiveellä. Ennen riittivät pelkät näyttävät sivut, sitten keksittiin myydä päivitettävyyttä ja rich mediaa. Tärkein asia tästä hetkestä ikuisuuteen on kuitenkin sisältö. Ehkä seuraavaksi myytäisiinkin apua sisällöntuottoon?

Niin, tai ehkä ei. Se on aika vaikeaa hommaa. Emmä kyllä tiedä mitä meidän asiakkaat oikeasti haluu.