Sciocchezze più e meno serie

Mele e appunti

1.

Durante l’installazione del nuovo Adobe Reader 9 facciamoci accompagnare dai commenti di Gus Mueller. Ironia sua e tragicommedia di Adobe, che col passare del tempo mi sembra cadere sempre più in basso.

Traduzione delle didascalie:

- La decompressione è fornita da chi? Perché dovrebbe importarmi? Che fanno, mettono la pubblicità sugli installer?

- “Recomposition”: questa mi giunge nuova. Cos’è, un’altra parola per dire “decompressione”? (Fornita da INOSSO, naturalmente).

- Ok, è venuto il momento di lanciare l’applicazione. Oh certo, Adobe Reader ha una sua cartella specifica in /Applicazioni… che contiene semplicemente l’applicazione e un file Leggimi. Non avrebbe più senso mostrare il file Leggimi all’avvio del programma e mettere soltanto Adobe Reader in /Applicazioni? Naah, macché.

- Primo avvio. Una barra dei menu senza menu, poi questo messaggio. Perché la cosa non mi sorprende?

- Ma tu pensa.
— Ehi, avete sentito che il PDF adesso è uno standard ISO? Wow! (fine del sarcasmo) 

* * * * * *

2.

Divertentissima e brillante risposta di Macalope a questo articolo totalmente idiota scritto da Anita Hamilton su Time, la quale Hamilton si chiede perché Apple non mette a disposizione gratuitamente tutte le applicazioni per iPhone dell’App Store prossimo venturo. Traduco un estratto interessante (in corsivo ciò che scrive la Hamilton, in tondo la risposta di Macalope):

Attualmente, la fetta più grande dei profitti di Apple proviene dalle vendite dirette, che siano MacBook, iTunes [Store] o iPhone. E il sistema di pagamento per giochi, suonerie e video per cellulari viene da tempo utilizzato da altri fornitori di tecnologia come Verizon e Research In Motion, e persino da app store di terze parti come Handango. “È un business model storico”, fa notare Kevin Burden di ABI Research.

Ciò avviene probabilmente perché Apple è soprattutto un’azienda che vende prodotti e non servizi. Alla Hamilton inoltre sfugge il fatto che qui entrano in gioco svariati altri business model. Google ‘regala’ le proprie applicazioni agli utenti finali e i suoi profitti derivano dagli annunci e dalla vendita delle proprie soluzioni back-end ad altre compagnie. Altri produttori offrono gratuitamente i propri programmi perché inseriscono annunci pubblicitari nei software stessi.

I consumatori, però, hanno voglia di pagare, a causa del prestigio del marchio Apple.

Hmm, no. I consumatori hanno voglia di pagare perché i prodotti di Apple valgono qualcosa, hanno una certa qualità.

Se Apple dovesse decidere di offrire gratuitamente tutte le applicazioni per iPhone, sarebbe un cambiamento radicale rispetto al suo solito modo di fare business. Passando a un modello supportato dalla pubblicità, Apple dovrebbe entrare in partnership con un’azienda che ha già a disposizione un vasto repertorio di annunci interattivi. Google sarebbe la scelta più ovvia, ma il gigante della ricerca sul Web ha già il ruolo di maggior concorrente di Apple nel mercato della telefonia mobile con l’introduzione dei dispositivi Android quest’autunno. Una tale alleanza sarebbe un tantino scomoda.

Ma che gliene importerebbe a Google? Tutto quel che Google vuol fare è sbatterti un annuncio pubblicitario davanti agli occhi. È questa la ragione principale che sta dietro ad Android. È per questo che lo ‘regaleranno’. Se Apple decidesse di scegliere la strada della pubblicità, Google sarebbe ben lieta di metterli sull’iPhone. Dopotutto, gli attuali utenti di iPhone si contano nell’ordine dei milioni, mentre il numero degli utenti Android è nell’ordine… degli zeri.

Agire in questo modo, tuttavia, non ha molto senso per Apple: chi compra i prodotti Apple solitamente preferisce un’esperienza utente pulita ed elegante, non compromessa dal dover, che so, inseguire un coniglietto animato (come quello del Larchmont Outlet Mall!) per tutto lo schermo prima di poter utilizzare un’applicazione. 

* * * * * *

3.

Per finire, l’esperienza allucinante di Marko Karppinen. Apple ha divulgato la password del suo Apple ID (e quindi di tutti i servizi accessibili dal suo account .Mac) solo perché qualcuno ne ha fatto richiesta:

L’altra mattina ho cercato di effettuare il login sul sito della Apple Developer Connection e ho scoperto che la mia password era stata cambiata e che l’indirizzo email associato al mio account era diventato un indirizzo yahoo.com non mio. Per fortuna la mia “domanda di sicurezza” era ancora quella, e così ho potuto resettare la password e tornare in possesso del mio account.

Osservando gli ultimi messaggi email apparsi nella mia casella .Mac, il “dirottamento” è riuscito grazie a questo semplice messaggio di una riga:

È dimenticato la mia password mac, avete darmi la password su nuova email marko.[xxxxx]@yahoo.com [Nota: il messaggio originale è sgrammaticato e ho cercato di renderne l’effetto in italiano]

Alla cui richiesta Apple non ha fatto altro che rispondere “Sissignore!” e divulgando così le mie informazioni personali. Questa è l’email che ho inviato ad Apple:

Cara ADC,

Avete resettato la mia password basandovi su una richiesta proveniente da qualcuno che non ero io. Invece di controllare se la persona che richiedeva tali informazioni fosse davvero il sottoscritto, facendo un confronto delle informazioni dei profili personali, avete permesso a terzi di accedere al mio Apple ID senza alcuna ragione plausibile.

Oggi ho cercato di effettuare il login e ho scoperto che la mia password era stata cambiata e che l’indirizzo email associato al mio account era diventato “marko.[xxxxxxx]@yahoo.com”.

Apparentemente, grazie a un messaggio email lungo una sola riga, avete permesso a un’altra persona di avere accesso:

  • Alle mie informazioni personali
  • Alla mia posta privata
  • A tutti i file conservati sul mio iDisk
  • A tutto quel che ho sincronizzato con .Mac (la mia Rubrica Indirizzi, i Bookmark, gli elementi di Accesso Portachiavi, ecc.)
  • Alle informazioni della mia carta di credito conservate nel mio profilo Apple Store
  • Al mio account iTunes Store
  • Alla mia ADC Premier Membership, compresa la chiave dei seed software e di altre risorse
  • Al Program Portal dell’iPhone Developer Program, compresi i dettagli sul nostro team di sviluppo
  •  

    Francamente sono fuori di me dalla rabbia per quanto è accaduto. Non vi è proprio passato per l’anticamera del cervello che il titolare dell’indirizzo “marko.[xxxxxxx]@yahoo.com” non fossi io? Che so, perché magari i nomi sono differenti?

    Avete la benché minima idea della mole di lavoro che mi tocca affrontare per rendere nuovamente sicure le informazioni da voi compromesse? Come pensate di ristabilire la volontà da parte mia, o di chiunque, di affidare ai vostri sistemi qualsiasi informazione sensibile in futuro?

    Cordiali saluti,
    Marko Karppinen

    Aggiornamento: qualche ora dopo aver pubblicato quanto sopra, un team leader dell’organizzazione di supporto della Apple Developer Connection europea si è messo in contatto con me, si è scusato dell’immenso pasticcio, e mi ha assicurato che normalmente non agiscono in questa maniera. Ha promesso di scoprire se Apple può determinare, basandosi sui log a sua disposizione, quando e come è stato utilizzato il mio Apple ID dal momento in cui è avvenuto il primo reset della password al momento in cui ho scoperto il ‘dirottamento’ 12 ore dopo. […] 

    Che dire, no comment.

    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.