Kategoria: Datailu

Applen OS X -käyttäjärjestelmän tuorein versio, 10.7 Lion, julkaistiin kesällä. Kantavana teemana on mainostettu mobiililaitteiden iOS-käyttöjärjestelmän parhaiden ominaisuuksien tuomista myös työpöytäkäyttöön. Siinä missä 10.6 keskittyi lähinnä konepellin alla oleviiin parannuksiin, niin Lion sisältää myös merkittäviä UI-muutoksia. 

Päivitin itse Lioniin pian julkaisun jälkeen niin koti- kuin työkoneellakin, joten ajattelin kirjoittaa hieman huomioistani muutaman viikon käytön jälkeen. 

Käyttöliittymä

Applen myymistä tietokoneista suurin osa on kannettavia, josta voidaan tehdä kaksi huomiota:

• trackpad on paljon yleisempi kuin perinteinen hiiri
• näytön koko on rajallinen (yleisimmät koot lienevät 13,3” - 15.4”, resoluutioiden ollessa 1280x800 ja 1440x900)

Trackpadin mahdollistamia kosketuseleitä onkin lisätty entisestään. Safarissa zoomaus tapahtuu tutulla pinch-eleellä, edelliselle sivulle pääsee kahden sormen swipellä (animaation seuratessa pyyhkäisyä pehmeästi). Eri työpöytien välillä liikkuminen kolmen sormen swipellä tuntuu erityisen nautinnolliselta, vaikka käytännössä cmd-tabilla sovellusten välillä tulee edelleen liikuttua.

Toivoa sopii, että myös muut kuin Applen omat sovellukset ottavat täyden hyödyn irti kosketuseleistä.

Oletuksena skrollaus toimii samalla tavalla kuin iOS:ssä, eli juuri toisinpäin kuin läppäreillä yleensä. Eli kun pyyhkäiset ylöspäin, niin ruutu skrollaa alaspäin. Tähän tottuu yllättävän nopeasti, noin parissa päivässä.

Käyttöliittymässä suunta kohti mahdollisimman pelkistettyä esitystapaa. Vierityspalkit ovat piilotettu oletuksena kokonaan: ne tulevat esiin vain kun sivua alkaa vierittämään. Tämä toimii pääosin hyvin, joskin välillä on vaikea havaita, että jokin laatikko esim. nettisivulla onkin vieritettävä.

Tuki koko ruudulla toimiville sovelluksille on ajatuksena hyvä, mutta käytännössä homma ei toimi. Ensinnäkin lisäpikseleitä saa yleensä käyttöön vain näytön ylälaidan menubarin verran, jos Dock on automaattisesti piilotettuna. Toisekseen koko ruudun tilassa ohjelmilla on typerä tapa avata uudet ikkunat modaaleina (kuten iPadissa), jolloin muita sovelluksen ikkunoita ei voi käyttää. Esimerkki: Mail-ohjelman uusi viesti -ikkuna avautuu modaaliin dialogiin, jolloin käyttäjän on mahdotonta kopioida toisesta sähköpostista osoitetta CC-kenttään.

Pages-tekstinkäsittelyohjelmassa full screen on parhaimmillaan: ruudulla ei oikeasti näy kuin dokumentti ja musta tausta. Voit keskittyä vain tekstiin.

Itse haluaisin menubariin samanlaisen autohiden kuin Dockissa, onkohan tämä mahdollista mitenkään?

Työpöytien hallinta on muuttunut. Spaces ja Expose on yhdistetty, jonka myötä nyt puhutaan Mission Controllista. Työpöydät eivät ole enää gridissä, vaan liikkuminen tapahtuu vain vasemmalle ja oikealle. Työpöytien järjestystä ei myöskään voi oletuksena muuttaa, vaan ne järjestyvät hämäävästi automaattisesti. Minulle ei ole vieläkään täysin selvää, millä logiikalla työpöytien järjestäminen toimii.

Valitettavasti työpöytien hallintaan liittyy bugeja:

• eri työpöydillä olevien ohjelmien välillä siirryttäessä (cmd+tab) näkymä saattaa siirtyä joskus työpöytään, missä ohjelmaa ei ole
• vastaavasti joskus näkymä siirtyy kyllä oikeaan työpöytään, mutta focus ei siirry valittuun ohjelmaan (valittu sovellus jää toisen ohjelman ikkunan alle)
• dialogit saattavat avautua väärälle työpöydälle, hautautuen muiden ohjelmien ikkunoiden alle

Käsittämätöntä näissä bugeissa on se, että ne olivat jo 10.6:ssa, eikä niitä ole vieläkään saatu korjattua.

Safari 5.1

Safari-selain päivittyi Lionin myötä versioon 5.1, enkä ole vakuuttunut. Selain jäätyilee lähes päivittäin -- ei kaadu, mutta menee jumiin 10 sekunniksi. IOS-tyyliin vanhojen välilehtien sisältö ladataan uudestaan, kun focus siirtyy niihin. Ilmeisesti tällä pyritään säästämään muistia. En pidä ominaisuudesta iPhonessa, ja vielä vähemmän läppärillä. Safarin kaatuessa ensimmäisen kerran huomasi myös App resume -featuren käytännössä: kesti ikuisuus, kun Safari latasi auki olleet ikkunat ja kymmenet välilehdet käynnistyessään.

Osaksi pelkistämiseen pyrkivää kehityssuuntaa voinee laskea Safariin jo aikaisemmin tulleen Reader-toiminnon, joka poistaa nettisivusta kaiken muun paitsi otsikon ja leipätekstin. 

Muita lyhyitä huomioita

• ei huomattavaa nopeusparannusta (testikoneet mid 2009 ja early 2011 MacBook Prot)
• animaatiot nykivät yllättävän usein molemmilla testikoneilla
• terminaalin asetuksia joutui jälleen puukottamaan, jotta merkistöt toimivat oikein
• developer toolit piti asentaa uudestaan (kääntäjät, GIT, jne)
• Finderissä on vihdoin cut+paste (joskin hyvin piilotettuna). Vihdoin. Vuonna 2011.
• koneen herätessä unesta langattomat verkot saattavat tulla näkyville vasta pitkän viiveen jälkeen. 10.6:ssa tätä ei tapahtunut koskaan.
• etc/hosts tiedostoa ei lueta enää ensimmäisenä DNS-kyselyssä. Web developerit ei tykkää.

Yhteenveto

Vaikka toinkin monia puutteita esiin, niin Lion on silti mainio käyttöjärjestelmä. Vaikka osa uudistuksista onkin hieman ongelmallisia, niin kaiken kaikkiaan isoja ja pienempiä parannuksia on niin paljon, että en näe mitään syytä olla päivittämättä.

Mielenkiintoisena kysymyksenä voidaan lopuksi esittää, miten paljon käyttöjärjestelmällä ja käyttöliittymällä nykyisin on peruskäyttäjälle edes merkitystä? Suurin osa käytöstä tapahtuu kuitenkin selaimen kautta.

Views must be one of the most used contributed module for Drupal. It’s kind of a SQL query builder that allows you to make various kinds of listings of your data. For example, a list of the most recent blog posts is really easy to build with Views.

You can select whether the rows are printed as a table, a list or just a bunch of divs/spans after each other. When it comes to markup of individual fields, things can get a little bit trickier.

To make CSS styling more easier it helps to have a wrapper element around the fields. Usually this is when you want to float a group of elements correctly.

Let's say that for each row we have three fields called field_1, field_2 and field_3. By default, the view style is unformatted and each field has a div-wrapper around it:

We would like to have a wrapper element around the field_2 and field_3. How can we achieve this? We could play with the template files, but many times I find it more straightforward to use replacement patterns, also known as tokens.

Select field_3 and click Rewrite the output of this field. Now you can see the replacement patterns that are available for use:

Remember that there are tokens only for fields that are displayed before this field! If you go to look tokens available for field_2, there isn’t a token for field_3. This is really important and may be a bit confusing in the beginning. Use the field rearrange feature if needed.

So, now that we have selected the field_3, we can use all the tokens and rewrite the output as we like. I’m just going to add a new div with class “wrapper” around the fields:

I want to avoid outputting field_2 twice. So click field_2 and check Exclude from display. After this we can see the final output with a nice wrapper around field_2 and field_3:

With this method you have almost full control over your markup and you don’t need to modify any template files. Just exclude all fields from display (not the last one, of course) and rewrite the output of last field using tokens.

This example has been tested with Drupal 6.19 and Views 6.x-2.11.

Nyt kun blogini on jokusen kuukauden ollut linjoilla, niin voisin kertoa hieman sivuston syntymisestä tekniseltä kantilta. 

Tämä oma sivustoni on selkeästi blogi, joten alustaksi Wordpress olisi ollut standardi-valinta, mutta olen viime aikoina tehnyt paljon töitä Drupalin parissa ja halusin osaltaan syventää tietämystäni rakentamalla omatkin sivut Drupalin päälle.

Jos blogin pystyttäminen on päätarkoitus, niin Drupal voi olla järkytys verrattuna vaikka edellä mainittuun Wordpressiin. Hallintapaneelin käyttöliittymä on ruma ja vanhanaikaisen näköinen, eikä esimerkiksi WYSIWYG-editoreista ole pakasta vedettynä tietoakaan. 

Onkin syytä tiedostaa, että oli sivusto millainen tahansa, niin pelkillä core-moduuleilla ei selviä oikeastaan koskaan. Käsittääkseni Drupalin kehitys on entistä enemmän menossa suuntaan, jossa vakiona mukana tulevien moduulien määrä on mahdollisimman pieni, mutta järjestelmästä olisi saatavilla eri tarkoituksiin räätälöityjä distribuutioita tarpeellisin lisämoduulein varustettuina.

Alusta lähtien oli selvää, että valmiiden teemojen sijasta ulkoasun täytyisi olla omaa tekoa. Omat Photoshop-taitoni eivät häikäise, mutta onneksi samassa taloudessa asuu graafisen alan ammattilainen, joten toiveideni mukainen leiska saatiin aikaiseksi. Halusin hyödyntää HTML5:sta ja varsinkin CSS3:sta sivuston taittoa tehdessä, mikä olikin oikein rentouttavaa, kun kerrankin ei tarvinnut välittää vanhemmista IE-selaimista. Suosittelen.

Kirjoitin HTML:n ja CSS:n aika pitkälti valmiiksi ennen kuin päätin ottaa Drupalin alustaksi. Tämä on aivan väärä tapa toimia, sillä Drupal tarjoaa HTML-merkkauksen, jolloin teeman tekeminen on CSS-muotoilujen tekemistä ja tarvittaessa HTML-merkkauksen muuttamista joko templaatti-tiedostojen tai teemoittamiseen liittyvien preprocess-funktioiden avulla.

Perusajatus Drupalin teemojen tekemisessä avautuu varsin nopeasti, mutta jos tarvitsee muuttaa vaikka yksittäisen lomakekentän HTML-merkkausta, niin HTML:n alkulähteen selvittäminen on varsinkin alussa hieman vaikeaa. Drupal-saitteja enemmän tehdessä tämä kuitenkin helpottuu.

Alkuun Drupalin välimuisti aiheutti turhaa ihmettelyä, kun tehdyt muutokset eivät tuntuneet toimivan. Vaikka Drupalin cachen laittaa pois päältä hallintapaneelista, niin se ei kuitenkaan ihan täysin poista sitä käytöstä. Cache on onneksi mahdollista kytkeä kokonaan pois käytöstä parilla puukotuksella development-vaihetta ajatellen, mutta tällä saattaa olla yllättäviä vaikutuksia esimerkiksi lomakkeiden kanssa. Jos jokin toimii hassusti, tyhjennä aina ensin cache.

Drupalissa on käsittääkseni alunperin ollut ajatuksena, että erillistä hallintapaneelin teemaa ei ole, vaan frontend- ja admin-puoli käyttävät samaa teemaa. Yleensä kuitenkin käytetään eri teemoja, mutta Drupalissa tämä erottelu on vielä hieman puolitiessä, sillä esimerkiksi sisältönoodin poistamisen varmistaminen tapahtuu frontend-teemalla, samoin noodin versiohistorian tarkastelu. Omassa käytössä tämä ei niinkään haittaa, mutta asiakasprojekteissa tällaiset outoudet aiheuttavat turhaa lisätyötä.

Drupalissa näkyy, että kehityksen aikana tärkeänä käyttökohteena on nähty yhteisölliset sivustot. Tämä on syytä muistaa vaikkapa moduulien konfigurointia ihmetellessä. Esimerkiksi itselläni oli alkuun hieman vaikea hahmottaa Twitter-moduulin konffausta, koska moduuli mahdollistaa oman Twitter-blockin esittämisen kullekin rekisteröityneelle käyttäjälle, jolloin asetuksia voi muuttaa useasta paikasta.

Drupalin vahvuus on laaja valikoima erilaisia valmiita moduuleita, joilla pystyy rakentamaan varsin suuria järjestelmiä hyvin vähäisellä koodauksen tarpeella. Välillä suorastaan hämmästyttää, kuinka monipuolisiin tarpeisiin jo pelkästään CKK-, Views- ja imagecache-moduulit riittävät. Näillä moduuleilla voidaan rakentaa monipuolisesti uusia sisältötyyppejä (Content Type), luoda niistä erilaisia näkymiä ja listauksia sekä käsitellä liitettyjä kuvia mm. muuttamalla kokoa ja rajaamalla. Kaikki tämä ilman, että tarvitsee kirjoittaa riviäkään koodia.

Toisaalta sitten, kun Drupalin kanssa tarvitsee alkaa koodaamaan, niin varsinkin alussa on helposti hieman hukassa, miten asiat tulisi tehtyä oikein, "the Drupal Way". 

Vaikka Drupalin kanssa on ollut tuskaisiakin hetkiä, niin mielestäni järjestelmä on kuitenkin suosionsa ansainnut. Odotan mielenkiinnolla tulevaa Drupal 7:aa, jossa CKK-moduuli on integroitu kiinteäksi osaksi Drupalia ja hallintapaneelin käyttöliittymä on uudistettu.

Aikaisemmin käytin RSS-feedien seuraamiseen Safaria, joka tarjoaakin varsin näppärän käyttöliittymän tähän tarkoitukseen. En käyttänyt erillistä sovellusta RSS-feedien lukemiseen, koska mielestäni oli luonnollista lukea feedit selaimessa. Iphonen hommaaminen kuitenkin muutti tilanteen, koska luonnollisesti syntyi tarve saada puhelin ja läppäri synkattua feedien osalta, eli tien päällä luetun entryn tulisi näkyä luettuna myös läppärillä.

Pienen selvittelyn jälkeen päädyin seuraavaan yhdistelmään: Google Reader + NetNewsWire (läppäri) + Byline (iPhone). Google Reader hoitaa synkkaamisen puhelimen ja työpöytäsovellusten välillä. NetNewsWiren 3.2+ desktop-versio osaa synkkaamisen molempiin suuntiin Google Readerin kanssa ja on muutenkin todella näppärä softa.

Iphone-ohjelmien puolella onkin sitten enemmän vaihtoehtoja tarjolla. Omissa selvittelyissäni kaksi on noussut ylise muiden: Byline ja NetNewsWire, joista Byline vie mielestäni lopulta voiton. Molemmat osaavat kaksisuuntaisen synkkaamisen Google Readerin kanssa. Erot näiden välillä löytyvät lähinnä käyttöliittymästä ja parista erityisominaisuudesta.

Byline:

NetNewsWire:

NetNewsWiresissä on näppärä "Next Unread"-painike ja ruudun alalaidassa kaiken aikaa näkyvillä oleva "Mark All as Read"-painike. Bylinessä tämä jälkimmäinen nappi on aina listan lopussa, ja on rasittavaa skrollata aina alas asti, jotta painike tulee näkyville. Toisaalta Bylinessä on todella näppärä cache-toiminto, jolla voi esimerkiksi tallentaa cacheen kaikki flägätyt entryt (siis koko nettisivun, jolla artikkeli on), jolloin niitä pystyy lukemaan nopeasti vaikka ei olisi internet-yhteyttä ollenkaan. Myös NetNewsWiressä on cache-toiminto, mutta se on rajoitetumpi.

NetNewsWiren käyttöliittymässä hämää se, että flägäämistä kuvaava ikoni (tähti) ei muuta ulkoasuaan sitä klikattaessa. Ruudun oikeaan yläkulmaan ilmestyy kyllä tähti kuvaamaan artikkelin lisäystä suosikkeihin, mutta olisi käytettävyyden kannalta loogista, että myös ikoni reagoisi. Olisin odottanut, että tämä olisi päivitysten myötä jo korjattu. Yleisesti ottaen Byline on ehkä hieman karumpi graafisesti, mutta mielestäni kuitenkin selkeämmän näköinen kuin NetNewsWire.

Ehkä eniten NetNewsWiressä häiritsee se, että uusimmat artikkelit eivät aina sijoitu listan kärkeen. Tämä kun yhdistetään siihen, että ohjelmassa ei ole Bylinen tapaan mahdollista piilottaa jo luettuja artikkeleita, niin artikkeleiden etsiminen listojen keskeltä muuttuu nopeasti todella rasittavaksi. Artikkeleiden piilottaminen olisi mukavaa myös screenshotissa näkyvässä tilanteessa, jossa uutinen on jostain syystä päivätty vuodelle 2019. 

Molemmat ohjelmat toimivat vikkelästi suuriakin artikkelimääriä ladattaessa. Kolmas varteenotettava RSS-ohjelma olisi ollut Newsstand, mutta olen lukenut lukuisia kommentteja ohjelman suorituskykyongelmista, joten en ole raaskinut rahojani sijoittaa kyseiseen ohjelmaan.

Bylinestä uupuu valitettavasti mahdollisuus jakaa artikkeleja esimerkiksi Twitterissä. NetNewsWirestä tämä ominaisuus löytyy. Bylinen tekijä on onneksi lupaillut Twitter-jakomahdollisuutta parin muun uudistuksen lisäksi tulevaan versioon.

Tätä kirjoittaessa Byline maksaa App Storessa 2,99€ ja NetNewsWire 3,99€. NetNewsWirestä on saatavilla myös ilmainen, mainoksia sisältävä versio, jota itse olen käyttänyt testailuun.

Kuten aikaisemmin kirjotinkin, niin puutteistakin huolimatta oma valintani on Byline - yksinkertaisesti siitä syystä, että tällä ohjelmalla feedien läpikäynti päivän mittaan on piirun verran suoraviivaisempaa kuin muilla ohjelmilla.

Viime aikoina on ollut myös puhetta siitä, kuinka Twitter korvaa RSS-feedien seuraamisen. Muutaman kaverin tiedänkin jo luopuneen RSS-feedeistä Twitterin vuoksi. Tätä aihetta tulee mahdollisesti käsiteltyä tulevissa postauksissa.