Selaimen käyttöliittymä katoaa sovellusten webissä

Firefox 4:n visio selaimen käyttöliittymästä tekee selvän eron sovellusten ja dokumenttien webin välille. App tabs -nimellä kulkeva nykyinen laajennus ja tuleva sisäänrakennettu toiminnallisuus näyttää web-sovellukset vain faviconin levyisinä, pysyvinä tabeina palkin vasemmassa laidassa.

App tabit käytössä hypoteettisessa karttasovelluksessa

Seuraavalla videolla Firefoxin UX-tiimi esittelee, miksi osoiterivi siirtyy oletuksena tabien alle ja samalla nähdään myös monta muuta mielenkiintoista käyttöliittymäratkaisua.

Video YouTube:ssa, videoon liittyvä kirjoitus ja still-kuvia Alex Faaborgin blogissa.

Sovellusten webissä monet dokumenttien webissä olennaiset käyttöliittymäelementit käyvät tarpeettomiksi tai ainakin vähemmän tärkeiksi. Osoiterivillä ei ole merkitystä. Navigaatiopainikkeita (back, forward, stop, reload) ei juuri tarvita. Selaimen menut ovat harvoin tarpeen. Sen sijaan web-sovellus tarvitsee ehkä oman menunsa. Tästä kaikesta seuraa, että sovellusten webissä selaimen käyttöliittymä on vain tiellä ja siitä on päästävä eroon.

Toisaalta selaimesta tulee vähitellen sama asia kuin käyttöjärjestelmän graafisesta käyttöliittymästä, sillä mihin enää tarvitaan ikkunoitua käyttöliittymää, kun kaikki tehdään yhden sovelluksen – selaimen sisällä?

Mikä on taskbarin tai dockin kohtalo? Pystyvätkö Microsoft ja Apple tekemään näin radikaalin siirtymän työpöytäkäyttöliittymissään vai tuleeko muutos mobiililaitteiden yleistymisen kautta? Veikkaan jälkimmäistä.

Olen pitkään ollut sitä mieltä, että ikkunoidun käyttöliittymän täysipainoinen hyödyntäminen vaatii useimmilta ihmisiltä liikaa kongitiivista kapasiteettia. Tämä osaltaan selittänee iOS:n ja iPadin menestystä, koska vain yksi aktiivinen sovellus kerrallaan on optimaalisinta meille moniajoa osaamattomille lihakimpaleille. Ongelmaa vain pahentaa, että selainsovellusten välillä vaihdetaan eri tavalla kuin natiivisovellusten välillä. Siksi siirtymävaihe voi tuottaa monille ylimääräistä päänvaivaa, jos kokonaan uudet tablettikäyttöjärjestelmät eivät yleisty riittävän vauhdikkaasti.

Toivottavasti pian alkaa löytyä myös oikeita ratkaisuja välilehtikäyttöliittymien tehokäyttöongelmiin: yli kymmenen tabin hallinta menee jo hyvin hankalaksi. App tabs on loppujen lopuksi vain väliaikaisesti helpottava ratkaisu.

Webin kolme ulottuvuutta

Viime päivinä olen miettinyt, voisiko webin sivustoja tai palveluita luokitella näiden kolmen ulottuvuuden kautta:

Venn-diagrammi, jossa kolme toisensa leikkaavaa ympyrää. Ensimmäisessä ylimmässä lukee ”Sosiaalinen web”, toisessa ”Dokumenttien web” ja kolmannessa ”Sovellusten web”
Lataa kuva: SVG, PNG

Dokumenttien web tai dokumenttikeskeinen web on se webin alkuperäinen käyttötarkoitus: alusta hypertekstin julkaisemiselle. Dokumenttien esittämiseen, etsimiseen, jakamiseen ja tallentamiseen on web ylivoimainen alusta ja kehittyy siinä edelleen.

Kaksi muutakin ovat olleet mukana melkein alusta alkaen, mutta vahvistuneet merkittäviksi vasta viimeisen puolen vuosikymmenen aikana. Sovellusalustana web on palvellut hyvin varhaisesta ajasta lähtien, mutta Google Mapsista ja Gmailista lähtenyt kehitys on ollut huimaa, ja työn tulokset tunnetaan nyt brändinimellä HTML5. Sosiaalisesta webistä puhutaan välillä liikaakin, mutta sen merkittävyyttä useimmiten silti aliarvioidaan.

Verkkopalvelun tai verkkostrategian taustalla on usein useampi kuin yksi näistä ulottuvuuksista. Vahvasti jotain ulottuvuutta edustava verkkopalvelu saattaa kuitenkin mausteena hyödyntää muita ulottuvuuksia. Isojen toimijoiden verkkopalvelut edustavat usein varsin tasaisesti kaikkia ulottuvuuksia. Kuvassa ympyrät voisivat mennä varmaan enemmänkin lomittain, mutta sitten se ei olisi enää niin nätti Venn-diagrammi.

Mieti, mihin kohtaan sijoittaisit Wikipedian, Diggin tai vaikka Engadgetin.

En varmasti ole ensimmäinen, joka tällaista miettii, mutta enpä muista itse vastaavaa nähneeni. Muistaako joku lukijoista?

Onko luokittelu riittävän kattava? Vai herääkö ihan muita ajatuksia?

Miten DHTML-widgettien tulisi toimia näppäimistöllä käytettynä

The DHTML Style Guide Working Group (DSGWG) has come together to create a recommendation for keyboard shortcuts to be used in website widgets. We realize that many keystrokes are already in use by various operating systems, user interfaces, and assistive technology. Therefore our task is to recommend the best, most intuitive, most international friendly shortcut keys possible without regard to their current use. It is hoped that developers, AT vendors, and Browser manufactures will use these as guidelines, but understand it may not be practical or possible given their individual constraints.

dev.aol.com/… →

Vaikeat verkkosovellukset

Verkkosovellukset ovat monella tapaa haastava juttu. En koskaan lakkaa hämmästelemästä sitä välinpitämättömyyden määrää, mitä joka päivä joudun webissä kohtaamaan. Tarkastelen tässä tavallisia verkkosovellusten sudenkuoppia. Ai mikä on verkkosovellus? Se on verkkosivusto, joka hyödyntää palvelinpään ohjelmointia. Luokittelisin siis kaikki ei-staattiset sivustot sovelluksiksi.

Verkkosovellukset ova haastavia siksi, että ne ovat syntyneet melkein suunnittelematta, webin suosion luontevana jatkona. Niitä on opittu rakentamaan aikana, jolloin web muuttui lähes joka päivä. Tilanne on nyt radikaalisti toinen, kehitys on lähes pysähtynyt. Nyt on jo korkea aika unohtaa jollekin tietylle selaimelle ohjelmointi ja keskittyä standardien noudattamiseen.

JavaScript ja JavaScript tappelivat, kumpi voitti? Kaikki hävisivät

WWW toimii mainiosti, kun dokumenttimuotoista tietoa (hypertekstiä) selataan. Yksinkertaiset haku- ja palautelomakkeet mahtuvat mukaan melko luontevasti, mutta ongelmia tulee niissäkin jo tavanomaisessa pakollisten kenttien tarkistuksessa. Tämä johtuu tietysti JavaScriptista, joka toimii vähänkin vanhemmilla selaimilla kovin epäyhtenäisellä tavalla, jos lainkaan. JavaScriptiin varaan siis ei voi laskea yhtään mitään olennaista, jos haluaa, että sovelluksesta tulee mahdollisimman saavutettava. Ja miksei haluaisi?

Tämä ei tietenkään tarkoita sitä, että JavaScriptiä ei voisi käyttää, sitä on vain käytettävä toisarvoisiin toimiin, joita ilman verkkosivut ovat täysin käyttökelpoiset. Google ei ole samaa mieltä, vaan on rakentanut Gmail-sovelluksen, joka hyödyntää mm. JavaScriptiin (ECMAScript) kuulumatonta IE:n XMLHttpRequest ActiveX -objektia tai Mozillan XMLHttpRequest-objektia. Tällä saavutetaan sovelluksessa varsin vähän, lähinnä joka toinen sivulataus ei tavallisen puolen sekunnin sijaan vie lainkaan aikaa. Ottaen huomioon, että tätä varten sisään kirjauduttessa odotellaan useamman sekunnin ajan JavaScript-kikkareiden latautumista, saavutettu hyöty on jossain minimaalisen ja negatiivisen välillä. Tämän takia kaikista maailman selaimista vain kolme (Win-IE:t, Mozilla-pohjaiset ja Safari) kelpaa Googlelle.

Googlen valintaa perustellaan sillä, että Gmail ei ole perinteinen verkkosivu vaan sovellus, joka nyt vain sattuu toimimaan selaimissa. Perustelu olisi jotenkin hyväksyttävissä, jos Gmail saavuttaisi jotain poikkeuksellista hyötyä selainkohtaisten toimintojen hyödyntämisellään. Koska se ei sitä tee, menettää argumentti merkityksensä.

On ironista, että itse Googlen päätuote, hakukone, olisi Gmailin sivuilla täysin hukassa. Mikä onni, että palvelu vaatii sisäänkirjautumisen! Kummallista on myös, että Googlen Blogger-porukka on saanut kasaan erittäin kelvon verkkosovelluksen, joka hyvin pienillä korjauksilla toimisi vaikka vanhoilla Netspaceilla. Tuota ammattitaitoa ei selvästi ole osattu jakaa.

Suurin syy vältellä JavaScriptin käyttöä ei edes ole sen vaihteleva selaintuki. Aikana, jolloin tietoturva-aukkoja etsitään ja hyödynnetään kiihtyvällä tahdilla on jatkuvasti hetkiä, jolloin aukko on löytynyt muttei vielä paikattu. Usein aukkojen hyödyntämistä ei voi estää kuin kytkemällä kaiken aktiivisen sisällön JavaScripteineen pois päältä. On siinä selittelemistä, kun toimenpiteen jälkeen verkkokaupasta ei voikaan enää ostaa mitään.

Hooämteeäl vai mikälie

JavaScript ei ole ainoa ongelma. Jo niinkin perusasia kuin HTML tuottaa monille sovellusten rakentajille vaikeuksia. Ylimääräisen javascriptauksen pois jättäessään Google ottaisi menettävänsä nopeushyödyn helposti takaisin siistimällä HTML:äänsä. Se sisältää nyt antiikkista font-size-table-kakka-HTML:ää, sivuun sisällytettyä CSS:ää ja JavaScriptiä ja muuta massiivisin turhaa tavaraa, jota liikutellaan putkea pitkin ilman mitään järkevää syytä. Googlen tavaramerkkiulkoasu on niin askeettinen, ettei sen kuvaaminen puhtaalla CSS:llä tuottaisi edes amatöörille vaikeuksia.

Jäljestä päätellen tyypillinen Visual Studion designeriä käyttävä ASP.NET-koodaaja ei edes katso kehittimen tuottamaa HTML:ää. Yllättävän monet ohjelmoijat pitävät HTML:ää merkityksettömänä yksityiskohtana, suorastaan häpeällisenä pakkopullana, jota ei kehtaa opetella ainakaan alkeita enenpää. Mahtaako se johtua siitä, että HTML:ää vääntävät eivät ole uusmediakuplan pamahdettua kovassa huudossa, en osaa sanoa.

HTML kuitenkin on tärkeä. Siihen vähän huomiota kiinnittämällä tehdään sovelluksesta kuin sovelluksesta melkein millä tahansa selaimella käytettävä ja sutjakkaasti latautuva. Jokaisen web-ohjelmoijan tulisi osata vähän enemmän kuin perusasiat HTML:stä. CSS:n vääntämisen voi jättää visuaalisesti lahjakkaammille, ja keskittyä dokumentin rakenteen kuvaamiseen. Sen ohjelmoija osaa, jos kuka.

Näinhän se tehdään, eikö?

Kolmas tyypillinen ongelma on, että web toimii niin kovin eri tavalla kuin käyttöjärjestelmän työpöytä. Se mitä käyttäjä näkee ei olekaan koko ajan ohjelmoijan hallittavissa. Työpöytäsovelluksia tehneen on vaikea hyväksyä sitä, että kun sivu on latautunut selaimelle se pysyy siellä kunnes käyttäjä tekee jotain. ASP.NET:in kiero Web Forms -malli koettaa piilottaa webin todellisen olemuksen käväisemällä palvelimella joka välissä. Ajatus on nokkela, mutta tuloksena on ongelmia, joita olen monta kertaa jo käsitellyt. Riittänee, että sanon, ettei ymmärtämättä syvällisesti webin toimintatapaa voi ASP.NET:in kanssa tehdä hyväksyttävää jälkeä.

Yksi työpöytäajattelun muoto ovat popupit ja varsinkin niiden ajattelematon käyttö. Popup-blokkereiden räjähdysmäinen kasvu Windows XP SP2:n myötä onneksi pakottaa edes osittain luopumaan moisista käytönvaikeuttajista. Silti vielä monet merkittävät suomalaiset sivustot hämmentävät käyttäjää rikkinäisellä toiminnallisuudellaan.

Webin toimintatapaa ei kannata ajatella esteenä. Sen kiertämiseen ei kannata käyttää kauheasti energiaa, koska samalla helposti rikkoo toiminnallisuuden joillakin selaimilla. On osattava tunnustaa, että joidenkin asioiden tekeminen verkossa ei välttämättä onnistu mitenkään järkevästi. Kenties sovelluksen tekeminen verkkoon ei silloin ole hyvä ajatus ollenkaan. Toisaalta myös hankalaa tapausta kannattaa miettiä toisenkin kerran, josko webille luonnollisempi toteutustapa tulisi mieleen vasta toisella yrittämällä.

Kaikki verkkoon materiaalia tuottavat sisällöntuottajasta ohjelmoijaan ovat vastuussa siitä, että tuotos toimii parhaalla mahdollisella tavalla verkossa. Aivan kuten verkkokirjoittamisessa on otettava huomioon verkko mediana on web-ohjelmoijankin mietittävä tarkkaan mitä käsistänsä päästää. Webissäkin pitäisi ottaa käyttöön lehdistä tutut apinalaatikot, jotta vastuullisia olisi helpompi hauk… öö.. valistaa.