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.

Ancora Newton: il bug del 2010

Mele e appunti

Come accennavo nella prima parte della mini-serie sulla storia del Newton, il problema più grosso che affligge oggi la comunità di utenti Newton è il cosiddetto ‘bug del 2010’. Questo problema si riteneva pressoché risolto, dato che tempo addietro Avi Drissman (programmatore noto alla comunità Newton soprattutto per l’ottimo Avi’s Backdrop, un’elegante applicazione per la ‘scrivania’ del Newton che consuma pochissime risorse) aveva rilasciato un programma chiamato Fix2010 (vedere la pagina del sito di Drissman dedicata al software per il Newton). Il programma, però, è tuttora in alpha, e dopo che alcuni membri di NewtonTalk si sono presi la briga di installarlo e collaudarlo si è constatato che non è risolutivo e, almeno sui MessagePad con l’ultima versione del NewtonOS (2.1), i problemi rimangono.

Eckhart Köppen, uno degli sviluppatori Newton rimasti ancora molto attivi (è autore, fra le altre cose, di un browser, di un lettore di RSS, e di una serie di plug-in per il Newton che ne espandono le possibilità — senza di lui non avremmo il Bluetooth sul Newton), ha deciso di investigare il problema e ne parla in questa pagina del suo sito. Eccone una traduzione:

Il problema dell’anno 2010 nel Newton

Il NewtonOS presenta un bug nella gestione degli anni a partire dal 2010. Il bug si trova nell’interfaccia NewtonScript inerente a determinate funzioni temporali, ed è provocato da un overflow di un valore intero di NewtonScript. Tale bug sembra manifestarsi soltanto in dispositivi con NewtonOS 2.1.

L’orologio del Newton

Nei dispositivi 2.1, il Newton prevede un orologio in tempo reale ad alta risoluzione (RTC — Real Time Clock). L’interfaccia verso il RTC è la classe TURealTimeAlarm in LongTime.h. I valori temporali vengono registrati in oggetti della classe TTime. Il RTC può gestire intervalli di tempo molto lunghi, ma la maggior parte delle funzioni utilizzano numeri interi non firmati a 32 bit come secondi a partire dall’1 gennaio 1904.

Classi e Funzioni

C++

Le funzioni C++ più comuni sono le funzioni RealClock e RealClockSeconds per leggere il RTC, e le funzioni SetRealClock e SetRealClockSeconds per impostare il RTC. La base per tutte queste funzioni è sempre l’1 gennaio 1904, e la risoluzione è in minuti o secondi. L’uso di un numero intero non firmato a 32 bit crea un problema di overflow nell’anno 2040. In generale, si possono considerare tutte le funzioni C++ sicure e senza problemi fino al 2040.

NewtonScript

Le funzioni NewtonScript sono tutte basate sul RTC — non esiste un orologio mantenuto separatamente per il livello del NewtonScript. Tali funzioni si basano sulle funzioni RealClock descritte sopra, e funzionano con risoluzione in minuti o secondi.

La funzione Time funziona con una base temporale incentrata sull’1 gennaio 1904. La funzione TimeInSeconds, e tutte le funzioni che utilizzano i secondi come risoluzione si servono di una base temporale che parte dall’1 gennaio 1993.

Il bug

L’overflow avviene in tutte le funzioni NewtonScript che utilizzano i secondi come risoluzione. A differenza del numero intero non firmato a 32 bit impiegato dalle funzioni C++, gli interi in NewtonScript sono soltanto a 30 bit. Mentre le funzioni C++ possono gestire l’intervallo fra il 1904 e il 2040 senza un overflow, le funzioni NewtonScript devono essere ideate con un intervallo minore a causa della loro limitata precisione.

Le funzioni basate sui secondi vengono implementate prendendo il valore dell’orologio in tempo reale (RTC), sottraendo lo spostamento all’1 gennaio 1993, e convertendo il risultato in un numero intero NewtonScript. Questo intervallo più ristretto e limitato provoca un overflow nel 2010.

I possibili fix

Riformulare una base per le funzioni temporali basate sui minuti

Il problema di un overflow nelle funzioni basate sui secondi è provocato dall’orologio di sistema che raggiunge e supera la data dell’overflow. Assicurandosi che l’orologio di sistema rimanga all’interno dell’intervallo ‘sicuro’, è possibile evitare l’overflow. Questo tipo di soluzione è stato implementato da Avi Drissman nel pacchetto Fix2010. Fix2010 impiega il concetto della ‘hexade’ (ossia 16 anni) e regola tutte quelle funzioni che si servono dei minuti come base temporale in modo che rientrino sempre nell’intervallo di tempo ‘sicuro’, tenendo conto della differenza di intervallo del gruppo di sedici anni.

Riformulare una base per le funzioni temporali basate sui secondi

Un approccio più a basso livello è quello di cambiare la compensazione impiegata dalle funzioni basate sui secondi in modo che l’intervallo di tempo ‘sicuro’ inizi e finisca più tardi.

Considerazioni

Per ognuna delle soluzioni, occorre tenere in considerazione alcune insidie. Le parti del NewtonOS non sistemate potrebbero attivarsi prima che la patch entri in funzione (per esempio al riavvio o dopo un cold boot), e certi dati potrebbero presentare dei valori errati. Per ora rimangono aperte le seguenti problematiche:

  • Lo stato dell’orologio dopo la perdita del tempo: l’orologio in tal caso si resetta e torna al 1996, e questo valore può entrare in conflitto con le funzioni a cui è stata applicata la patch.
  • Gli allarmi: gli orari in cui è stato impostato un allarme potrebbero essere alterati se l’allarme è stato inserito senza la patch.
  • Certe assunzioni precodificate inerenti alle basi temporali: quei programmi che presumono che le funzioni basate sui secondi inizino sempre nel 1993 potrebbero smettere di funzionare.

È interessante inquadrare tutta la questione alla luce delle osservazioni dell’ex ingegnere Newton che ho pubblicato nelle quattro parti sulla storia del Newton. È chiaro che per applicare una simile patch occorre effettuare un reverse-engineering dell’ultima patch di sistema, che è quel che ha fatto Köppen qualche giorno fa, scrivendo in lista NewtonTalk: Pare che creare delle patch proprie sia meno complicato di quel che si pensava. […] Sono stato in grado di ricreare la patch originale [717260] dai sorgenti e fare qualche esperimento con piccole modifiche. Esistono ancora dei problemi da risolvere, ma in generale è di certo meno magia nera di quanto anticipato. In bocca al lupo, Eckhart. Documenterò eventuali risoluzioni.