28 Apr 2012
Prima di dedicarmi completamente a Linux, avendo smesso di usare Windows da un sacco di tempo, avevo deciso di esplorare l'universo Apple più in profondità, concedendomi il lusso di poter dedicare un po' della mia infinita sapienza (hahah) all'atto di costruirmi un piccolo Hackintosh. C'è chi ci riesce e chi no; a me è riuscito e all'incirca un paio di anni fa ho fatto un giro con Mac OS X, spulciandomelo bene fino in fondo, sino ad arrivare nei meandri del filesystem, comprendendo l'abominio commesso da Apple nello sdoppiamento della struttura dei dati all'interno della root del sistema operativo. Ma a parte questo, che forse vi racconterò un'altra volta, ho compreso che l'universo della mela non faceva per me per una serie di motivi: primo tra tutti la sua chiusura. Sono così tornato ad usare con soddisfazione Linux, il quale però non mi riservava la stessa attenzione riguardo un aspetto che mi aveva molto colpito usando il mio Mac-non-Mac.
La user experience.
Cosa accade nell'universo Apple
Per retaggio culturale più che per vera necessità - diciamocelo infatti, Mac OS era superiore per operazioni di design in quanto Windows vent'anni fa non supportava i font a spaziatura variabile e tante altre carinerie; ora come ora sono esattamente equipollenti - a Mac OS è rimasto ancorato quel bacino d'utenza che, un po' hipster e un po' nostalgico, nonchè un po' traviato dalle opinioni comuni, durante le operazioni di sviluppo di un software tenta irrimediabilmente di trovare la migliore strada per disegnare l'interfaccia grafica. È un male? No. Anzi. Durante la mia esperienza con Mac OS X mi è capitato di imbattermi in applicazioni fatte abbastanza male dal punto di vista della funzionalità, ma mai in qualcosa che a vedersi fosse sgradevole: questo può essere riconducibile a due elementi fondamentali: Aqua e Cocoa. Cocoa è un set di librerie fondamentalmente molto prestante, e Aqua è l'estetica generale di Mac OS che al sottoscritto piace molto. Oltre questo, se proprio non si aderisce agli standard di Aqua le applicazioni che vengono scaricate sono sempre molto belle. Anche un tasto del tipo Sad Trombone risulta fenomenale, sarei pronto a scommetterci.
Proprio questo ha fatto sembrare Linux per certi aspetti ai miei occhi un sistema abbastanza "vecchio dentro", non tanto per i desktop environment che col tempo hanno assunto dei connotati sempre più moderni, ma per alcuni programmi i quali sembrano la morte civile. Fortunatamente Canonical ha portato all'attenzione di tutti questo dettaglio, che per quanto possa essere un'idiozia è pur sempre qualcosa che conta agli occhi dell'utilizzatore finale; sono felice quindi che esistano applicazioni come Nitro Tasks, che godono di un port Linux e di un'interfaccia molto bella, ma soprattutto ho visto come il trend a riguardo sia cambiato, anche nel panorama Linux che a cambiamenti di questo tipo è sempre stato restio, a causa dei moniti lanciati da Steve Jobs e Mark Shuttleworth in seconda battuta.
Il panorama open si evolve
Ho fatto un giro con Novacut 12.04 proprio ieri, per testarlo un secondo e vedere fin dove ci si può spingere con questo software che erge come suo cavallo di battaglia proprio la UI. Soddisfattissimo, mi sono poi girato il blog ufficiale e ho trovato a lato la lista degli sviluppatori, con rispettive qualifiche. Ve la riporto integralmente:
Jason DeRose
Architect & Developer
Tara Oldfield
Anthropologist & Artist Liaison
Akshat Jain
Developer Outreach & Developer
James Raymond
UI Designer & Developer
David Jordan
Multimedia Engineer & Filmmaker
Mi è saltata all'occhio questa cosa meravigliosa: tra cinque sviluppatori, possiamo vedere come due tra loro (un'ottima percentuale quindi) siano "umanisti": un UI designer, quindi una persona più che preparata, e soprattutto un'antropologa che si occupi di verificare che effettivamente il lavoro del designer sia usabile e degno di questo nome. Sono parecchio felice di vedere che anche nel panorama Linux le cose stanno cambiando, e che il design non sia un fattore che di fronte ad altri aspetti (magari marginali) passa in secondo piano.
Spero vivamente che l'esempio di Novacut non rimanga solo una goccia nel mare.
Photo courtesy by jm3 @ Flickr
20 Apr 2012
Poco tempo fa è apparso un post su OneOpenSource scritto dal medesimo che spiegava come Linux 3.3.1 introducesse dei bug gravissimi nella gestione di schede wireless Atheros, precisamente facenti uso del driver ath9k incluso in Linux già da parecchi anni. A quanto pare infatti, gli sviluppatori hanno deciso di farsi qualche risata alle nostre spalle.
Con Linux 3.3.2 rilasciato stabile su kernel.org ho voluto dare una chance alla mainline 3.3 per vedere cosa diavolo succedesse, e invece mi sono trovato connesso alla rete WPA2 di Roma2LUG in men che non si dica. Tutto è bene quel che finisce bene, tuttavia volevo lasciarmi a qualche considerazione da vecchia di paese riguardo l'accaduto, precisamente sul meccanismo di QA e signoff sia del kernel Linux che del suo pacchetto in Arch Linux.
Mi domando infatti cosa diavolo sia venuto in mente agli sviluppatori da due lati: innanzi tutto rilasciare una modifica del genere senza testare. È vero infatti che uno in genere è sicuro di quello che scrive e "if it compiles, it works", tuttavia ho esaminato la patch (capirai, 'sta perizia tecnica hahah) e ho visto che è stata tolta una porzione di codice veramente miserrima, mentre le aggiunte sono state parecchie in confronto. Mi è sembrato come se ci si fosse dimenticati di inserire delle syscall in mezzo al codice; qualcosa del tipo "Massì, fàmo così, che ce frega,che ce 'mporta, male che va ci arriva qualche mail minatoria" - e infatti è andata male. Non commento solo perchè in quanto a programmatore sono un'emerito imbecille e non sono al livello, sicuramente, di chi ha scritto ath9k, però insomma. Qualche riserva me la prenderei.
La mia seconda perplessità è riguardo il meccanismo di signoff di Arch Linux. Quando è arrivata la mail "please signoff linux-3.3.1" la gente a che pensava? Era tempo di YouPorn? Mi fa strano, perchè comunque gli sviluppatori di Arch di solito scoprono eventuali malfunzionamenti abbastanza in fretta. La patata bollente stavolta è scappata dalle mani di tutti, ed è finita in terra. Peccato: sinora il meccanismo di QA (se così si può chiamare, dato che non lo è in maniera letterale) aveva retto parecchio bene a eventi di questo tipo.
Questo è lo spazio riservato alle considerazioni che mi sono concesso. Le riflessioni che ne sono derivate, magari ve le racconto nel prossimo post ;)
16 Apr 2012
Certo, non è una passeggiata. Se non si ha un animo smanettone è meglio lasciare perdere. Non perché sia impossibile, ma perché a conti fatti non cambia l'esperienza utente.</p>
Questo post di Vincenzo mi ha colpito molto, non solo perché non è la solita sequenza fritta e rifritta di comandi, ma soprattutto perché dice una verità immensa, cioè che ricompilare il kernel Linux ad un utente medio (ma anche medio-alto) non serve assolutamente a niente, a meno che non ci siano moduli che per qualche strano motivo non vengono inclusi nella distribuzioni standard.
Tutta didattica e poca altra roba quindi. Poi oh, ha usato una mia guida linkandola e ringraziandomi. Io però ho deciso che mi preparerà una pastiera di sua mano, dato che, si sa, verba volant, pastierae manent.
12 Apr 2012
Ecco qua; all'ennesima startup di successo, dopo il caso Jobs planetario, si cominciano a vedere gli articoli che ne descrivono pregi, difetti, la storia, e proprio dai magazine italiani cominciano a fuoriuscire degli splendidi coccodrilli; stavolta ci si mette Linkiesta, illustrando perchè Instagram in Italia non sarebbe mai nata.
Io direi che anche basta con queste cose. In Italia abbiamo startup di successo che si tengono in piedi, magari un po' traballanti, con gli stessi sforzi e gli stessi sogni delle persone che sono dietro Instagram: la volontà di costruire qualcosa di nuovo. E, dico io, in Italia Instagram non sarebbe mai nata perchè siamo bravissimi a piangerci addosso e nessuno invece si da da fare per trovare l'uscita dal labirinto. In Italia Instagram non sarebbe mai nata perchè al posto di costruire alternative e sistemi anche burocratici fattibili la gente è impegnatissima a manifestare disagio per cose banali che sarebbero risolvibili senza frignare tanto.
08 Apr 2012
Ho notato un comportamento chiave nel mercato del software: nel caso di attività multipiattaforma, si genera una sorta di onda anomala per cui all'arrivo di un software blasonato su una piattaforma concorrente, vengono disintegrate le alternative, a prescindere dalle criticità e dai pregi dell'una e delle altre. Mi spiego meglio.
This world will be mine...
Proprio con l'arrivo del problema dell'essere multipiattaforma, sono cominciate ad esistere nel settore informatico una serie di ricorrenze per cui un software, diventato leader di mercato, comincia a fare le sue belle cosine su una piattaforma sola e la portabilità viene considerata un po' poco. D'altra parte, gli utenti di altri sistemi operativi, CMS, browser o cose simili cominciano a desiderare spasmodicamente quel software, e sperabilmente sfruttano potenziali concorrenti; nel campo dell'open source si incappa oltretutto nella creazione ex novo di altri software che facciano la stessa cosa, altrimenti dei volontari si uniranno a progetti esistenti per implementare le feature di cui c'è la necessità in qualcosa di già presente nel mondo dei programmi.
Contemporaneamente, però, in generale il motore immobile di tutto questo, ossia il software leader di mercato che è presente sull'altra piattaforma, costituisce il driver fondamentale per quanto riguarda le caratteristiche di ciò che un software di quel tipo deve avere. Una grossa minaccia per la creatività di chi, occluso dalla cecità istigata dalla voglia di quella determinata caratteristica, invece potrebbe sfornare tanto di buono che non viene a galla. Follow the leader. E gli altri?
... and you're first in line
Il nostro ecosistema di software che essenzialmente fanno tutti un po' la stessa cosa, capeggiati da un driver di mercato che detta feature e altro, è dispersivo. Ognuno coltiva il proprio orticello, e in genere anche se c'è un software più "corposo" degli altri comunque non è sufficientemente autonomo in campo di feature design da dare filo da torcere al competitor principale, anzi; spesso alcuni pregi non vengono capiti, e ci si concentra su delle cose magari risolvibili invece di prendere atto di alcune peculiarità che, magari, sarebbero decretatrici della fine di qualsiasi progetto concorrente.
Un giorno, il leader di mercato decide che i dati di crescita non sono più abbastanza grandi, oppure (e l'uno non esclude l'altro) vuole semplicemente un'altra fetta di utenza tutta per sé; lo squalo decide di mangiare il gattino in quattro e quattr'otto, e annuncia l'inizio dello sviluppo del software per la piattaforma concorrente a quella corrente. Leak di volontari, e disinteresse per i progetti che sinora erano stati tenuti in vita solo dalla volontà di vedere un prodotto simile al leader per la piattaforma concorrente, sono i sintomi più comuni dopo un annuncio del genere.
Il gigante del mercato così fagocita tutto il resto, inglobando quei progetti che, giustamente, non hanno saputo fare di meglio che restare nella sua scia invece che proporre alternative intelligenti e feature innovative che avrebbero potuto decretare il successo della piattaforma alternativa e il balzo in testa di un nuovo leader, almeno in alcune fette di mercato.
L'effetto Instagram
Quanto di cui sopra, mi piace formalizzarlo come "effetto Instagram". L'intuizione infatti mi è venuta mentre osservavo il trend sempre crescente di Instagram su iOS, e quando ho visto la notizia della pianificazione dell'applicazione per Android ho potuto notare come molti avessero già deciso per lo switch da altre piattaforme, compreso il sottoscritto per vari motivi. Software come PicPlz e Lightbox hanno quindi ricevuto una poderosa ridimensionata al proprio volume di attività dal momento in cui Instagram ha fatto la propria comparsa sul Google Play Store.
È solo un caso, ma ce ne sono a decine di simili, come GIMP o LMMS, software assolutamente buoni ma che crollerebbero se un market driver come Adobe decidesse per qualche motivo di fare il grande passo verso Linux. Rimarrebbero software per hobbisti, gratuiti e nient'altro, non in grado di offrire niente di più.
Nel caso specifico, PicPlz ha puntato semplicemente ad essere un'alternativa ad Instagram per Android senza minimamente calcolare che il fattore che ha determinato il successo di Instagram non è stato qualcosa come la presenza di filtri (dato che quelli di Instagram fanno alquanto cagare, e scusate il francese) o la possibilità di modificare le foto, bensì la sua componente hipster (io ho Instagram → io ho un iPhone → io mi posso permettere un device da 700 euro) e la comunità su cui l'applicazione scala parecchio bene, che si è formata e adesso conta veramente tantissimi membri attivi. L'aspetto social è sempre stato sottovalutato da applicazioni come PicPlz che oltre a fare la stessa cosa che faceva Instagram la facevano pure maluccio, per quanto riguarda l'aspetto community, e infatti adesso sono state fagocitate e buttate nel calderone di quelle cose che ormai non servono più. Fine del bel sogno di gloria.
Evitare l'effetto Instagram
La parola d'ordine è solo una: differenziarsi. Fare l'Instagram dei poveri o il Photoshop aggratis è un conto, iniziare ad introdurre qualche feature degna è un altro paio di maniche. E se il tuo progetto non deve morire, deve differenziare la propria offerta da quella dei competitor, non importa quale piattaforma si prenda come riferimento.
Magari lavorare secondo la Teoria delle Nicchie di Simone ;)
Photos courtesy of jfingas, WindKoh
