Qualcuno che mi segue su Twitter se ne sarà accorto da un bel pezzo, ma nei mesi scorsi ho rilasciato (e  aggiornato) assieme a Babele la mia prima applicazione per iPhone, WideNoise. Era già da un po’ che giocavo con Xcode, ma questa è la prima applicazione di una portata rilevante che realizzo. Portable Firefox CX per quanto utilissimo è davvero un giocattolo al confronto.

Origine

Il progetto nasce all’interno di WideTag mentre si rifletteva su qualche modo efficace di utilizzare le tecnologie spime-centered che stavamo sviluppando su qualcosa di più vicino alle persone, qualcosa di intuitivo e facilmente utilizzabile. In origine pensavamo a dei rilevatori di inquinamento, o anche solo di CO2, ma agganciare un sensore ad un telefono oltre che comunque con una certa complessità necessiterebbe anche la vendita del sensore stesso.

Così ad un certo punto abbiamo notato che anche l’inquinamento acustico è una forma di inquinamento, peraltro molto poco percepita e del quale non si parla a sufficienza. L’idea originale? Io ricordo un accenno di Bru, ma anche Babele e Lee avevano qualcosa di simile che gli ronzava in testa. Non saprei a chi attribuire la proposta iniziale però.

Design

Siamo partiti dalle funzionalità che volevamo incluse, sostanzialmente due:

1. La rilevazione del rumore ambientale, ovvero raccolta dei dati dagli spime.
2. La mappatura del rumore su una cartina, ovvero tracciatura utile e sociale dei dati degli spime.

Vista l’esistenza di due funzionalità distinte, abbiamo realizzato due tab, uno di sampling dal microfono e uno di visualizzazione della mappa.

Da un punto di vista dell’interazione volevamo qualcosa di semplice, il più automatico possibile. L’ideale sarebbe stato ovviamente il velocissimo “Premi un pulsante e tutto poi funziona in automatico”.
Dopo alcuni test iniziali così abbiamo notato però che non era raro voler fare delle rilevazioni senza per forza vederle anche nella mappa globale, così abbiamo scorporato le due funzionalità: rilevazione e invio dei dati.

La mappa invece è stato un problema un po’ maggiore perché ci sarebbe piaciuto realizzare una heatmap, ma risultava computazionalmente troppo pesante e sostenere i costi per l’hardware necessario a generarla era un po’ eccessivo visto lo scopo limitato di WideNoise.

La prima idea è stata quella di visualizzare il dato medio dell’area visualizzata, ma abbiamo subito notato che un numero preciso rischiava di creare aspettative su un’area che poi concretamente non erano corrispondenti alla realtà.

Nella ricerca di un sistema più fuzzy abbiamo pensato a mappare vari “oggetti” a varie fasce di rumorosità. In questo modo abbiamo avuto: piuma, gatto, televisione, automobile, dragster, t-rex e concerto rock, come intensità crescente. Il risultato per certi versi ha superato le aspettative: questa è una delle feature che è piaciuta di più e ha anche permesso di rendere più comprensibili numeri che sono troppo astratti: le persone normalmente non sanno “40 db” cosa significa come rumorosità. Se invece dico “televisione” allora già il discorso cambia.

Nella versione 2.0 abbiamo poi cercato di renderlo più sociale. Da un lato creando un po’ di rumore (:P) su Twitter, dall’altro creando un widget delle rilevazioni che si fanno in modo da poterle inserire su siti e blog. Abbiamo anche aggiunto alla mappa le singole rilevazioni della persona e un pannello globale sul sito che visualizza in tempo reale le rilevazioni.

Note tecniche

Affrontare quasi da zero una applicazione per iPhone non è una cosa difficile, ma neppure esattamente una passeggiata. Iniziamo quindi con lo scordarci un bel ‘print “Hello world”‘ alla Python.

L’inizio è buono: gli strumenti di sviluppo sono molto ben progettati e riescono a nascondere un po’ del fatto che, alla fine, stiamo parlando pur sempre di C, seppure in una sua forma evoluta chiamata Objective-C.

Il modello di sviluppo basato su MVC (più VC che MVC secondo me, ma è soggettivo suppongo) semplifica ulteriormente le cose e InterfaceBuilder è uno strumento eccezionale: le interfacce base vengono fatte in un istante, anche se bisogna ben capire il modo in cui si agganciano gli oggetti e gli eventi al codice Objective-C sottostante.
Da un punto di vista degli eventi si gestisce quasi tutto tramite delegation (associando oggetti agli eventi). Io ho provato un po’ di artifici – fattibili – per tentare un approccio più JavaScript-like (associando funzioni agli  eventi) ma alla fine non essendo quello formalmente accettaato si rischiano situazioni miste brutte a vedersi e a gestirsi.

L’unico grosso difetto è forse la sintassi di Objective-C, che a mio parere è difficile da digerire (le quadre… *sigh*). Insomma: se si riesce a trovare un modo di adattare questa sintassi al proprio stile credo che non ci siano alla fine grossi problemi.

La documentazione non è facilmente reperibile perché comunque è un linguaggio per certi versi di nicchia. Abituato alla facilità di reperire informazioni su PHP, Ruby, Python qui spesso si deve scavare nei lunghi documenti ufficiali Apple o in forum.

Il sistema di gestione certificati per sviluppatori è invece un inferno a mio avviso, e una cosa che da Apple proprio non ci si aspetterebbe. Finché sviluppate sul simulatore tutto bene, ma sia per andare sul device fisico sia per rilasciare sullo store è necessario generare dei certificati.
Io mi sarei aspettato una bella gestione trasparente della cosa: un sistema, anche un applicativo separato, dal quale fare richiesta automatica con il proprio account sviluppatore, con tutta l’amministrazione lato server necessaria, anch’essa automatizzata.
Non vi dico qual è il processo esatto, vi dico solo che è tediante e fa perdere un bel po’ di ore, che si moltiplicano nel caso qualcosa vada storto (ad un certo punto durante le beta dell’iPhone OS 3.0 mi son ritrovato con 3 certificati intestati a me, tutti scaduti o “rotti”).

Sinceramente, mi aspetterei che in futuro:

1. Automatizzassero la gestione dei certificati. (questo fattibile già oggi, se volessero).
2. Abilitassero bridge verso linguaggi interpretati (o pre-compilati in qualche modo) come Python, Ruby o perché no, HTML/CSS/JavaScript. Su Mac OS X già ci sono. (questo credo oggi non fattibile perché C è comunque immensamente più veloce e leggero di un interprete qualunque).

Tornando all’applicazione in sé, Babele ha fatto un ottimo lavoro di taratura nonostante le limitazioni del microfono dell’iPhone che come è ovvio che sia è realizzato per ottimizzare la risposta sulla voce umana – è quello il suo scopo.

Da parte mia grossi problemi non ne ho trovati, alla fine si tratta soltanto del tempo (molto) necessario per scrivere tutto quello che serve in C, andando a capire i vari framework (UIKit primo fra tutti). Dal mio punto di vista molte cose potrebbero essere astratte e sarebbe bello se ci fossero librerie per gestire automaticamente certe cose (come qualche astrazione sulle funzionalità HTTP esistenti). Pian piano queste stanno nascendo ma sono mediamente ad uno stato embrionale: non c’è ancora nulla di solido e affermato.
Una cosa bella sarebbe poi se queste librerie non venissero distribuite come file sorgente ma già pacchettizzatae in framework. Questo putroppo è ancora più raro. :/

Note di rilascio

Il primo rilascio da parte di Apple è stato molto veloce (2gg), poi però per la 2.0 hanno segnalato dei problemi e non ci è stata approvata. Purtroppo quello che succede in questo caso è che i messaggi di risposta di Apple ai motivi sono sempre piuttosto inutili, nonostante qualcuno si prenda sempre la briga di allegare degli screenshot.

Nel nostro caso solo dopo molto tempo (e molti scambi di mail con messaggi copia-incollati e screenshot inutili) abbiamo capito che non era un problema di UI nonostante quanto dicessero i tecnici Apple. Riducendo pian piano le possibilità abbiamo trovato che era un problema dell’algoritmo di encoding base64 e quindi con certe password non riusciva a postare su Twitter. Come potete immaginare, né io né altri avevamo password con i caratteri incriminati, quindi a noi funzionava sempre tutto correttamente.

L’esperienza non è stata delle migliori. Oltretutto se il tecnico avesse risposto alla nostra prima mail con quanto chiedevamo (il log) avremmo risolto nel giro di un giorno, e non di mesi.

Questa sequenza di scambi ci ha permesso però di vedere che, almeno per noi e la nostra app, il ciclo di approvazione sembra essere di una/due settimane, con la comunicazione da parte di Apple inviata il sabato, indipendentemente se le correzioni venivano fatte da noi domenica oppure venerdì (salvo un caso).

Riporto i valori indicativi delle nostre submission:

1. 1.0: inserita il 22 gennaio 2009, approvata il 24 gennaio 2009 (sabato).
2. 2.0: inserita il 18 marzo 2009, rifiutata il 28 marzo 2009 (sabato, alle 23:48) [a].
3. 2.0b: inserita il 29 marzo 2009, rifiutata il 4 aprile 2009 (sabato, alla 1:55).
4. 2.0d: inserita il 6 aprile 2009, rifiutata il 18 aprile 2009 (sabato, alle 3:19).
5. 2.0e: inserita il 8 maggio 2009, approvata il 18 maggio 2009 (lunedì) [b].
6. 2.0.1: inserita il 2 giugno 2009, approvata il 19 giugno 2009 (sabato) [c].

[a] Nota: la 2.0 è stata in sovrapposizione con l’evento di presentazione di iPhone OS 3.0 il 17 marzo.
[b] Nota: l’unica approvazione non fatta un sabato.
[c] Nota: la 2.0.1 è stata a cavallo del WWDC (8-12 giugno) e quindi ha saltato una settimana di approvazione.

Ringraziamenti

I primi ringaziamenti vanno ovviamente alle tre persone che stanno portando avanti l’idea di WideTag: Leandro Agrò, Roberto Ostinelli e David Orban. Un grandissimo ringraziamento anche al co-autore di questo piccolo software, Aaron ‘Babele’ Brancotti. E, mea culpa me ne stavo scordando, un grazie anche a Trinity Dunnit per la grafica steampunk.

Bill, oltre ad essere un geniale designer e programmatore era anche un appassionato di fotografia (notata l’interdisciplinarietà? *wink*). Questo gli ha dato uno spunto che ci ha consegnato un interessantissimo documento storico: per ogni stadio di evoluzione dell’interfaccia del Macintosh scattava una Polaroid, a volte commentata.

Sul sito Folklore.org, depositario di una quantità di aneddoti sui primi passi del Macintosh, è presente anche la collezione di queste polaroid, commentate.

E’ uscita una riflessione sui menu radiali (o pie menu), così mi sono messo a pensare ma l’unico caso che ricordo di approccio funzionale al problema è quello di Maya. Ci sono sì moltissime altre soluzioni, come ad esempio Neverwinter Nights (nei giochi è più frequente) ma molto spesso hanno problemi: l’approccio che usa solo icone, oltre ad essere poco denso informativamente, è anche poco comprensibile nel colpo d’occhio e richiede un apprendimento sensibile.

Non venendomi in mente nessun esempio di menu radiale ben strutturato, modulare, scalabile ed esteticamente piacevole, ho pensato di preparare un mockup seguendo le linee guida di Apple (HIG).

Dietro questa scelta vi sono alcune considerazioni di portata più e meno ampia, ma vorrei sapere la vostra opinione in merito.

Vi lascio quindi con due domande:

1. Pro e Contro di questa soluzione?
2. Avete esempi di menu radiali che ritenete efficaci, efficienti ed esteticamente piacevoli?

The only problem with Microsoft is they just have no taste, they have absolutely no taste, and what that means is – I don’t mean that in a small way I mean that in a big way. In the sense that they they don’t think of original ideas and they don’t bring much culture into their product and you say why is that important… well you know proportionally spaced fonts come from type setting and beautiful books, that’s where one gets the idea… if it weren’t for the Mac they would never have that in their products and so I guess I am saddened, not by Microsoft’s success, I have no problem with their success, they’ve earned their success for the most part. I have a problem with the fact that they just make really third rate products.
— Steve Jobs, 1996

Oggi mi sono ricordato questa intervista, che ritengo una delle cose più vere ma anche più cattive che Jobs abbia mai detto contro Microsoft.

Mi sono ricordato di questo perché ho letto, via Joel, cosa Microsoft ha fatto scrivere dietro gli Zune: “Hello from Seattle”, per schernire a modo suo il “Designed by Apple in California”. Ma vi rimando all’articolo di Joel.

Mi piacerebbe che questo discorso venisse percepito non per il solito fanatismo pro/contro le due società, ma per il significato che è insito in queste parole. In altri termini, seppure è vero che Jobs sia il CEO di Apple, è anche vero che Jobs è Jobs, indipendentemente dal fatto che sia in Apple, Next, Pixar o quant’altro. E ovunque vada, si porta dietro un chiaro stile ed una limpida cultura del design.

Sapete cosa mi ricorda ogni volta? Olivetti dei bei tempi (1930-1960) (farei notare che la voce su Wikipedia è piuttosto povera come cultura e design, quel poco che c’è è per ora a mano mia).

La prima questione riguarda la capacità di innovazione di Apple. In questo preciso momento la necessità di fare soldi di Apple è il limite alla sua stessa innovazione tecnologica. Il motivo è semplice: ha due prodotti che de facto sono leader: iPod, leader di mercato, iPhone, leader come interfaccia (e Nokia ha già copiato dichiarando apertamente che iPhone è un ottimo design).

Perché affermo questo? Perché avendo fatto l’eccellente scelta sia tecnica che commerciale di portare tutti gli iPod su “OS X Embedded“, poteva permettersi molto di più sull’iPod Touch di quanto abbia fatto. Se fate caso infatti l’iPod Touch dall’iPhone eredita solamente il formato e le feature multimediali. Di “non-iPod” c’è solamente Safari. E Mail? E le note? E le funzionalità di calendario, saranno le stesse? Poteva inserire tutti questi software a costo zero, eppure non l’ha fatto.

Il semplice motivo è che sarebbe stato un concorrente dell’iPhone, ancora troppo recente (già la gente si è arrabbiata per il deprezzamento di 200$ dopo 2 mesi – se 599$  ti sembrava un prezzo giusto e hai comprato, problemi tuoi), per quanto non abbia le funzionalità di fonia. Questo spiega anche perché non è stato rilasciato un dev-kit per iPhone: in questo modo iPod Touch avrebbe raggiunto a tempo zero le stesse funzionalità del fratello maggiore. Il fatto che siano hack è un deterrente.

Vediamo l’altro aspetto, mi apro un istante alla pura speculazione. Primo dato: iPod ha una penetrazione di mercato e di popolazione piuttosto alta. Così alta da avere a disposizione un ecosistema di accessori ricchissimo (nota a margine: non ha praticamente mai cambiato interfaccia hardware). Secondo dato: iPod Touch ha WiFi.

Stavo quindi immaginando un panorama futuro in cui l’iPod Touch – o un suo successore – potesse diventare un oggetto talmente diffuso da spingere aziende, negozi e locali pubblici ad installare dispositivi WiFi.
Se ci pensate, è abbastanza evidente: oggi ci sono poche persone che utilizzano o utilizzerebbero WiFi in luoghi pubblici. Pensate un istante se una consistente percentuale della popolazione possedesse in una sua forma un iPod/iPhone WiFi. L’avrebbe acquistato per motivi indipendenti dalla copertura WiFi, eppure a quel punto potrebbero usarla se solo ci fosse.

Notate anche un dettaglio non del tutto marginale: iPod come termine non ha niente a che fare con la musica (trae infatti origine da 2001: Odissea Nello Spazio). Una previsione plausibile in futuro è una contrazione della linea prodotti Apple verso l’abbandono di iPod così come lo conosciamo (già ora ha preso il nome ‘Classic’ e perso il bianco) e verso qualcosa di completamente diverso, seppure ne manterrà il nome.

In fondo, era quello che Apple voleva sin dal Knowledge Navtigator (1987).

E’ buffo perché si tratta della prima bozza, fatta prendendo una foto dalla rete, modificandola un po’ e cercando di renderla realistica. Era quasi solo l’intuizione di come avrebbe potuto essere (beh, in fondo ci ho azzeccato sul touch).

La seconda versione è estremamente più rifinita, ma non ha avuto una diffusione comparabile. Il dubbio rimane: giusto tempismo? Ranking più alto sui motori di ricerca (la keyword iphone nano mi pare presenti il mio blog in prima pagina)? O cos’altro?

Questo per dire che spesso un pesante compromesso sulla tecnica in virtù di un tempismo maggiore può portare a vantaggi anche molto rilevanti.

[up/2007.10.11] Oggi sono spuntati entrambi i miei mockup su un’altra classifica postuma, sono classificati 22° e 12°, anche se non è una reale classifica. I commenti sono comunque molto positivi, e criticano soprattutto la mancanza di feature come musica e video (che ai tempi non era detto vi fossero):

This may be a tad to distilled (almost Nano-ish), but sleek enough to make the list.  Interesting that while being a mock-up, it’s still better looking than many phones still offered today

Beh, per quanto piccole son soddisfazioni. Dovrei mettermi a fare design industriale.

1. Tantissimi sviluppatori si stanno accanendo per violare Safari 3 beta (Digg e Techmeme sono pieni di notizie in merito). Questo, non è un ‘problema’ di Safari, anzi: è il motivo per cui si rilasciano le beta. La cosa buffa è che stanno usando questo per ‘dimostrare’ quanto Apple faccia marketing. E la novità dove sta? Flash news: attaccando Safari 3 beta state supportandolo, non screditandolo, trovando i bug e facendo hype.
2. Safari 3 beta è anche aggredito per dimostrare come non serva a niente, sia meno performante, occupi più memoria, etc. Lo scopo di Safari 3 su Windows NON è dare un altro browser a Windows. E’ fornire anche agli sviluppatori Windows l’SDK ‘light’ per sviluppare su iPhone.

Dico SDK ‘light’ perché nonostante quanto detto da Jobs, è evidente come sviluppare Ajax su iPhone sia una cosa fondamentale ma non serva a sviluppare applicazioni vere su iPhone.

Per il resto, l’ho trovato un Keynote senza novità: probabilmente sapevo già tutto o quasi di quello che è stato detto e la GUI di OS X 10.5, l’unica cosa per cui mi chiedevo ‘cosa avrebbe fatto Apple’ ora è semplicemente stata uniformata. Buona cosa, ma niente di strabiliante.

Una piccola nota a margine: se guardate i video disponibili su Leopard sul sito Apple, potete vedere nelle demo del Finder nuovo (carino, non c’è che dire) che sotto ai computer trovati in rete c’è “Share Screen”. Feature?

[uP] Leggo ora una voce piuttosto interessante su Safari 3 per Windows: c’è l’ipotesi che Apple abbia ripreso il vecchio progetto Yellow Box, ovvero il porting multipiattaforma (in questo caso Windows) dei framework di sviluppo Next, ovvero l’attuale Cocoa e Core vari.
Se la notizia fosse vera – e l’articolo segnala una persona che ha compilato dei sorgenti sui Core di Safari 3 – significherebbe non solo che Safari 3 è l’SDK lite per iPhone, ma anche lo strumento di betatesting del loro framework…

Visto l’hype che di questi tempi pervade internet intorno alle voci del prossimo iPhone, io che ho anche un animo da designer (IxD, GD, quel che vi pare) mi sono invece divertito a pensare quale fosse il modo più efficiente per comporre i numeri di telefono con la wheel. In effetti non ci ho dovuto pensare molto, avevo già tutto sotto mano. I telefoni in fondo sono stati “così” per parecchio tempo, prima di avere le tastiere.

Così, unendo questa idea con uno spunto di Leandro e chiedendo a Glorfind3l di crearmi un modello 3D in Blender, ho creato questi mockup basati sul mio prototipo precedente.

Come potete vedere, la linea è stata aggiornata a quella dell’iPod Nano 2G, che ho reputato più idonea come formato di un telefono per le sue dimensioni. Ripeto e integro le caratteristiche tecniche che avevo abbozzato:

• Scocca dell’iPod Nano.
• Display TouchScreen su tutta la superficie frontale.
• Display LED/OLED sotto la superficie per essere più resistente.
• B/N o a Colori, indifferentemente, seppure il prototipo è pensato in B/N.
• Per sbloccare il telefono si memorizza una particolare gesture da fare sul touch screen. La gesture è personalizzabile.
• Scroll Wheel.
• Fotocamera digitale sul retro

Ho preferito l’approccio scroll wheel rispetto a quello a tasti perché in questo modo si “risolve” parzialmente il problema del feedback tattile: l’attrito del dito sulla superficie fornisce un feedback passivo. Dato che serve per scorrere, lo stesso attrito su un tasto non sarebbe egualmente efficace.

Nelle due immagini potete vedere 4 stati differenti del cellulare:

1. accensione
2. standby
3. rubrica
4. composizione del numero

I due stati interessanti sono quelli contenuti nella seconda immagine, ovvero il 3 e il 4.

Il terzo semplicemente mostra come oggi la rubrica dovrebbe essere facile, intuitiva e spaziosa da sfogliare. Non solo, avendo ogni cellulare integrata ormai di default una fotocamera, sarebbe importante poter sfogliare la rubrica per fotografie. E’ evidente come sia più semplice ricordare un nome e non sarebbe un problema scattare una foto al volo quando ci si scambia il numero. Quante volte vi è successo di non ricordare chi fosse un numero che avevate sul cellulare?

Il quarto invece mostra come con la scroll wheel sarebbe comunque intuitivo comporre un numero di telefono. Forse non veloce come un utilizzatore di tastiera rapido, ma comunque non così scomodo per uno già abituato con la scroll wheel. Il modo è analogo alla navigazione standard su iPod: girando la wheel si scorrono le cifre, mentre premendo next e back si passa alla cifra seguente o alla precedente.
Ho ovviamente aggiunto qualche “eyecandy” che credo sia possibile realizzare e contemporaneamente migliorerebbe l’esperienza d’uso dell’utente (il cosiddetto cool factor):

• La wheel è leggermente opaca, ma si illumina al contatto con il dito.
• La selezione del numero appare facendo scorrere su una ipotetica circonferenza i numeri, con in dissolvenza quelli non selezionati.

Per me è stato divertente pensarci e realizzarlo, spero che piaccia anche.

Precisazioni: visto che è il commento che ho letto più spesso, forse è meglio che lo aggiunga esplicitamente anche nell’articolo (seppure ci sia già scritto fra le righe): questo prototipo è stato progettato per puro esercizio di stile e tecnica (interazione, progettazione di interfacce, grafica) secondo dei vincoli espliciti ed impliciti che ho dato come assunti. Questi vincoli sono il formato (iPod Nano), il touchscreen (visto che è quasi confermato) e la wheel (tratto distintivo). E’ chiaro che non sia la soluzione ideale, né vuole esserlo.

Certo:

• Le cifre sembrano un tantino esagerate
• Lo studio è promosso da Apple (Cinema Display 30″ anyone?)

Però è evidente che chiunque lavori al computer abbia un incremento di efficienza netto avendo più spazio di lavoro ed il monitor è sia spazio di lavoro sia benessere per gli occhi.

Poi, è anche chiaro: seppure con un tavolo più grande un falegname lavorerà meglio, non è detto che tutti i falegname lavorino bene… quindi l’incremento potrebbe non esserci. Per quanto comunque, anche in caso di incremento assente, la persona avendo comunque più spazio avrebbe un fattore in meno di fastidio.

Qualche giorno fa notai in un post una curiosa parentesi fra le sue note (4). BBEdit negli anni 90 era l’editor HTML più usato per realizzare siti web. Nota bene: non l’editor Mac più usato, ma l’editor in assoluto più usato fra tutte le piattaforme. Ed è disponibile solo su Mac. In questi anni la storia si ripete: NetNewsWire è l’aggregatore RSS più diffuso sulla rete, pur essendo esistente solo per Mac.

Gruber accenna una ipotesi: “Penso che la spiegazione sia semplicemente che gli utenti Mac sono nettamente più propensi ad essere early adopters“.

Mi ha fatto pensare.

L’ho connesso con un altra considerazione riportata da Christian Metts (via Sam Ruby): alla RailsConf 2006 oltre il 90% dei partecipanti utilizzava portatili Apple.

Mi ha fatto pensare.

Oggi torno su un post più recente di Gruber, che riporta un suo post del 2002: “I Mac è molto più probabile che siano utilizzati da entusiasti”.

Entusiasti?

Mi son appoggiato alla sedia, ho riflettuto un po’ sul “mood” medio che trovo fra un utente Windows, un utente Linux, un utente Mac. Annessi e connessi sociali.

Già.

E’ chiaro, non si può generalizzare, ma… è vero.

Gli utenti Mac sono normalmente degli entusiasti. Non solamente usano il computer perché “capita” ma ne sono affascinati, in qualche modo. Chi per la tecnica, chi per l’usabilità (pur non sapendo che si dice così), chi per l’estetica. Sono persone che facilmente ti risponderanno “okay, vado a casa e preparo il video su iMovie e te lo faccio avere domani”, per fare un esempio stupido (forse troppo, lo ammetto). Sono quelli che solitamente non pensano al computer come una macchina, ma a quello che con la macchina si può fare per il mondo che sta fuori.

Gli utenti Windows, sono invece normalmente delle persone che “lo uso perché ho sempre usato questo”, oppure “lo uso perché questo c’è in ufficio”. Certo, questo è dettato indubbiamente dalla percentuale di adozione, ma raramente un utente Windows è anche un entusiasta. Spesso è un addicted o un power user, ma la differenza è sostanziale: un power user usa il computer all’estremo ma non necessariamente lo fa perché è “affascinato” dal computer in sé. Pensate ad un videogiocatore sterotipato: il fatto che il gioco sia su Windows è meramente una questione contestuale. Se fosse su Linux e girasse egualmente bene, gli importerebbe zero. Se fosse su XBox e girasse egualmente, gli impoterebbe zero. La differenza non è così sottile.

Gli utenti Linux sono invece fondamentalmente dei curiosi. Spesso, certamente, dei tecnici. Qualcuno probabilmente direbbe “gli ingeneri dell’informatica”, ove gli utenti Mac sono “i designer” e i Win “il popolo”, con differenti sfumature di dispresso in rapporto a quale gruppo appartenente. Gli utenti Linux quindi se vogliamo sono l’altra faccia della medaglia dell’entusiasmo: quella più tecnica.

Certo, son generalizzazioni, potreste ritrovarvici oppure no. Però sotto una certa angolatura, magari per voi molto particolare, queste tre categorie calzano. Magari ancora meglio se riuscite a non “offendervi” per la mia definizione di utente Windows.

Se ci pensate, ci vuole un bel coraggio da “power user” nel passare da un Windows a un Linux o un Mac. Non solamente perché potrebbe mancare quel bel programma che usavate (oggi problema sempre meno rilevante) ma perché non vi trovereste più a casa: non sareste quindi più dei power user, ma dei noob. Questo secondo me è un ostacolo che gli switcher trovano e uno dei motivi per cui c’è un eccessivo attaccamento a quello che, di fatto, è solamente uno strumento. Discorso che vale anche per chi Windows lo usa appena appena (“già faccio fatica qui, figuriamoci se cambio…”).