Il browser ideale

Mele e appunti

In questo periodo, se non si è capito, mi è tornato il pallino dei browser. Come scrivevo di recente in un commento, si possono trovare essenzialmente due approcci all’utilizzo del browser. Esiste un tipo di utente che vede il browser come qualcosa di monolitico: il browser deve essere uno e un solo, deve funzionare al meglio, e non si dà altro browser all’infuori di ______ (inserire un nome a piacere). Esiste un altro tipo di utenza che usa più browser, vuoi perché certi siti sono meglio visibili e/o utilizzabili con un browser diverso dal preferito, vuoi per preferenze personali. Io appartengo a questa seconda categoria. Recentemente, poi, ho provato addirittura a lasciar da parte i browser preferiti (Safari e Camino) e a usarne altri, appuntandomi cosa gradivo e cosa non mi piaceva granché. Però, invece di scrivere uno ‘speciale’ su punti di forza e debolezze dei vari browser provati, ho preferito fare un piccolo gioco: pensare a un browser ideale, che racchiuda quelle che ritengo siano le funzioni più utili, interessanti e distintive dei singoli browser attualmente a disposizione. Un browser ‘Frankenstein’, se vogliamo.

L’elenco che segue è tutt’altro che esaustivo, e naturalmente riflette inclinazioni e abitudini personali. (Si danno per scontate cose come il rispetto degli standard Web). Per me, questo ‘super-browser’, che chiamerò Columbus, dovrebbe avere:

  • Di Safari: il motore di rendering WebKit. Il Web Inspector. L’implementazione dei profili colore. L’interfaccia pulita e Mac-like. Il lettore integrato di feed RSS.
  • Di Camino: il blocco della pubblicità. L’esiguo consumo di risorse CPU. La robustezza (di tutti i browser che uso da anni, Camino è in assoluto quello che è andato in crash meno frequentemente. A memoria, l’ultimo che ho sperimentato avvenne sotto Mac OS X 10.2).
  • Di OmniWeb: la gestione dei bookmark (è possibile specificare parecchie informazioni per ogni bookmark, per raffinare le ricerche; si veda anche questo mio post). La possibilità di visualizzare le miniature dei siti quando si utilizza la navigazione a pannelli. La possibilità di impostare preferenze specifiche per ogni sito.
  • Di Firefox: la possibilità di estendere le funzioni del browser attraverso le estensioni. La gestione e la ricerca dei bookmark (direi che al momento è la migliore, insieme a OmniWeb; ne parlo brevemente nel mio post sulla prova di Firefox 3 Beta 4).
  • Di Shiira: la comoda navigazione a schermo pieno. L’implementazione di exposé nella navigazione a pannelli (peccato che al momento lo sviluppo di questo browser sembra fermo. Ho smesso di utilizzarlo perché semplicemente è troppo incompleto e instabile sotto Leopard).
  • Di iCab: il gran numero di opzioni disponibili nelle preferenze, che lo rendono un browser estremamente capace e flessibile. La compatibilità con Mac anziani (PowerPC pre-G3) e antichi (Motorola 680x0). Il controllo al volo della sintassi HTML dei siti visitati. L’implementazione di exposé nella navigazione a pannelli (più lenta di Shiira, ma al momento è l’unico browser su cui funziona, e l’implementazione non è priva di eleganza).
  • Di Netscape 9: [sì, ho preso in considerazione anche questo browser che non viene più ufficialmente sviluppato e supportato da marzo 2008] il Link Pad e la possibilità di avere un mini-browser nella barra laterale della finestra principale. Il Link Pad è una sorta di area di parcheggio per quei link che vogliamo appuntarci temporaneamente, senza dover per forza aggiungere il tal sito ai già numerosi bookmark. Basta fare un drag and drop sull’area del Link Pad, o fare Ctrl-clic su un link e dal menu contestuale scegliere di salvarlo nel Link Pad (un esempio).
  • Di SeaMonkey: i moduli Mail & Newsgroup e Composer, così da avere client di posta ed editor HTML in un unico ambiente (visto che al nostro browser ideale non deve mancare nulla).
  •  

    Un grande assente da questo elenco è Opera. La versione 9 non mi fece impazzire più di tanto. È da ieri che sto provando la 9.5 e mi piace il lavoro che hanno all’interfaccia grafica. Tuttavia non ho ancora trovato funzioni particolarmente distintive per questo browser che possano essere inserite nell’elenco qui sopra. Si accettano suggerimenti. E aggiunte: se qualcuno ha notato qualche altra funzione ‘indispensabile’ presente nei browser citati che a me è sfuggita, faccia sapere.

    Ancora sulle voci di menu disabilitate: Tooltip e Aiuti Veloci

    Mele e appunti

    Se avete trovato interessante l’argomento trattato dal post sulle voci di menu disabilitate, e ve la cavate con l’inglese, c’è un altro post interessante oltre al breve commento di Gruber: Disabled Menus Are Usable (I menu disattivati sono usabili), un articolo che Daniel Jalkut, ex dipendente Apple e sviluppatore di vari software interessanti per Mac, ha di recente pubblicato nel suo blog.

    Nei commenti si fa riferimento ad alcuni sistemi per fornire ulteriori informazioni all’utente sugli elementi dell’interfaccia grafica. Un esempio eminente è l’utilizzo dei Tooltip, piccole etichette gialle che appaiono avvicinando il puntatore del mouse a pulsanti, opzioni ed elementi dell’area di lavoro di un’applicazione, e che informano brevemente sulla funzione di quel dato elemento. Esempio banale:

    tooltip.png

    .

    I tooltip non sono una cattiva idea, ma sono perfettibili. L’ideale sarebbe che la loro presenza fosse standardizzata, estesa in maniera uniforme e prevedibile a tutte le applicazioni del sistema, agli elementi dell’interfaccia, alle voci di menu… Beh, in realtà un sistema del genere già esiste, o meglio è esistito dal System 7 a Mac OS 9.2.2: gli Aiuti Veloci (Balloon Help), ovvero l’Aiuto contestuale, quei fumetti che, se abilitati, apparivano ogni volta che si fermava il puntatore del mouse su un qualsiasi elemento dell’interfaccia grafica del Mac: Barra del titolo di una finestra, pulsanti di una finestra, elementi come il Cestino o dischi montati sulla scrivania, icone di pannelli di controllo, estensioni, e così via. Compresi i menu e le voci di menu. Comprese le voci di menu disabilitate (clic per ingrandire):

    .

    In questa figura si può vedere come l’Aiuto a fumetti spieghi perché la voce di menu “Cancella” è grigia (disattiva). Passando il puntatore sulle voci attive, l’Aiuto dà informazioni sulla loro funzione. Quando il contesto fa in modo che una voce di menu, da disabilitata, si attivi (perché vi è un documento aperto da manipolare, perché vi è del testo selezionato, perché una certa finestra è in primo piano, eccetera), ecco che il testo contenuto nell’Aiuto a fumetti cambia dinamicamente e spiega la funzione di quel comando. Forse sembrerà nostalgia se dico che mi piacerebbe rivedere questo tipo di Aiuti Veloci su Mac OS X, ma in realtà si tratta semplicemente di rivolere un’idea, vecchia finché si vuole, ma indubbiamente migliore e più usabile dell’implementazione attuale dell’Aiuto di Mac OS X.

    Qualcosa si muove dietro le quinte

    Mele e appunti

    Un’ora e mezza fa circa, Mail, apparentemente di testa sua, si è messo a sincronizzare la mia casella .Mac. O forse è meglio dire ‘ricostruire’. La finestra attività mi ha infatti informato che Mail stava comunicando con il server .Mac e riscaricando tutti i messaggi nella Casella di entrata [.Mac], ma anche tutti i messaggi in uscita da [.Mac], nonché tutti gli allegati.

    ricostruisci-mac.png

    (Si noti per altro l’abbagliante refuso Communico). Quattro anni di posta. Ci ha messo un’ora.

    Che sia Apple che sta preparando i server per l’aggiornamento a MobileMe? Sarei curioso di sapere se è accaduto qualcosa di analogo ad altri utenti .Mac.

    Sulle voci di menu disabilitate

    Mele e appunti

    Joel Spolsky, noto programmatore in ambiente Windows, ha scritto di recente nel suo blog un articolo (piuttosto corto e per nulla approfondito, aggiungerei) dal titolo Don’t hide or disable menu items, ossia “Non nascondere o disabilitare le voci di menu”. La mia traduzione del pezzo:

    Tempo fa si usava spesso, ed era persino consigliato, disabilitare voci di menu quando non potevano venire utilizzate.

    Non fatelo. Gli utenti vedranno la voce di menu disabilitata sulla quale vogliono fare clic, e non avranno alcuna idea di ciò che dovrebbero fare per attivarla.

    Invece, lasciate la voce di menu abilitata. Se esiste qualche motivo per cui non è possibile completare l’azione, la voce di menu può visualizzare un messaggio che spieghi all’utente perché 

    Puntuale, come al solito, il commento di John Gruber:

    Questo è un chiaro esempio del perché Spolsky sia uno sviluppatore Windows e non Mac. Disabilitare le voci di menu quando non è possibile utilizzarle è una buona pratica — significa che lo stato visivo di un menu riflette lo stato effettivo del comando che rappresenta. Uno può sostenere che questo possa confondere gli utenti che non capiscono perché una certa voce di menu sia al momento disattivata [appare ingrigita richiamando il menu], ma è uno dei più classici compromessi. La pratica suggerita da Spolsky, ovvero di lasciare sempre e comunque attive tutte le voci di menu, e mostrare un avviso quando vengono richiamate anche se non possono venire usate, sarebbe molto irritante ogni volta che l’utente si imbattesse in una tale situazione. (Mi ricorda anche certe applicazioni Mac assolutamente prive di aiuto in linea, ma che visualizzano comunque il menu Help / Aiuto, con una voce di menu tipo “NomeApplicazione Help” o “Aiuto NomeApplicazione” che non svolge nessun compito se non quello di visualizzare un messaggio che dice “L’aiuto non è disponibile per NomeApplicazione”).

    Il suggerimento di Spolsky si basa inoltre sulla presupposizione che l’utente sia stupido. Meglio dare per assodato che l’utente sia intelligente e curioso di investigare da solo il perché un certo comando sia al momento disattivato. 

    A me ricorda anche una scelta di design analoga, e ugualmente irritante, dell’ambiente Windows (almeno fino a XP): i ‘clic perduti’, ossia il fatto che un pulsante (di un pannello o di una finestra di dialogo) riconosca comunque il clic del puntatore del mouse anche quando in realtà l’applicazione è bloccata, congelata o non responsiva per qualsiasi motivo. Si fa clic su “Annulla” o “OK”, si crede che il clic abbia avuto effetto, e invece nulla: il pannello rimane lì, la finestra di dialogo pure, e non si è sicuri se l’applicazione abbia davvero registrato il nostro input. Sul Mac OS classico ricordo che, in una situazione analoga, un indizio del fatto che qualcosa non stesse funzionando era che il pulsante si ‘accendeva’ ma non ritornava sulla posizione di ‘spento’ e l’utente capiva la piega che stava prendendo la situazione. Su Mac OS X, di solito, non c’è feedback, ovvero si fa clic sulla finestra di dialogo ma tutto rimane rigidamente come prima.

    È interessante vedere, anche da sottigliezze come queste (mi riferisco ai consigli di Spolsky), la differente prospettiva e mentalità dello sviluppare per una piattaforma o per l’altra. E vedere come l’usabilità di certe parti di un’interfaccia venga più o meno compromessa anche da piccole scelte come queste.

    Mozilla e i temi di una volta

    Mele e appunti

    Ho scaricato Firefox 3, ma non durante la gran fanfara voluta dalla Mozilla Foundation per battere uno stupido record. Semplicemente, qualche giorno fa ho aperto la versione di Firefox che avevo (3.0 beta RC1) e mi ha chiesto se volevo aggiornare. Sì, grazie. Finita lì.

    Avevo parlato molto bene di Firefox 3 quando scaricai la Beta 4 — fui particolarmente colpito dalla gestione dei bookmark, che è senza dubbio la funzionalità più interessante di questo browser, a mio avviso. È una spanna avanti rispetto a Safari e Camino (e una mezza spanna rispetto a OmniWeb), ma per il resto lo utilizzo saltuariamente e lo tengo sui miei Mac nel metaforico armadietto dove conservo i browser, perché a me piace testarli e mi interessa in generale lo sviluppo di questo particolare tipo di software. Sarà perché una decina d’anni fa ero uno dei molti beta tester di Netscape/Mozilla, quando le beta di Mozilla si chiamavano ancora Milestone (M09, M10, ecc.).

    Sarà per questo che non riesco ad appassionarmi a Firefox, né mi ha particolarmente esaltato la gran festa intorno alla versione 3. Se mi si passa l’immagine, direi che Firefox, pur rimanendo radicato nell’ambito open source, ha un retrogusto commerciale che mi lascia piuttosto freddo. È un progetto che ha preso coscienza del fatto che può ‘fare carriera’, in un certo senso. Niente di male, e tanti auguri, però continuo a preferire Camino, sia nello spirito, sia nel concreto, limitandomi al prodotto software che, come ho commentato di recente, alla versione 1.6 fa già bene quel che Firefox fa alla versione 3. Camino è più Mac nell’interfaccia e, se vogliamo, nella filosofia spartana che lo contraddistingue. Osservando Monitoraggio Attività, Firefox con 2 pannelli aperti consuma RAM e cicli processore circa quanto Camino con 3 pannelli aperti. Camino ha meno funzioni, non ha una gran gestione dei bookmark, i pannelli non si possono riorganizzare con il drag and drop, ecc. Ma ha una funzione che né Firefox né Safari hanno (e che per averla, se non erro, necessitano di plug-in di terze parti): il blocco della pubblicità Web. Non parlo tanto di finestre pop-up, ma degli antipaticissimi banner (spesso animazioni Flash) che istoriano parecchi siti. Attivando l’opzione “Block Web advertising” nel pannello Web Features delle preferenze di Camino si può dire addio agli odiati banner. (Anche OmniWeb incorpora questa funzione).

    Un altro browser della famiglia Mozilla che sto provando è SeaMonkey, vera e propria reincarnazione della suite Netscape/Mozilla che tanto amavo. Proprio come Netscape prima e Mozilla poi, SeaMonkey non è solo browser, ma è costituito da una struttura a moduli composta da un browser (Navigator), un client per la gestione di posta e newsgroup (Mail & Newsgroup), un editor HTML (Composer), e un client di chat IRC (ChatZilla). Non incorpora la rinnovata gestione dei bookmark di Firefox, ma a parità di finestre e pannelli aperti consuma meno risorse. Come reattività e velocità percepita lo trovo a un livello intermedio tra Firefox e Camino (essendo Camino il più ‘scattante’). Dico ‘percepita’ perché il motore di rendering è sempre Gecko per tutti e tre i browser. Il resto, credo, sta tutto nell’ottimizzazione. Un’altra cosa che trovo gradevole di SeaMonkey è la possibilità di installare vecchi temi che erano ormai spariti dalla circolazione e che qualcuno ha pensato bene di risuscitare. Ho potuto così installare il mio preferito da sempre: Venerable Modern. Per Firefox 3, come si suol dire, non c’è trippa per gatti. Quasi quasi torno alla homepage di Camino e chiedo di entrare come beta tester…