Muropaketti:
Microsoft on ollut viimeksi vastaavassa tilanteessa Windows 3.11 -käyttöjärjestelmänsä kanssa.
Web-sovellukset toimivat paremmin ilman selainta
Webin toisella kultakaudella kokonaan uusia sovellustyyppejä ilmaantuu verkkoon kuin sieniä sateella. Vähänkin aktiivisempi webin käyttäjä on pian pulassa selaimen välilehtiviidakossa.
Minulla kesti pitkään tajuta, miksi työpöytäsovellus on lopulta parempi vaihtoehto kuin 15 avointa välilehteä. Satunnaiseen käyttöön web-liittymä vielä menee, mutta kun sovelluksia alkaa olla enemmän, ei selaimen käyttöliittymä enää veny.
Sivujen selailu ja sovellusten käyttö ovat kaksi eri käyttötapausta, vaikka protokollat ovatkin samat. Käyttöjärjestelmien käyttöliittymät on suunniteltu usean yhtäaikaisen sovelluksen käyttöön. Selaimen välilehdet ovat äärimmäisen alkeellinen käyttöliittymä sovelluksesta toiseen vaihtamiseen. Havainnollinen alt-tab-yhdistelmä, Exposé, tiedostojen raahaaminen ikkunoihin, kaikki nämä ja monta muuta ovat mahdottomia selainsovelluksille.
Selaimen välilehtien käyttö muuttuu hyvin hankalaksi kun avoimien välilehtien määrä lähentelee kymmentä ja painajaiseksi tämän jälkeen. Jatkuvasti avoinna olevat sovellukset syövät näitä arvokkaita paikkoja tehosurffaukselta.
Vielä pahempi ongelma ovat käyttäjät, jotka eivät osaa hyödyntää välilehtiä. Kymmenen avointa selainikkunaa ja “mikäs se Facebook näistä olikaan, en löydä, avaanpa uuden ikkunan” -syndrooma on tuttu näky, kun vierailen monien työpisteillä. Heille erillissovellukset eivät ole ratkaisu, koska ne vaativat perehtyneisyyttä ja kokeiluhalua. Ehkä ongelman ratkaisisi jos www-sovellus voisi kommunikoida selaimelle olevansa sovellus. Selain voisi tällöin ehdottaa sivuston rekisteröintiä omaksi sovelluksekseen, joka toimisi yhdessä, kenties sovellukselle kevyesti mukautetussa, selainikkunassa.
Jo nyt Fluid tarjoaa JavaScript-rajapinnan www-sovelluksen ja Fluid-sovelluksen väliseen kommunikointiin. Laajentamalla ideaa yhden klikkauksen sovelluksen generointi olisi mahdollinen. Jo tällaisenaan vielä buginen ja muutenkin keskeneräinen Fluid on silti jo varsin käyttökelpoinen. Olen käyttänyt Gmailia muutaman viikon sen kautta menestyksekkäästi. Fluidin suurin hyöty on sovelluksissa jotka eivät tarjoa rajapintaa tai joille ei ole kunnollista työpöytäsovellusta olemassa.
Bloggaaminen onnistuu OS X:ssä Marseditillä ja Windowsissa Windows Live Writerillä. Marsedit on tätä kirjoittaessa kokeilussa ja todennäköisesti tulee hankittua.
Sähköpostia voi tietenkin lukea millä vain sähköpostiohjelmalla. IMAP-tuki on tässä palveluntarjoajalta aika ehdoton vaatimus.
Syötteiden lukemiseen aivan ehdottoman loistavaksi olen havainnut NewsGatorin NetNewsWiren. Nykyään ilmaisena sitä ei kannata jättää kokeilematta. Windowsissa saman firman asiakasohjelma on FeedDemon, joka sekin on erinomainen sovellus. Google Readeria, Bloglinesia ja kumppaneita voi tietysti käyttää selaimessa, mutta varsinkin vähän isommalla syötemäärällä en vaivautuisi.
Twitter, Jaiku ja vastaavat eivät ole saaneet minua vielä innostumaan, mutta näille löytyy myös omat sovelluksensa. Deliciousiin ja muut sosiaalisiin kirjanmerkkipalveluihin samoin.
Unohdinko jonkin oleellisen www-sovellustyypin? Tiedätkö jonkun erityisen hyvän työpöytäkäyttöliittymän jollekin web-sovellukselle?
Safari 3 Windowsille
Ihan kiva, mutta miksi ihmeessä?
Tarkemmin ajatellen en keksi kuin yhden syyn. Apple yrittää varmistaa, että kiihtyvällä tahdilla kehittyvät WWW-sovellukset testataan myös heidän selaimellaan. Monen Windowsia käyttävän kehittäjän mielessä selainriippumattomuus tarkoittaa Firefox-tukea — huolestuttava trendi aikana jolloin työpöytäsovellusten valtakausi alkaa hiipua.
Käyttämättömät kuvakkeet
Henri Sivonen: Unused Icons. Tarina Windowsista ja IE:stä.
Hyviä uutisia
Päivän uutisia lukiessa ei voinut olla toivomatta olevansa Microsoft-onnelassa PDC-tapahtumassa. MS julkisti paljon mielenkiintoisia asioita sekä tulevasta Windowsista, Longhornista että Visual Studio .Netin ja .Netin 2.0-versiosta, Whidbeystä. Kaikki Longhorn-hypen on tietysti mukavaa kuultavaa, mutta todellisuudessa mielenkiintoisinta on Whidbey. Klassinen Steve Ballmerin räppi tulee vääjäämättä mieleen näitä lukiessa.
Vihdoinkin ASP.NET järkevöityy siten, että kääntämisrumbasta päästään eroon. Tämä tapahtuu uudella codebeside-mallilla, jossa vanhasta codebehind-mallista luovutaan. Kuvauskieli ei enää perikään kooditiedoston Page-implementaatiota vaan nämä kaksi ovat osa samaa luokkaa, vaikkakin edelleen eri tiedoistoissa. Sivutuotteena ainaisesti epäsynkronissa olevista ja muutenkin turhaa kirjoitustyötä vaativista kaksinkertaisista objektien määrittelyistä päästään eroon. Ei kauniin OOP:n mukaista, mutta tehokasta.
Whidbeyn panostaa muutenkin kääntämisen vähentämiseen. Tutun bin-hakemiston kumppaniksi esitellään uusi code-hakemisto. Se nimensä mukaisesti nielee lähdekoodia joka käännetään vasta sovellusta ajettaessa. Ja jotta loppukäyttäjä ei kärsisi kehitystyön helpottumisesta, esitellään uusi tapa kääntää ennalta kaikki web-sovelluksen kooditiedostot (aspnet_compiler.exe).
Kymmeneen kertaan kopiotu HTML vähenee uuden Master Pages -tekniikan avulla. Käytännössä sillä korvataan vanhan ASP:n includet isäsivulla, jota eri toiminnallisuutta tarjoavat sivut käyttävät. Yhtenäisen ulkoasun ylläpitäminen on siten jatkossa huomattavasti helpompaa. Kevyeen kehitystyöhön on tarjolla uusia tapoja yhdistellä dataa kontrolleihin entistä vähemmällä tai jopa täysin ilman koodia.
IDE:n tulevat ominaisuudet vaikuttavat myös lupaavilta. Varsinkin versionhallintaa käyttävässä monen ohjelmoijan ympäristössä ongelmallisista projekti- ja solution-tiedostoista päästään eroon. Visual Studio tulee sisältämään oman kehitystyöhön tarkoitetun web-palvelimen joka vastaa vain koneen sisältä tuleviin sivupyyntöihin. Paketti sisältää pitkään paikallaan polkeneen SourceSafen uuden 2004-version, joka arvatenkin pohjautuu SQL Serveriin.
Kaikkien hyvien ideoiden lisäksi on aina oltava huonojakin. Kehnoimmalta kuulostaa idea adaptereista, joilla voidaan palvella erilaisia asiakasohjelmia tarjamalle niille erilaista kuvauskieltä. Tämä johtaa aivan väärälle tielle. Oikea tie on tarjota selaimesta riippumatta mieluummin taulukotonta XHTML:ää.
Mainitsematta jääneet asiat ilman turhaa kritiikkiä voi lukaista MSDN:n sivuilta (toimimaton linkki poistettu 9.7.2009). Pakollista luettavaa ovat myös vasta julkistetut, mutta jo vanhaa tietoa olevat C# 2.0:n speksit (toimimaton linkki poistettu 9.7.2009).