Lo stato dei client di posta elettronica

Mele e appunti

Circa tre settimane fa leggevo un articolo di Alex Payne dal titolo The Problem with Email Clients (Il problema dei client di posta), nel quale Payne presenta quelli che a suo avviso sono i pro e i contro dei client di posta come applicazioni a sé stanti (Mail di Apple, Thunderbird, ecc.) e della consultazione della posta via Web. Dalla panoramica tracciata da Payne, Gmail ne esce come il servizio più innovativo in questo settore negli ultimi anni, e la sua conclusione è che le applicazioni desktop di gestione della posta dovrebbero comportarsi più come l’interfaccia Web ma assolutamente non viceversa. Payne dice cose molto condivisibili, ma anch’io ho qualche considerazione da fare in proposito.

Il bello di Gmail

Payne inizia citando a sua volta un articolo estremamente a favore di Gmail scritto da Farhad Manjoo, che si occupa di scrivere di tecnologia per il sito Slate. Payne:

Manjoo ha assolutamente ragione nel sostenere che Gmail ha superato i client di posta sotto quasi ogni punto di vista. Parla della velocità di Gmail, della sua efficienza, del fatto che l’utente non deve preoccuparsi dello spazio/supporto di archiviazione, né di come funziona la ricerca ‘sotto il cofano’. Stranamente però Manjoo non cita una delle migliori scelte di design di Gmail: le conversazioni.

Gmail presenta gli scambi di email (i thread) come una lunga conversazione, partendo dal messaggio più datato e finendo con il più recente. Quando si ritorna a una conversazione, i messaggi più vecchi vengono visivamente compressi e quando serve esaminarne uno è possibile espanderlo. Non importa se altre persone si uniscono al thread, la conversazione rimarrà sempre un’unica pila di messaggi compatta, verticale, in ordine cronologico. È possibile archiviare intere conversazioni e queste torneranno in evidenza nella casella di Entrata in caso arrivino nuovi messaggi pertinenti.

Chiunque abbia provato estesamente Gmail noterà molto presto come le conversazioni siano una funzionalità indispensabile. Tornare a un qualsiasi altro client di posta è tremendo e disorientante. […]
Con le conversazioni, Google ha offerto l’unico vero progresso nell’architettura delle informazioni dei client di posta da decenni a questa parte.

Personalmente ritengo che sia una questione di abitudini. Ho iniziato a usare in maniera continuativa l’email dieci anni fa. Il mio client di posta è stato Netscape Messenger (il modulo Mail & News di Communicator) ed è durato, incredibile a dirsi, da Mac OS 8.6 fino ai tempi di Mac OS X 10.2 Jaguar. Si può dire che la definitiva transizione a Mail (a cui si è aggiunto in seguito Mailsmith) è avvenuta per me con l’uscita di Mac OS X 10.3 Panther. Ho sempre organizzato e letto la mia posta in ordine cronologico e mai per thread; per chi segue parecchie mailing list, l’organizzazione per thread sembra una buona idea, e in linea di massima lo è, ma basta che un partecipante alla discussione inizi un nuovo thread rispondendo a un messaggio di un altro thread e cambiandone l’oggetto, ed ecco che la preziosa organizzazione per thread cade come un castello di carte.

Proveniendo da questo tipo di organizzazione, ho trovato le conversazioni in Gmail un po’ disorientanti al principio (non sono nuovo a Gmail — lo uso da quando era in beta privata e gli inviti a disposizione si diffondevano col contagocce), e oggi non mi fanno né caldo né freddo. Sono utili senza dubbio, ma non le considererei “l’unico vero progresso nell’architettura delle informazioni dei client di posta da decenni a questa parte”.

Secondo me i punti di forza di Gmail sono altri, primo fra tutti l’interfaccia utente, che è indubbiamente frutto di duro lavoro per presentare con estrema semplicità una macchina complessa. Osservando l’interfaccia Web di Gmail, tutto è sott’occhio e raggiungibile con il minor numero di clic possibili. E la reattività rasenta e spesso eguaglia quella di un’applicazione a sé stante. E la supera nella gestione di migliaia di messaggi. Con un clic si accede alla cartella Spam, e con un altro clic si possono cancellare — come ho fatto ieri — 5392 messaggi di spam con la stessa velocità che Mail impiega a cancellarne 5. Questo grazie all’incredibile spina dorsale che supporta ogni servizio di Google, specie Gmail, e che rende possibili operazioni del genere a quella velocità. Semplicità d’uso, affidabilità, velocità nell’effettuare qualsiasi ricerca, e un’interfaccia efficace, che mette davanti all’utente solo la cosa più importante: la sua posta e i comandi necessari a gestirla. Quando osserviamo una delle nostre caselle Gmail aperta nel browser non vi sono immagini, né un’interfaccia graficamente intrusiva che distoglie l’attenzione o confonde l’utente con icone magari non riconoscibili da subito. Il testo la fa da padrone. La corrispondenza.

Il problema dei client di posta

Secondo Payne,

Il problema dei client di posta è che sono rimasti fermi, non vanno da nessuna parte, non accennano a evolversi. Mentre Google ha fornito soluzioni che migliorano l’esperienza dell’email, Apple, Mozilla, Microsoft e ora anche Postbox sono lì a girarsi i pollici e a guardare il soffitto. Nel consigliare l’impiego di un client di posta a sé stante, l’accento viene posto sul fatto che in tal modo si ha una copia di ogni messaggio archiviata sul nostro disco rigido, ma ormai anche questa lacuna è colmata. E allora perché si continua a utilizzare i client di posta?

Payne (si) risponde affermando che, in sostanza, le applicazioni Web — e Gmail su tutte — sono una gran bella cosa, fanno molto, ma non tutto (e bene):

Detta da uno sviluppatore di applicazioni Web quale io sono, questa potrà suonare come un’eresia, ma credo che le applicazioni Web in circolazione sono in gran parte orribili. Odio usarle. Quando devo risolvere un problema informatico, voglio farlo servendomi di un’applicazione rifinita, stabile e nativa, progettata per il mio sistema operativo d’elezione. Un’applicazione che sembri appartenere in tutto e per tutto al mio computer. Non credo nelle Rich Internet Applications — sono uno spauracchio che spero se ne vada una volta per tutte.

[…]

Mi piace usare Gmail, ma mi piacerebbe ancor di più se rispettasse le regole del mio sistema operativo, non quelle del Web. Il Web ha molto da offrire per risolvere certi tipi di problemi, ma non sono convinto che l’email sia uno di quelli.

Sono abbastanza d’accordo. Io continuo a preferire le applicazioni a sé stanti per la gestione della posta, perché malgrado la struttura solida che Google ha senza dubbio alle spalle, il fatto di non avere un archivio raggiungibile localmente non mi lascia tranquillo al 100%, e infatti ho configurato Mail e Mailsmith in modo che scarichino la posta in locale, pur mantenendo una copia sul server (lo considero un sistema rudimentale e semplice per avere un minimo di backup).

Sono con Payne anche quando sostiene che uno degli errori che i maggiori client di posta hanno commesso nei loro recenti sviluppi è quello di offrire nuove funzioni di dubbia utilità invece di concentrarsi sul potenziamento e l’ottimizzazione della gestione dei messaggi email. In effetti io dei Modelli di Mail non so che farmene, mentre invece ho accolto con piacere l’aggiunta dei feed RSS (Payne lascia intendere che l’implementazione è insufficiente, mentre a mio avviso va bene così — Mail non deve fare il lavoro di NetNewsWire o di Vienna; in più trovo coerente e intelligente la scelta di design per cui in Mail i feed RSS siano trattati come messaggi email).

Osservando i maggiori client di posta attualmente disponibili, a mio avviso le innovazioni più importanti devono riguardare soprattutto quel che l’utente non vede, ciò che sta dietro l’interfaccia. Quella è la lezione da imparare da Google. Migliorare le ricerche, migliorare il modo in cui i messaggi vengono archiviati, raffinare degli standard che permettano una migrazione indolore verso un altro client di posta, evitare inutili e astruse soluzioni proprietarie, usare — la butto lì — testo puro o al più XML e mettere il tutto in una directory di cartelle magari automaticamente criptata con PGP. E che il tutto sia in gran parte invisibile all’utente, che deve avere di fronte un’interfaccia chiara e incentrata sulla sua corrispondenza elettronica. L’utente deve avere sempre la sensazione che sia l’applicazione a piegarsi al testo, alla gestione dei messaggi email, e non il contrario.

I filtri, per dirne una, sono uno strumento molto potente, ma la loro implementazione è ancora troppo complessa. Gmail fa uno sforzo in questa direzione, e il sistema delle etichette è visivamente intuitivo; in più, quando si crea un filtro, Gmail permette di fare una ricerca previa dei messaggi che potrebbero corrispondere ai criteri indicati, come a dire: ‘questi sono i messaggi che saranno interessati dalle opzioni che hai specificato — va bene così?’. E questo è un buon sistema per avere conferma della bontà di un filtro. Ma si può fare di più: immagino un programma che mi permetta di creare una cartella e, basandosi sul campione di messaggi che sposto in quella cartella, che mi proponga la creazione del filtro. La tecnologia per effettuare questo genere di riconoscimento c’è già: i filtri bayesiani che permettono a un client di separare lo Spam dai messaggi buoni.

Queste sono le prime cose che mi sovvengono, ma vorrei avere una vostra opinione in proposito. Come vi trovate con i vostri client di posta? Vantaggi? Limitazioni? Quali funzioni vorreste vedere implementate? In che direzione si deve muovere l’evoluzione dei client di posta elettronica (o della webmail)? Sono genuinamente curioso.

Find Any File, senza dubbio

Mele e appunti

Circa due mesi fa, nel mio articolo intitolato Strumenti alternativi di ricerca, parlavo dell’allora recente scoperta Find Any File, un’utility scritta da Thomas Tempelmann che riportava al Mac il vecchio sistema di ricerca durato all’incirca dal System 7 fino a Mac OS X 10.3.9 e che, a differenza di front-end alternativi che migliorano l’interfaccia utente di Spotlight ma che si basano sempre sugli indici di Spotlight (come NotLight di Matt Neuburg), scansiona ogni volta il disco o i dischi specificati nella ricerca. Questo sistema, a tutta prima, può apparire più lento e macchinoso, ma qui lascio la parola a Tempelmann, che nelle FAQ scrive:

D: Non sapevo che la ricerca effettuata su un intero volume fosse così veloce.

R: Sì, e questo è il bello: il Mac OS offre la funzione di ‘ricerca veloce su un intero volume’ sin da quando è stato implementato HFS come filesystem, ossia per più di 15 anni, ed è stata utilizzata dalle applicazioni “Cerca Documenti” e “Sherlock” in versioni precedenti del sistema operativo. Quando tali applicazioni furono eliminate e sostituite da Spotlight, molti altri programmatori provarono a colmare la lacuna, ma apparentemente nessuno di essi pensò di sfruttare questa speciale funzione. Non ci potevo credere — quella funzione era estesamente documentata, eppure nessun programma ne faceva uso, malgrado effettuasse le ricerche su un intero volume. Un esempio abbastanza noto è EasyFind. La cosa mi irritò a tal punto che, dopo un’attesa di qualche anno nella speranza che altri ci arrivassero, decisi di rilasciare una mia utility che si servisse di quella funzionalità. E guarda un po’ — due giorni dopo aver rilasciato Find Any File, qualcun altro pubblicò un’applicazione simile (Find File) che si appoggiava sulla medesima funzione.

Nell’uso quotidiano, infatti, Find Any File non fa rimpiangere Spotlight, né in fatto di velocità, né soprattutto in fatto di precisione e presentazione dei contenuti. Da due mesi è ormai il mio strumento di ricerca preferito, al punto che ho configurato una scorciatoia per attivarlo rapidamente quando mi serve. Aperta parentesi: l’idea era quella di creare una scorciatoia da tastiera nuova che mi permettesse di attivare Find Any File senza bisogno di avere l’icona del programma nel Dock. Volevo qualcosa di comodo e veloce come ⌘-spazio (la scorciatoia di Spotlight), ma ho scoperto ben presto che in Mac OS X non è possibile fare una cosa del genere. Il pannello in Preferenze di Sistema > Tastiera e Mouse > Abbreviazioni da tastiera permette di configurare la scorciatoia per un comando già esistente all’interno di un’applicazione — o, tutt’al più, per richiamare un Servizio. Ma poi mi è venuta un’idea: sono andato nelle preferenze del Mouse e ho potuto assegnare al pulsante centrale del Mighty Mouse (ossia premendo la pallina) il comando “Apri Find Any File”. In questo modo avvio l’utility davvero velocemente. Chiusa parentesi.

Per avere un’idea generale di Find Any File, rimando al mio articolo citato all’inizio. Nel frattempo l’applicazione si è raffinata, e oltre ad avere un’icona più in stile Mac OS X presenta un paio di novità:

1. Se si tiene premuto il tasto Opzione mentre si sceglie Find, viene richiesta una password di amministratore, e Find Any File si riavvierà con permessi di root e sarà in grado di trovare davvero qualsiasi file nei volumi del Mac (cosa che Spotlight non fa). Si noti tuttavia che questo potrà funzionare soltanto con dischi locali, non con unità di rete montate localmente.

2. Presenta una nuova vista gerarchica degli elementi trovati. È possibile passare a questa vista premendo ⌘-2 o facendo clic sull’apposita icona nella parte superiore della finestra dei risultati.

Malgrado alcune limitazioni di Find Any File (l’interfaccia diventa poco reattiva durante ricerche complesse, ma per me non è un gran problema), in quanto a efficacia se confrontato con Spotlight non c’è partita. Un esempio: ho provato a cercare la stringa safari sul mio disco principale, prima in Find Any File poi in Spotlight. Con un occhio all’orologio, entrambe le applicazioni hanno impiegato una ventina di secondi (gli elementi trovati sono stati più di un migliaio); tuttavia, per avere dei risultati visualizzati in modo accettabile, con Spotlight ho dovuto prima fare clic su “Mostra tutto” nel menu in alto a destra, poi si è aperta una finestra del Finder dove mi venivano mostrati i risultati per “Contenuto” e non per “Nome documento” (come volevo io), e quindi Spotlight ha dovuto eseguire una seconda ricerca per mostrarmi i risultati come volevo. Quindi, in pratica, Spotlight si è dimostrato più lento e meno versatile. E comunque, anche visivamente, vince Find Any File, senza dubbio (clic per ingrandire):

Risultati della ricerca del termine "safari" con Spotlight.

Risultati della ricerca del termine “safari” con Spotlight.

Risultati della ricerca del termine "safari" con Find Any File

Risultati della ricerca del termine “safari” con Find Any File.

Si noti come con Spotlight sia più difficile capire in quale posizione si trovi un certo file nella gerarchia di cartelle e sottocartelle, specie in casi come questo in cui vengono trovate cartelle apparentemente identiche. Certo, facendo clic su un certo elemento il percorso viene visualizzato nella barra di stato della finestra del Finder, ma se l’elemento si trova in una posizione molto nidificata (come nella figura) la visualizzazione dei risultati di Spotlight non brilla per immediatezza. Con Find Any File la posizione dei file salta subito all’occhio e la vista gerarchica aiuta a orientarsi meglio con maggiore rapidità ed efficacia (sempre nell’esempio, è chiaro che non mi interessava trovare gli elementi della cartella SafariAnimals, e quindi sono passato oltre senza perdere tempo).

Ho scritto a Tempelmann per proporgli una localizzazione in italiano e magari anche in spagnolo.

Ulteriori considerazioni sull'interfaccia di Safari 4

Mele e appunti

Prima di tutto, una puntualizzazione

Da che è disponibile Safari 4 Public Beta si sono lette per il Web parecchie disquisizioni, soprattutto in merito all’interfaccia grafica, dato che Apple ha presentato cambiamenti sottili ma importanti. E anch’io, nel post precedente, ho mostrato quelle che a mio parere — e non solo mio — sono delle incoerenze serie, sia per quanto riguarda le HIG (Human Interface Guidelines) di Apple, sia per quanto riguarda la generale usabilità del browser.

Tutti questi discorsi all’utente medio (o comunque a digiuno di usabilità, accessibilità e teoria delle interfacce) possono sembrare questioni di lana caprina. In altre parole: “A me il nuovo Safari piace, chi se ne frega dove hanno messo i pannelli o come hanno cambiato la grafica”. Posizione sacrosanta. Del resto anch’io potrei tenere un blog un po’ diverso da questo, con articoletti di un paio di paragrafi, in cui scrivere la notizia “Wow, è uscita la beta pubblica di Safari 4. Top sites! CoverFlow! Più veloce! Andate a scaricarla”.

Ecco, Autoritratto con mele non funziona così. A me piace analizzare aspetti come la nuova interfaccia utente grafica, proprio perché non sono a digiuno di teoria delle interfacce, usabilità, accessibilità e design del software. A me piace tentare di portare tali questioni all’attenzione di chi magari non si interessa di queste cose e stimolare la sua curiosità. Parlando in generale, esiste ancora tanta gente che al sentir nominare la parola design alza gli occhi al cielo e crede che design sia qualcosa di superficiale, legato all’estetica di un oggetto o di un elemento, ossia del far qualcosa ‘bello da vedere’.

Ovviamente il design è molto di più. Basta osservare con attenzione gli oggetti più banali che ci circondano. La mia caffettiera Bialetti è costruita in modo che quando il caffè è pronto e io afferro la caffettiera per versarlo, la mia mano non si scotta, perché il manico rivestito ha una curvatura e una forma pensate e progettate per evitare un simile incidente. Il beccuccio ha una forma particolare che evita che gocce di caffè scorrano lungo la caffettiera mentre il caffè viene versato nella tazza.

Un esempio banale, ma che mostra come dietro qualsiasi cosa che usiamo quotidianamente vi siano una o più menti che hanno riflettuto su come costruirla al meglio. (Ovviamente non sempre ci azzeccano, ma questa è un’altra storia). Anche i computer. Anche i programmi che girano sui computer.

Veniamo a noi

Le mie considerazioni su Safari 4 Beta cercano di andare oltre i gusti personali. A me piace Top Sites, a me piace CoverFlow. Sono idee accattivanti e ingegnose. (Usavo CoverFlow ancor prima che fosse comprato da Apple e integrato in iTunes). A me piace la navigazione a pannelli in un browser e non tornerei mai indietro. Ma cerco di contestualizzare queste idee per capire se, oltre all’effetto puramente estetico, la loro applicazione e implementazione sia stata eseguita tenendo presente tutta una serie di fattori (usabilità, ottimizzazione per Mac con processori e schede video più datati, coerenza con il resto dell’interfaccia del sistema operativo, ecc.), oppure se le priorità sono state altre. E qui i gusti personali c’entrano poco.

A leggere le varie opinioni sulla nuova interfaccia utente grafica di Safari 4, poi, la confusione aumenta perché anche di fronte a questioni generali le correnti di pensiero sono disparate. C’è chi ritiene che i pannelli in alto (Tabs on top) siano una buona idea e una miglioria rispetto a Safari 3, c’è chi li ritiene una pessima idea fuori dalla logica dell’interfaccia di Mac OS X.

Fra i sostenitori della giustezza della nuova collocazione dei pannelli di Safari, c’è Lukas Mathis, che in un suo articolo recente sostiene che i pannelli in alto sono corretti perché rispettano la gerarchia degli elementi dell’applicazione e dei contenuti:

Gli utenti hanno un modello mentale di come le singole applicazioni funzionano. Tale modello descrive la logica interna che l’utente presuppone e si aspetta da una certa applicazione. [Questa logica] proviene sia da preconcetti sulla natura dell’applicazione, sia dall’esperienza diretta con tale applicazione. Una parte di questo modello mentale è la gerarchia degli elementi dell’applicazione.

Nel nostro esempio, i pannelli dovrebbero trovarsi logicamente sopra la barra dell’indirizzo, perché quando si passa da un pannello all’altro i contenuti della barra dell’indirizzo cambiano. La disposizione dei pannelli nella versione precedente di Safari — ossia fra la barra dell’indirizzo e la pagina Web — dava adito a confusione poiché contraddiceva il modello interno dell’applicazione, dando agli utenti dei falsi indizi sulla sua funzionalità e potenzialmente interferendo con il loro modello mentale dell’applicazione.

Anche secondo me l’idea di disporre i pannelli in alto è più rispettosa di tale gerarchia, ma gli ingegneri di Safari 4 sono andati ancora più in là e hanno eliminato del tutto il concetto di barra del titolo, che non è solo uno spazio inutile per mettere, appunto, il titolo di una pagina Web, è anche e soprattutto il ‘contenitore’ che crea la metafora dello spazio di lavoro. Togliendo questo elemento, oltre a creare i problemi (piccoli, forse, ma non trascurabili) di cui ho parlato nel precedente articolo, si elimina il concetto di ‘contenitore’ e l’applicazione Safari sparisce per diventare il sito e i siti che di volta in volta visualizza. Se ciò può avere senza dubbio i suoi lati affascinanti, per me è un problema concettuale, e oltre a essere incoerente con il resto dell’interfaccia di Mac OS X, va a interferire con il mio modello mentale di applicazione. Mi spiegherò con esempi visuali.

Per me un browser, e tutti i suoi pannelli, è come un’agenda, un planner:

planner1.jpg
planner3.jpg

Le pagine Web sono come i fogli di queste agende (anzi, forse è più appropriato considerarli i separatori) che si possono spostare aprendo i ganci e cambiando la posizione. Le etichette servono ovviamente a distinguere i contenuti:

planner2d1.jpg
planner2d2.jpg

La barra del titolo, insieme ad altri elementi grafici comuni a tutta l’interfaccia di Mac OS X (i pulsanti rosso, giallo e verde, di controllo della finestra, il contorno — che in Safari è più evidente se attiviamo la barra di stato in basso, ecc.) sono ciò che distingue l’applicazione Safari dai suoi contenuti. Se osserviamo le foto delle agende, l’analogia è con la copertina dura dell’agenda, sulla quale vengono montati i ganci — in una parola, la struttura stessa dell’agenda, il contenitore.

Sempre seguendo questa analogia, l’immagine che meglio raffigura la mia sensazione nel vedere violata ed eliminata la barra del titolo in Safari 4 Beta è questa:

planner-raw.jpg

Pannelli, pagine Web, l’uno di fianco all’altro, senza un contenitore. Quando afferro un pannello in Safari 4 si muove tutta la finestra, quando afferro un pannello in Safari 3 si muove solo il pannello. Ognuno ha la propria opinione e sensibilità, e soprattutto il proprio modello mentale per queste cose: a me sembra più logico il comportamento di Safari 3, che distingue fra pannelli e finestre/contenitori. Neanche i pannelli in Safari 3 erano perfetti, perché seguendo questa logica delle gerarchie, non ha senso che il pannello in primo piano sia visivamente collegato al chrome, alla cornice solida di Safari:

Safari3tabs-before.png

In realtà l’approccio più corretto (quel che avrei implementato io in Safari 4 al posto di massacrare la barra del titolo) mi pare il seguente (mi scuso con i grafici per i ritocchi artigianali all’immagine precedente):

Safari3tabs-after.png

Ossia, il pannello ‘esce’ dalla pagina Web sottostante, perché ne è il naturale prolungamento, ma rimane sempre subordinato al browser, che è l’applicazione che lo contiene.

E se fosse l’inizio di una nuova interfaccia?

In fondo in fondo, una parte di me sospetta che questo nuovo approccio al concetto dei pannelli in alto al posto della barra del titolo sia il precursore di un rinnovamento generale dell’intera interfaccia di Mac OS X. Chissà, magari dietro l’angolo ci attendono finestre del Finder a pannelli, disposizione degli account in Mail a pannelli, playlist in iTunes a pannelli (come già appaiono le diverse sezioni quando si collega un iPod o iPhone), pannelli pannelli pannelli.

Non sarebbe un’idea nuova, del resto. Gia nel 1979–1980, in fase di progettazione dell’interfaccia del Lisa, le finestre del ‘Finder’ erano pannelli. Si vedano le foto allegate a questa storia su Folklore.org, nello specifico questo trittico e quest’altro. Le finestre minimizzate sulla scrivania erano pannelli. Questo concetto è stato ripreso più avanti in Mac OS 8, con l’opzione di visualizzare le finestre nel Finder come ‘finestre a comparsa’. Con l’opzione attivata, era possibile minimizzare le finestre e farle apparire come pannelli la cui etichetta spuntava nella parte inferiore dello schermo. L’idea non era male, e il bello è che tutte le finestre ridotte a pannelli rimanevano persistenti anche dopo un riavvio, dando così all’utente la possibilità di disporre in fondo allo schermo tutta una serie di ‘finestre più usate’ senza dover fare doppio clic sulle rispettive cartelle ogni volta.

Mi auguro che, se questa dovesse essere la strada che Apple ha deciso di intraprendere, l’implementazione di una simile interfaccia a pannelli estesa a tutto il sistema (o alle sue parti notevoli) venga fatta tenendo presente la gran quantità di feedback che sono certo Apple starà ricevendo da qualche giorno. E soprattutto tenendo presente l’impatto dirompente che ciò potrà avere sui modelli mentali che gli utenti hanno su come funzionano un sistema operativo e le applicazioni che incorpora. Per non parlare dell’usabilità. Come sempre con Apple, attendo curioso.

Safari 4 Beta: prime impressioni

Mele e appunti

[L’articolo è stato aggiornato, 17:10 del 26 febbraio]

Quando era uscito Safari 4 Developer Preview, data la mia proverbiale curiosità verso i browser, lo avevo installato e provato subito, senza incontrare alcun problema (ne scrissi brevemente in questo post del giugno scorso). La Developer Preview era una versione piuttosto conservatrice rispetto a quella standard (che allora era la 3.1.1), e una delle novità a mio avviso interessanti era l’introduzione di una funzionalità che permetteva di salvare un sito Web come applicazione a sé stante (File > Save as Web application).

Ieri scaricavo Safari 4 Beta circa una mezz’ora dopo l’annuncio della disponibilità sul sito Apple. Leggendo che il nuovo Safari incorpora 150 nuove funzioni, ero molto incuriosito. Ho letto la presentazione sul sito in modo superficiale. Quel che conta, in questi casi, è l’impatto con il nuovo software. E ‘impatto’ direi che è il termine più appropriato in casi come questo.

Lo dico subito: era da tanto tempo che un’applicazione Apple ‘importante’ non mi lasciava così perplesso e combattuto. Perplesso per alcune scelte a livello di interfaccia utente a dir poco discutibili; combattuto perché vedo molti progressi sotto il cofano, vedo che Safari offre prestazioni obiettivamente superiori sotto molti aspetti, ma al tempo stesso quel che c’è sopra il cofano non mi piace e rende meno scorrevole l’esperienza d’uso. È come prendere un grande velocista come Carl Lewis e legargli insieme i lacci delle scarpe. Al via si ritrova faccia a terra.

Inciso: sono prime impressioni e sto cercando di esplorare bene Safari, e di metterlo sotto torchio per vedere se quel che non mi piace è dovuto all’abitudine alla vecchia versione del browser oppure no. Ma dalla discussione che è scaturita su Twitter fra i pezzi grossi del mondo Mac (sviluppatori, opinionisti, ecc.) pare vi sia una certa unanimità sullo ‘sgradimento’ di certe novità di Safari.

Finita la premessa, vengo al sodo.

1.

Vorrei poter fare due chiacchiere con il genio in Apple che ha avuto l’idea dei Tabs on top, cioè dei pannelli nella barra del titolo. Anzitutto si vede lontano un chilometro l’influenza di Google Chrome, solo che in Safari l’implementazione dei pannelli in quel modo è assolutamente forzata e, quel che è peggio, distrugge l’omogeneità dell’interfaccia grafica di Mac OS X (omogeneità già precaria di suo). Safari 4 Beta è la prima applicazione Mac OS X a non avere una barra del titolo. Sì, perché i pannelli diventano la barra del titolo. Qualche immagine per rendere l’idea:

Safari 4 Beta - tabs on top

(Clic per ingrandire)

Più apriamo pannelli, più la parte superiore diviene affollata e progressivamente inusabile:

Safari 4 Beta - more tabs on top

Inusabile perché, fra le altre cose, è più difficile fare clic sul pannello che si vuole portare in primo piano. Io, che pure ho un monitor abbastanza grande, ho già ‘mancato’ più di una volta un pannello, a volte finendo col puntatore sulla barra dei menu, a volte su un altro pannello, a volte nella barra dell’indirizzo. E poi, sempre per rimanere nelle finezze dell’interfaccia grafica, farei notare il quadratino di chiusura che appare facendo passare il puntatore sul pannello, soprattutto del pannello che rimane all’estrema sinistra:

safari4b-chiuditab.png

La vicinanza con il pulsante verde di ridimensionamento è paurosa. Sarò conservatore in questo, ma ritengo inviolabile l’area orizzontale che va dall’angolo superiore sinistro all’angolo superiore destro di una finestra e che comprende i pulsanti di controllo della finestra. Che è appunto l’area della barra del titolo. È una zona che, specie nell’interfaccia unificata grigio scuro di Leopard, dà eleganza alla finestra o applicazione, e permette all’utente una maggiore precisione nel premere i pulsanti rosso giallo verde, oppure un certo menu sulla barra dei menu, oppure la prima icona a sinistra della finestra, sotto i pulsanti colorati. Safari rompe questo schema a favore di un certo affollamento dell’interfaccia, che dà una sensazione di compressione degli elementi del browser. Tutto questo per guadagnare un po’ di spazio nella finestra principale? Suvvia. È chiaro che il compromesso non pesa a favore dei benefici di tale scelta.

Ora, per contrasto, osserviamo qualche esempio di browser che implementano una navigazione a pannelli inconsueta. In tutti i casi la barra del titolo viene preservata, e la navigazione fra i pannelli rimane efficiente.

Stainless, versione 0.4.5:

Stainless 0.4.5

e con più di un pannello aperto:

Stainless 0.4.5 - più pannelli

In Stainless, il pannello in primo piano è il più scuro, questo perché graficamente la logica è invertita rispetto a Safari 4 Beta. Ma si noti come viene rispettata la zona della barra del titolo, si noti la posizione più intelligente della x per chiudere il pannello e del + per aprirne uno nuovo; si noti infine che potendo visualizzare le icone dei siti (favicon), è molto più immediato orientarsi quando si ha una dozzina o ventina di pannelli aperti e i titoli delle pagine Web vengono brutalmente abbreviati per ragioni di spazio. Si osservi ancora la situazione in Safari 4 Beta con molti pannelli aperti: con la coda dell’occhio sono tutti uguali.

Ecco invece Opera 9.62 che, come Safari 4 Beta e Google Chrome, dispone i pannelli sopra la barra dell’indirizzo:

opera962-tabs.png

Anche qui la barra del titolo viene preservata; il pulsantino con la x per chiudere il pannello è a sinistra, come in Safari, ma osservando il pannello all’estrema sinistra la distanza rispetto ai pulsanti colorati di controllo della finestra è sufficiente per non fare pasticci, questo perché i pannelli hanno la loro fila, la loro propria area, e non invadono aree di altri elementi dell’interfaccia.

Che l’ispirazione di questo cambiamento di interfaccia grafica in Safari 4 Beta sia Google Chrome è evidente. E forse qualcuno obietterà alle mie osservazioni sui Tabs on top in Safari dicendo che, in fin dei conti, Google Chrome fa così e va benissimo, eccetera. Vogliamo rinfrescarci la memoria ed esaminare l’interfaccia di Google Chrome?

Google Chrome

.

Perché è così sobria ed efficace?

  1. Perché Google Chrome non ha mai avuto una barra del titolo.
  2. Perché Google Chrome non ha una barra dei menu.

Altro dettaglio: il pulsante [+] per aprire nuovi pannelli è in una posizione brillante: fuori dai pannelli aperti ma senza interferire con quei pochi elementi costanti nell’interfaccia grafica di Windows: i pulsanti Ingrandisci, Minimizza e Chiudi nell’angolo in alto a destra di tutte le finestre. Il [+] in Safari è più goffo, secondo me, e quando i pannelli aperti sono molti è facile perderlo di vista e fare clic sui menu extra nella barra dei menu, o sull’icona di Spotlight. Stainless (vedere figura sopra) ha copiato la logica di Google Chrome, e anche lì il [+] è collocato in una posizione più interessante.

Un altro passo indietro rispetto a Safari 3: il riposizionamento dei pannelli. In Safari 3 i pannelli sono pannelli e non parte integrante della finestra principale, quindi è possibile ‘afferrarli’ facendo clic in qualsiasi punto dell’etichetta e trascinando. In Safari 4 Beta la stessa dinamica porta allo spostamento di tutta la finestra del browser (come quando in una qualsiasi finestra si fa clic — indovinate dove? — sulla barra del titolo). Occorre individuare la linguetta nella parte superiore destra dell’etichetta, operazione non facilissima. Altra stupidaggine dal punto di vista dell’usabilità e dell’intuitività dell’interfaccia.

2.

Sempre in tema di cambiamenti all’interfaccia grafica, altre due — lasciatemelo dire — colossali idiozie sono la sparizione del pulsante Ricarica e la sparizione della barra di progresso azzurra in fase di caricamento di un sito. Adesso ci ritroviamo un’iconcina all’estrema destra della barra dell’indirizzo, che funziona come su iPhone. Solo che sullo schermo di un dispositivo piccolo e con interfaccia multi-touch il ‘pulsante’ Ricarica si vede ed è usabile. Sullo schermo di un Mac portatile o, peggio, su un monitor esterno da 20 e più pollici, non è così evidente e ho dovuto mettermi a cercarlo, anche arrivando a scegliere la personalizzazione della Barra Strumenti (ho pensato che il pulsante fosse disabilitato per default). Insomma, l’idea non funziona granché a mio avviso. In primo luogo, come ho già detto, perché in questo modo il ‘pulsante’ è meno visibile. L’utente ormai cerca automaticamente con il mouse il pulsante Ricarica accanto ai pulsanti Indietro e Avanti, visto che è tradizionalmente collocato in quella posizione. (Rompere tradizioni così radicate dell’interfaccia utente non è mai una bella idea dal punto di vista dell’usabilità, per non parlare del fatto che adesso il pulsante Ricarica si trova in una posizione assurda e poco evidente). In secondo luogo, il nuovo ‘pulsante’ Ricarica va a occupare il posto di un elemento diverso nelle precedenti versioni di Safari: il pulsante SnapBack. E visivamente non è nemmeno tanto differente:

Safari 4B - Reload

Pulsante Ricarica in Safari 4 Beta

Safari3-snapback.png

Pulsante SnapBack in Safari 3.2.1

E che cosa aveva fatto di male la barra di progresso azzurra per essere eliminata? Era uno dei dettagli più ingegnosi dell’interfaccia grafica di Safari, perché si notava immediatamente il progresso del caricamento di una pagina Web, anche senza guardare la barra di stato in basso. In tutti gli altri browser gli indicatori di progresso (barre, rotelline, logotipi animati) erano insufficienti o posizionati in angoli e punti a scarsa visibilità. Adesso c’è anche qui una rotellina piccola piccola, come se stessimo tutti lavorando su un iPhone.

[Aggiornamento: un altro dettaglio che mi era sfuggito mi fa dubitare ancor di più sulla nuova posizione del pulsante Ricarica. Ecco che cosa viene visualizzato nella barra dell’indirizzo quando si accede a pagine Web i cui contenuti vengono anche offerti come feed RSS:

Ricarica e RSS

Non è così facile centrare il pulsante per ricaricare la pagina, e mi è già capitato un paio di volte di fare clic sull’icona RSS. Per inciso, non è questione di essere incapaci o di vederci male. Moltissime aree dell’interfaccia grafica vengono raggiunte spostando il puntatore del mouse senza realmente seguirlo pixel per pixel. Se voglio fare clic sull’icona di Spotlight, per esempio, non è necessario che metta la freccetta esattamente sull’icona della lente di ingrandimento, mi basta spostare il puntatore nell’angolo lassù a destra e fare clic. Idem per il menu Apple sulla sinistra. La nuova posizione del pulsante Ricarica è inconsueta e l’unico altro browser ad averla identica è… MobileSafari su iPhone. E non tutti hanno un iPhone. E anche per chi lo possiede, come il sottoscritto, non è detto che sia altrettanto semplice da individuare e da premere quando si passa da iPhone al Mac. Proprio perché la posizione è inconsueta, e per il fatto che graficamente non è più da considerarsi un ‘pulsante’ vero e proprio, il pulsante Ricarica perde completamente in immediatezza.]

Pare che sia possibile far tornare la barra di progresso e la disposizione dei pannelli così com’erano prima — vi sono delle preferenze nascoste attivabili da Terminale (dare un’occhiata a questa pagina, per esempio), ma credo che andrebbero promosse a preferenze visibili e inserite nella sezione Aspetto/Appearance del pannello Preferenze di Safari.

3.

Un altro dettaglio migliorabile dell’interfaccia è la gestione dei siti protetti (gli https://, per intenderci). Comunemente i browser in circolazione evidenziano il fatto che si stia visitando un sito o pagina Web protetti utilizzando l’icona di un lucchetto e/o cambiando il colore della barra dell’indirizzo (Firefox, Camino, Google Chrome, ecc.). Questo è importante anche (e forse soprattutto) per segnalare visivamente all’utente quando si abbandona un sito o pagina protetti. Safari, va detto, non ha mai brillato sotto questo aspetto, limitandosi a mettere un lucchettino nell’angolo superiore destro della finestra del browser e nulla più, ma almeno chi usa Safari abitualmente sa dove guardare: anche avendo una dozzina di pannelli aperti, quando si portano in primo piano un sito o pagina protetti il lucchetto si trova sempre là in alto a destra. In Safari 4 Beta, che non ha più la preziosa area della barra del titolo, il lucchettino appare ancora più minuscolo nell’etichetta del pannello. Inutile dire che, con l’aumentare dei pannelli aperti, la visibilità del lucchettino diminuisce proporzionalmente, fino a sparire quando, con molti pannelli aperti, si passa sull’etichetta del pannello del sito protetto: il lucchetto viene coperto dalla x per chiudere il pannello. Geniale, eh?

4.

Top sites: idea non originale, ma si è cercato di implementarla in maniera originale rispetto ad altri browser. Il risultato è esteticamente gradevole, ma mi sembra un po’ chiassoso. Un browser non è iTunes. Un browser deve essere soprattutto efficiente e usabile. E qui mi arrabbio perché Safari 4 Beta contiene delle innovazioni che lo rendono — ed è stato misurato — più veloce e performante della concorrenza; solo che gli ‘abbellimenti’ a cui è stata sottoposta l’interfaccia grafica rendono l’esperienza d’uso generale leggermente frustrante. Quando ho avviato Safari la prima volta, la finestra principale per default si è aperta sui Top sites, cioè anteprime dei siti più visitati su cui si può fare clic per un accesso rapido. Safari si è messo a caricare furiosamente queste anteprime, poi è spuntata la rotellina colorata di Mac OS X, poi la finestra si è riempita di aberrazioni grafiche, poi “l’applicazione si è chiusa inaspettatamente”. Questo dopo più di tre minuti in cui non potevo far altro che guardare impotente Safari mentre arrancava nel tentativo di far qualcosa di utile. Per la cronaca: da che esiste Safari, si contano sulle dita di una mano le volte che è andato in crash sui miei Mac.

Qui il crash non ha niente a che vedere con fantomatici plug-in di terze parti (che non ho, a parte ClickToFlash, che funziona molto bene anche in Safari 4 Beta). Semplicemente, Safari sta cominciando ad avere requisiti grafici e di sistema un tantino esagerati per essere un browser e non l’ultimo gioco sparatutto o un programma professionale come Aperture, Logic, Final Cut Pro. È inconcepibile che un G4 a 1 GHz, con 1,25 GB di RAM e 32 MB di RAM video faccia fatica a far funzionare un browser. Ho persino chiuso il PowerBook per dedicare tutta la RAM video al monitor esterno da 20 pollici, ma sia Top sites che l’altra genialata (adesso arrivo anche a questa) — CoverFlow nella finestra di gestione dei bookmark e nella ricerca visuale della cronologia — caricano imperdonabilmente la CPU di lavoro extra e rendono Safari al limite dell’utilizzabile, oltre che assai lento. Non oso pensare cosa avviene su un G3 con 8 o 16 MB di RAM video…

CoverFlow: lo ripeto, Safari non è iTunes. (Neanche il Finder, se volete la mia opinione, infatti è molto raro che io ricorra alla vista CoverFlow nel Finder). È visivamente carino e impressionante ‘sfogliare’ la cronologia e i bookmark con CoverFlow quasi a tutta pagina. Ma utile? Non saprei dire fino a che punto. Non è insensato nel caso della cronologia: con tutti i siti che si visitano in una giornata di lavoro, un’immagine vale sicuramente più di tanti URL spesso lunghi e poco informativi. Forse si può dire lo stesso per i bookmark, ma nel caso dei bookmark perché la vista CoverFlow si può solo ridurre e non disattivare? Soprattutto nei casi in cui, a quanto pare, la scheda grafica è al limite della sufficienza per rendere il tutto un minimo utilizzabile. In una giornata di uso non sono riuscito a navigare fluidamente né nella cronologia né tantomeno fra i miei bookmark. O Safari si bloccava con rotellina colorata, o andava in crash.

Che devo fare, comprare un Mac con Core 2 Duo e 4 GB di RAM solo per usare decentemente Safari?

No, faccio prima a cambiare browser. Tra l’altro è da ieri che OmniWeb e altre tre applicazioni di The Omni Group sono diventati freeware.

Però, come dicevo all’inizio, sono combattuto. Safari 4 Beta ha alcune novità che mi piacciono, e molto. I siti si caricano in un batter d’occhio, i suggerimenti che appaiono quando si inizia a digitare una URL sono molto ma molto più efficaci che in altri browser (come Firefox), e a parte i difetti sin qui trattati (di cui ho già mandato feedback ad Apple e spero siano ‘imperfezioni da beta’), le prestazioni e la stabilità quando si naviga sono notevoli. Siti come Gmail sono molto più reattivi, per esempio. Inoltre pare che di questo tipo di modifiche sotto il cofano beneficerà anche il prossimo MobileSafari, il che non è male. Sono curioso di vedere come sarà la versione definitiva, e spero che venga ulteriormente raffinata e ottimizzata in modo da rendere Safari utilizzabile anche da chi non possiede l’ultimo dei MacBook Pro unibody.

Apple, i netbook e i pezzenti

Mele e appunti

Spezzo la serie di post dedicati al Newton con un breve ‘ritorno di fiamma’ sui netbook. Alla FNAC di Valencia, da prima del periodo natalizio, hanno creato un’isola in cui esporre esclusivamente netbook di ogni marca e colore. Sta giusto di fianco all’elegante isola Apple, con tavolo in legno chiaro e colonna metallica nera con il logo Apple illuminato. Vado abbastanza spesso a fare un giro alla FNAC con mia moglie, vuoi perché ci può essere qualche occasione o novità fra i DVD, o perché ho voglia di sfogliare libri su arte, design e tipografia che non mi potrò facilmente permettere, o perché ho sentito della musica nuova e voglio vedere se trovo il CD (sono ancora un po’ vecchio stampo e continuo a preferire il CD per i miei acquisti, specie se si tratta di jazz o musica classica).

Insomma, continuo a vedere l’isola dei netbook per lo più deserta; magari qualcuno di tanto in tanto chiede un paio di informazioni al commesso di passaggio, ma in linea di massima non mi pare che attragga molti visitatori. Al contrario, è molto, molto difficile avvicinarsi ai MacBook e MacBook Pro unibody esposti nell’isola Apple. Se voglio smanettare un po’ con quel che (spero) sarà il mio prossimo acquisto, devo aspettare fino a circa una mezz’ora prima dell’orario di chiusura.

Mi spiace reiterare, ma più passa il tempo, meno sono convinto che Apple abbia interesse a buttarsi nel mercato dei netbook (sempre che ve ne sia uno per davvero). Ieri sera pensavo proprio a questo, poi ho letto l’articolo di Adrian Kingsley-Hughes a cui rimanda il solito John Gruber e, beh, Kingsley-Hughes mi ha tolto le parole di bocca, pur con un tono forse più provocatorio.

Il suo intervento è ben riassunto nel titolo: Credete davvero che Apple sia disposta a seguire i consigli commerciali di un branco di pezzenti?

E il nocciolo del discorso è:

Vedete, esistono due scenari ben distinti. Nel mondo reale troviamo Apple, un’azienda multimiliardaria che si è creata una propria nicchia come compagnia che produce tecnologia esclusiva. Vendendo in tutto il mondo i suoi prodotti a prezzi relativamente alti, quest’azienda ricava miliardi di dollari ogni anno. È anche un’azienda che ha 25 miliardi di dollari (sì, miliardi) in banca, e non ha debiti. Sotto ogni punto di vista, Apple è in buona salute.

Però poi, in qualche bizzarro universo parallelo, vi sono dei tizi che vorrebbero disperatamente che Apple si avventurasse nei territori dei PC a poco prezzo e dei netbook, segmenti di mercato che notoriamente producono margini di profitto davvero esigui e in cui si azzuffano almeno una dozzina di altri nomi importanti fra i costruttori di PC. Se si considerano le varie posizioni dei personaggi appartenenti a questo bizzarro universo parallelo, alla fine la conclusione è una: Apple dovrebbe produrre un computer a basso costo per soddisfare le esigenze del consumatore taccagno.

[…]

Certo, se potessi comprare un Mac Pro a 500 dollari, lo comprerei, ma sicuramente non mi metterei a creare una vuota discussione dicendo che Apple dovrebbe vendere sistemi a basso prezzo solo perché a me farebbe comodo. Apple, in realtà, non dovrebbe. Almeno finché il suo attuale modello di business le fa guadagnare denaro. Sicuro, oggi si spende meno, e i netbook sono indubbiamente interessanti. Ma occorre vendere parecchi netbook per eguagliare i profitti di un MacBook Pro o di un iPhone.

In sostanza, come scrivevo ieri su Twitter, forse qualcuno sente il bisogno di comprare un netbook marcato Apple, ma Apple non sente il bisogno di (produrlo e) venderlo, almeno non ora.