Interfaccia utente: the Microsoft way

Mele e appunti

L’universo è sicuramente dotato di ironia, perché poco dopo essermi impegnato nella realizzazione del lungo articolo di qualche giorno fa sulle spinte innovative e conservative dell’interfaccia utente, mi capita sotto gli occhi questa schermata che dovrebbe essere di una versione beta di Microsoft Office 2010.

D’accordo, non è una versione definitiva.

D’accordo, è una schermata fissa, e non è del tutto indicatrice della vera esperienza utente.

Sta di fatto che non ho parole. Steven Frank sì, ed esprime bene lo stesso tipo di reazione che mi ha assalito. Trovo assolutamente corretto e condivisibile questo passaggio:

Credo che questo [pasticcio di interfaccia] derivi da una cultura aziendale incapace di dire no a qualunque proposta. Office ha un triliardo di funzioni, e senza dubbio la decisione di aggiungerne altre migliaia è spinta da ragioni di marketing, per giustificare l’upgrade alla versione 2010. Ognuno ha un proprio modo di utilizzare Office, e [Microsoft] sta letteralmente cercando di fornire ogni layout o personalizzazione possibile per accontentare ogni utente della storia. Ha paura che qualcuno smetta di usare Office (come se avesse scelta) perché Microsoft non è riuscita a posizionare i tre pulsanti di cancellazione in quella certa maniera. È pura follia. 

Se insegnassi design e usabilità prenderei quella schermata come esempio di ciò che non va fatto quando si progetta un’interfaccia utente.

Tweetie per Mac

Mele e appunti

Ora che mi sento più a mio agio in Twitter e che utilizzo il servizio con più costanza, stavo cercando una configurazione più omogenea per pubblicare i miei tweet. Un mese fa scrivevo in questa sede:

Dal punto di vista ‘tecnico’, dopo aver provato vari client Twitter per Mac OS X, per ora rimango con questa configurazione: Twitterrific in lettura sul monitor del Cube, che si trova alla sinistra del mio monitor principale, e l’interfaccia Web di Twitter in scrittura. I client Twitter provati (Twitterrific compreso) sono tutti interessanti dal punto di vista dell’interfaccia, e hanno funzioni anche carine, ma trovo che a tutti, curiosamente, manca un dettaglio che per me è molto pratico per la scrittura dei tweet: un campo di testo con caratteri più grandi, e soprattutto in cima alla serie di tweet dei contatti che seguo. Proprio com’è fatta l’interfaccia Web di Twitter. Negli altri client desktop (almeno per Mac OS X), la casella di testo per scrivere i messaggi è in basso, è piuttosto piccola e il font ha la stessa dimensione di quello usato per visualizzare i messaggi altrui. (Penso soprattutto a Twitterrific, che è l’esempio che ho davanti). Con monitor piuttosto grandi, e con l’interfaccia del client che arriva poco sopra del Dock, scrivere in quella casella è scomodo […]

Quando si è sparsa la voce che Loren Brichter, creatore di un ottimo client Twitter per iPhone chiamato Tweetie stava lavorando a una versione di Tweetie per Mac, ho iniziato a tenermi informato con interesse. Quando, pochi giorni prima del rilascio ufficiale dell’applicazione (lo scorso 20 aprile), Brichter aveva pubblicato sul suo sito un video dimostrativo di Tweetie per Mac, ero certo che sarebbe diventato subito il mio client preferito. Mio e di tantissime altre persone. Ancora non si sapeva se sarebbe stato un freeware o un software a pagamento, ma quel video era stato per me così convincente che non mi importava.

E infatti, appena scaricato e installato, Tweetie per Mac ha mantenuto le promesse ed è l’unico client che uso sul mio PowerBook principale per scrivere messaggi. Dopo alcune ore di utilizzo non avevo dubbi e ho cancellato tutti gli altri client provati nelle ultime settimane, e ora Tweetie ha un posto fisso nel mio Dock. (Continuo a tenere Twitterrific sul Cube a fianco, perché va benone in lettura).

Avrei voluto scrivere le mie impressioni qualche giorno fa, ma ho preferito lasciar sedimentare l’entusiasmo, esplorare bene l’applicazione, che nel frattempo in poco più di una settimana è già alla versione 1.0.2, e prender nota degli aspetti positivi e dei particolari che a mio avviso dovrebbero essere rivisti o aggiustati. Potrebbe comunque essermi sfuggito qualcosa, e ogni vostro contributo in proposito è più che ben accetto.

Cosa mi piace

Tweetie è un’applicazione visivamente molto gradevole, e mi piace molto il lavoro che è stato fatto con l’interfaccia. La scelta dei colori, la disposizione delle informazioni, le icone, le animazioni e gli effetti di transizione. E in generale tutta una serie di piccoli tocchi che rendono l’interfaccia di Tweetie piuttosto originale e che le permettono di distinguersi da tutti gli altri client Twitter e da altri programmi per Mac OS X.

La finestra principale di Twitter. Mi piace la scelta di differenziare i propri tweet da quelli di chi seguiamo, disponendo la nostra icona e il relativo 'fumetto' in orientamento speculare rispetto agli altri tweet.

La finestra principale di Twitter. Mi piace la scelta di differenziare i propri tweet da quelli di chi seguiamo, disponendo la nostra icona e il relativo ‘fumetto’ in orientamento speculare rispetto agli altri tweet.

Nella figura qui sopra è visibile la finestra principale di Tweetie, con i tweet dei contatti che seguiamo. In alto l’applicazione indica dove ci troviamo (“Timeline”). Nella barra laterale sinistra è presente una serie di icone — dall’alto verso il basso esse sono: l’immagine dell’account Twitter attivo al momento, l’elenco dei messaggi (nostri e di chi seguiamo), l’elenco delle risposte o delle menzioni, l’elenco dei messaggi diretti (privati), l’icona ‘spotlight’ per effettuare ricerche, e infine (nel mio caso) l’immagine di un secondo account Twitter, che è ‘spenta’ perché non attivo al momento. Come potete vedere, l’aspetto generale di Tweetie lo fa sembrare un programma pensato più per iPhone che per la scrivania del Mac. Un indizio rivelatore, a parte la foggia e le dimensioni delle icone, è la barra di scorrimento, nonché l’icona in basso a sinistra per scrivere un nuovo messaggio, identica a quella di MobileMail per comporre una nuova email.

Utilizzare Tweetie, con un’interfaccia così, è semplice e immediato. Un particolare che mi ha favorevolmente colpito sin dall’inizio è la velocità delle transizioni e della navigazione. Quando Tweetie non era ancora disponibile e guardavo il video dimostrativo, pensavo: ‘Certo, è così fluido perché è su un Mac con processore Intel Core 2 Duo. Voglio vedere sul mio povero G4’. Beh, sul povero G4 con 32 MB di memoria video, Tweetie è ugualmente scattante e fluido — un altro punto a favore. E non solo è veloce nel passare da una schermata all’altra, ma anche nel dialogo con Twitter: se stiamo seguendo qualcuno e ci incuriosisce conoscere la persona a cui il nostro contatto sta rispondendo o fa riferimento, basta un clic sul @nome-utente ed è subito visibile il suo elenco di messaggi.

tweetie3.png

E non solo: in alto appare una fila orizzontale di icone che permettono di navigare all’interno del suo profilo (vedi figura). L’icona del fumetto mostra tutti i suoi tweet; icona della chiocciola (@) mostra tutte le risposte e le menzioni dirette a questa persona; l’icona della stella mostra i tweet che la persona ha contrassegnato come preferiti; e infine l’icona con la ‘i’ mostra le informazioni relative alla persona: quanti tweet ha scritto in totale, quanti sono i suoi preferiti, quanti utenti la stanno seguendo e quanti utenti segue, e poi luogo di residenza, indirizzo dell’eventuale sito Web e il mini-profilo di massimo 160 caratteri.

Tweetie è assai rapido nell’accedere a tutte queste informazioni: più di altri client Twitter e a volte più della stessa interfaccia Web di Twitter. E mi piace molto il fatto che queste informazioni siano visualizzate tutte all’interno di Tweetie. Una cosa estremamente irritante di Twitterrific è proprio il suo appoggiarsi all’esterno, rimandando al browser ogni genere di informazione che non sia lo stream di messaggi visualizzati nella finestra principale. Lo trovo un andirivieni fra applicazioni inutile e un po’ caotico. Con Tweetie non è necessario uscire dal programma, a parte ovviamente quando si fa clic su un link a un determinato sito Web.

Scrivere nuovi tweet — I vari client Twitter provati in precedenza, come scrivevo un mese fa, avevano tutti un dettaglio che non mi piaceva: il campo di testo dove scrivere i messaggi era troppo sacrificato, e i caratteri troppo piccoli. Non riuscivo a capire perché nessun client seguisse l’ottimo esempio dell’interfaccia Web di Twitter: un riquadro grande, con caratteri ben visibili, e soprattutto in cima ai tweet, non in basso. Tweetie aggira brillantemente il problema: i nuovi messaggi si scrivono in una finestra a parte. Inizialmente questa scelta non mi convinceva, ma presto mi sono reso conto che è la più pratica. Si fa clic sull’icona in basso a sinistra — o, molto più comodamente, si usa la scorciatoia da tastiera ⌘-N — e appare la finestrella con un’animazione ‘liquida’. La finestra si può spostare ovunque sullo schermo, e la posizione viene registrata e mantenuta coerentemente. Per chi usa monitor di dimensioni medio-grandi è ottimo poter scrivere in una finestra che si apre all’altezza degli occhi, e non in uno spazio in fondo all’applicazione e quasi sempre a ridosso del Dock (come in Twitterrific e in altri client). In più la grandezza dei font è variabile nelle preferenze, da un minimo di 10 a un massimo di 14 punti. Per i miei occhi 12 punti sono perfetti, 14 è grasso che cola. Altri client sembrano preferire 10–11 punti… un po’ piccoli su uno schermo da 20 pollici.

(Fra l’altro questo modo di scrivere tweet, l’aprire la finestrella, scrivere il messaggio e vedere il messaggio sparire nell’etere e poi apparire nello stream di Twitter mi riporta indietro ai tempi della scuola, quando si usava comunicare con i compagni durante le lezioni attraverso brevi messaggi scritti su pezzetti di carta e scambiati furtivamente per evitare di essere beccati dal professore).

Accorciare i link e aggiungere immagini — Per queste due funzioni Tweetie lavora sull’integrazione. Nelle preferenze è possibile scegliere fra 5 servizi di ‘accorciamento link’ (bit.ly, TinyURL, is.gd, tr.im e DiggBar), e 4 servizi di gestione foto per chi usa Twitter (Twitpic, Twitgoo, Posterous e yFrog). Quando si inserisce un link lungo in un nuovo messaggio e si sceglie il comando “Shorten URLs” dal menu a discesa attivabile facendo clic sull’icona dell’ingranaggio, il link viene automaticamente accorciato, senza bisogno di usare il browser, andare al sito del servizio, incollare il link da accorciare, e copiare il link accorciato nel proprio messaggio. Questo è molto comodo e permette di risparmiare tempo e passaggi.

Sempre in tema di link accorciati, trovo ottima la funzione di anteprima di Tweetie: quando si fa clic su un link accorciato, Tweetie apre una finestra di dialogo in cui viene visualizzato il link completo, così che si abbia già una idea più precisa di che cosa si aprirà nel browser.

Altra cosa molto apprezzata è la gestione di più account. Avere più account in Twitter può sembrare sciocco e da malati, ma non è infrequente trovare casi di utenti che hanno in attivo un account personale e uno rappresentativo della loro società, o della rivista a cui collaborano, o dell’applicazione che sviluppano (qui l’account viene impiegato come flusso di feed con informazioni, novità e avvisi specifici relativi all’applicazione), ecc. Passare da un account all’altro in Tweetie è questione di un clic sull’icona corrispondente. Se abbiamo già aperto la finestra per scrivere un nuovo messaggio e ci rendiamo conto di essere nell’account sbagliato, basta scegliere l’altro account dal menu a discesa presente nella finestra stessa.

Dettagli da rivedere

Scorciatoie e deviazioni — Tweetie, a mio avviso, ha un problema con le scorciatoie da tastiera per gestire la navigazione all’interno dell’interfaccia. Alcune delle scelte di default sono discutibili: perché per effettuare lo scorrimento della lista dei tweet verso il basso e verso l’alto non posso usare i tasti con le frecce o i tasti ‘Pagina Su’ e ‘Pagina Giù’? Tweetie costringe a servirsi della barra spaziatrice per scorrere verso il basso e, a complicare le cose, ⇧-Barra spaziatrice per scorrere verso l’alto. Non è difficilissimo abituarsi, ma non sono scorciatoie ‘naturali’. Spesso e volentieri viene spontaneo usare i tasti ‘Pagina Su’ e ‘Pagina Giù’… e non succede nulla.

Altre scorciatoie sono molto simili fra loro e quindi facilmente confondibili. Per scrivere una risposta viene spontaneo fare ⌘-R. E per ricaricare (Refresh) i tweet e aggiornare il flusso? ⇧-⌘-R naturalmente. E per ri-pubblicare (Repost — o meglio Retweet, nel gergo di Twitter) un messaggio altrui? ⌥-⌘-R. Troppo simili.

Poi si possono trovare piccole incongruenze: se voglio marcare un messaggio altrui come preferito, lo seleziono e premo F. Compare una stellina, il messaggio è tra i preferiti. Per togliere quello stesso messaggio dai preferiti viene spontaneo premere ancora F, perché — come in altre applicazioni — quel tasto viene avvertito come un interruttore (toggle). Ci si aspetta che funzioni e che la stellina scompaia, invece non succede niente.

A mio avviso, quindi, le scorciatoie da tastiera più importanti dovrebbero essere personalizzabili.

Non tutto è trasparente — Trovo molto utile il sistema di indicatori in Tweetie. Per segnalare la presenza di nuovi tweet, nuove risposte/menzioni, nuovi messaggi diretti, Tweetie appone un pallino azzurro in alto a destra sulle rispettive icone nella barra laterale. È comodissimo, specie quando si avvia l’applicazione: vediamo subito se ci sono nuovi messaggi che ci riguardano e in un clic li visualizziamo. Un altro indicatore, anche se più rudimentale, dell’arrivo di nuovi tweet è l’icona che Tweetie aggiunge per default alla barra dei menu: nera (spenta) quando tutti i messaggi sono stati letti, blu (accesa) quando ve ne sono di nuovi. Solo che, anche quando si sono letti tutti i messaggi nuovi, gli indicatori rimangono presenti (i pallini sulle icone e lo stato ‘blu’ dell’icona nella barra dei menu) e non si capisce bene che cosa bisogna fare affinché segnalino correttamente l’avvenuta lettura di tutti i tweet. Io ho notato che a volte basta selezionare uno degli ultimi tweet e salire di uno in uno fino all’ultimo più recente; altre volte è necessario scorrere prima verso il basso e poi risalire di uno in uno come prima.

Inoltre, malgrado sia possibile attivare un’opzione nelle preferenze che renda in una sfumatura di grigio più chiara i tweet già letti, trovo grossolana l’assenza di un pratico ‘Segnala tutti i tweet come letti’ (⌘-K in Twitterrific).

Interfaccia e usabilità — Sotto questo aspetto, Tweetie è promosso, ma non a pieni voti. Qua e là si notano particolari ancora raffinabili, come l’icona in basso a sinistra per scrivere un nuovo tweet: è piccola, fuori luogo, non sembra un pulsante da premere (pare più un’icona che visualizza uno stato) e si trova in una posizione non prominente. Dà molto l’idea di essere un’aggiunta dell’ultimo minuto (vedi figura). Inoltre, quando Tweetie è in background, la sua finestra non cambia sfumatura per segnalare lo stato ‘non attivo’, ma conserva la stessa intensità e colorazione dello stato attivo. Questo non è conforme alle linee guida di Mac OS X.

tweetie2.png

Ci sono poi altri dettagli che a mio parere dovrebbero essere personalizzabili e invece, al momento, sono prestabiliti e immutabili. Tweetie aggiorna automaticamente il flusso dei tweet, mentre sarebbe preferibile un’opzione (presente in altri client) per specificare l’intervallo di refresh. Delle scorciatoie da tastiera ho già detto. L’icona che appare nella barra dei menu non mi dispiace esteticamente e non mi disturba più di tanto, ma dovrebbe esservi un’opzione per disattivarla e utilizzare l’icona del Dock come punto di riferimento per avere rapide informazioni (se ci sono nuovi tweet, numero di tweet non letti, ecc. In questo Twitterrific rimane insuperato). Anche l’amico Daniele ha scritto una recensione di Tweetie, ed è stato molto più critico e pignolo di me nell’evidenziare quel che a suo parere sono gli elementi negativi. Cito di seguito i punti in cui mi trovo d’accordo con lui:

  • l’icona del dock non visualizza il numero di tweet non letti
  • non è possibile usarne solo una (dock o menubar)
  • la finestra di inserimento separato ha un senso per chi non si vuole distrarre, ma allora non si capisce perché se Tweetie è nascosto la scorciatoia per creare un nuovo tweet porta in primo piano anche la finestra principale
  • il sistema per i retweet (RT) utilizza [il formato] via username anziché il prefisso RT
  • le ricerche non possono essere salvate
  • la possibilità di staccare la finestra di ricerca in una nuova finestra è comoda ma può produrre un sacco di sovraffollamento se utilizzato più volte per monitorare diverse ricerche
  • se non si utilizzano le scorciatoie da tastiera, cosa che comunque andrebbe fatta, a volte si ha l’impressione di dover cliccare troppe volte per raggiungere un’azione
  • il pulsante verde della finestra principale [che secondo le linee guida di Mac OS X serve per ridimensionare la finestra] non fa assolutamente nulla
  •  

    Detto questo, per quanto mi riguarda gli aspetti positivi superano senza dubbio i negativi, e l’esperienza d’uso di Tweetie è decisamente più fluida e appagante di altri client Twitter per Mac. I difetti sono difetti di gioventù. Per essere una versione 1.0.2 non c’è da lamentarsi e direi che ha già un buon livello di maturità. Lo sviluppatore pare molto attento al feedback e vale la pena scrivergli. Su Twitter potete seguire i suoi account @atebits e @Tweetie.

    Tweetie è utilizzabile in versione gratuita con annunci pubblicitari (pochi e mai invadenti), oppure è possibile acquistarlo in versione senza annunci per 19,95 dollari (prezzo promozionale fino al 4 maggio: 14,95 dollari).

    The point-and-shoot computer

    Tech Life

    Thinking about it, these new subcomputers called ‘netbooks’ share a lot with digital point-and-shoot cameras. I was taking a look at the latter, the other day. Digital compact cameras all have a small footprint so that they can easily be pocketed and carried around. They’re lighter and cheaper (some much cheaper) than their DSLR counterparts. They have fewer or simplified features, smaller sensors, smaller collapsible lenses. They usually have a series of usability tradeoffs, too. Controls are cramped, tinier, at times more difficult to operate for those with big hands and fingers. But all in all they can take decent photos and generally make for a nice second camera alongside a bigger, more sophisticated DSLR. Some people will also argue that these compact digital cameras are even better than their bulkier brethren for certain uses: they’re unobtrusive, quieter, ideal for quick snaps and candid shots, and for documenting parties and outings with friends.

    So when someone asks whether a netbook is a ‘real computer’, I think about digital point-and-shoot cameras (heh, even those film disposable cameras that are still available in many stores) and I raise a similar question: are they ‘real cameras’? Yes, they are cameras. They are pretty, handy little cameras taking photos and stuff like the big ones. And netbooks, they are handy little computers that have (little) screens and (little) keyboards and (little) trackpads, and they can do email and web browsing and stuff like the big ones.

    However, when you use a digital point-and-shoot camera, you’re not doing photography — you’re taking snapshots. Your concern is not taking good photographs. Your concern is being practical. Technically speaking, the result is often like the point-and-shoot cameras themselves: smaller, of lesser quality, cheaper. Or, if you love these little cameras, you’ll talk about the result as being ‘not bad’, or ‘good enough’. Bigger, more sophisticated and more expensive digital SLRs have less usability tradeoffs, and offer more refined and advanced sets of features which usually let the photographer focus on his/her work, not on just being practical (hopefully). Now apply the same logic to netbooks and full-fledged notebooks.

    Interfaccia utente: spinte innovative e forze conservative

    Mele e appunti

    Steven Frank di Panic ha recentemente pubblicato una riflessione interessante sul suo blog, sull’attuale situazione dell’interfaccia utente in campo informatico. È da molto che siamo fermi alla metafora della ‘scrivania’. Quale può essere una possibile evoluzione o trasformazione di questo concetto ormai ‘datato’?

    Steven inizia facendo una panoramica delle interfacce utente finora incontrate:

    Nella breve storia dei computer da scrivania, in pratica, sono esistite due metafore predominanti per quanto riguarda l’interfaccia utente:

    • Tastiera + linea di comando
    • Mouse + scrivania

    Una terza metafora, la penna, non ha mai preso realmente piede.

    Da una parte si è avuto il Tablet PC, che altro non è che la seconda metafora, ma con una penna al posto del mouse. Dall’altra abbiamo avuto il Newton OS e il Palm OS originario, che sono state le due uniche piattaforme che hanno davvero tenuto conto di come gli esseri umani impugnano e utilizzano una penna. Ma i due sistemi affrontarono la questione in modi diversi. 

    Secondo Frank, il motivo primario per cui l’utilizzo della penna non ha mai ingranato è dovuto alla scomodità dell’inserimento di testo. Il riconoscimento della scrittura — scrive — anche se è stato rapidamente migliorato nel corso degli anni, è sempre soggetto a errori. E le tastiere software virtuali sono tediose.

    Poi arriviamo a una quarta metafora piuttosto recente: l’interazione diretta fra il dito e lo schermo, il multi-touch, introdotta su scala relativamente ampia da iPhone e iPod touch. Frank la descrive come probabilmente la novità più rilevante in materia di interfaccia utente a entrare nel mercato di massa negli ultimi tempi. Su questo metodo di interazione, Frank continua:

    Un singolo tocco è sostanzialmente un mouse senza l’astrazione. Invece di impiegare un dispositivo che sposta un dito virtuale su uno schermo (il puntatore a freccia), si utilizza il dito direttamente. Con il mouse, se ne va anche la precisione. Secondo le stime di Apple, un tocco con la punta del dito copre un’area attiva di circa 40x40 pixel sullo schermo di iPhone, contro 1x1 pixel di un puntatore del mouse e (suppongo) circa 8x8 pixel di un tocco impreciso con una penna. Per cui è preferibile realizzare software adatto a questo tipo di input che tenga in conto della differente precisione. 

    Dal singolo tocco al multi-tocco il passo è breve — o quasi:

    Quando passiamo dal singolo tocco al multi-touch, entriamo nuovamente nel mondo dei gesti. Se nessuno ci insegna determinate gestualità [di un’interfaccia], può essere molto difficile scoprirle; ma una volta apprese la loro esecuzione è estremamente gratificante.

    Ci vogliono due secondi per imparare il pinch-to-zoom [ossia il ‘pizzicare’ un testo o immagine per ingrandire/rimpicciolire], ma se prestassimo un iPhone a una persona che non ne ha mai visto uno e le dicessimo “ingrandisci una porzione di questa pagina Web”, non saprebbe assolutamente come fare. Magari nemmeno si sarebbe immaginata che era possibile fare zoom se non glielo avessimo detto.

    Però, una volta insegnata la gestualità, le sembrerà naturale, ed è difficile concepire un sistema più efficiente per fare zoom con le mani. […] Viene offerta una funzionalità che non necessita di spazio sullo schermo dedicato ai controlli, e un’esperienza tattile che deve essere piuttosto gratificante a quel che suppongo sia un livello molto basso del sistema nervoso.

    Il vantaggio del pinch-to-zoom rispetto a metodi di ingrandimento/riduzione precedenti è così immediatamente ovvio che si giustifica la curva di apprendimento. Che la curva di apprendimento sia ridicola è un altro punto a favore. Trovo affascinante che una parte enorme dell’apprendimento dell’usabilità di iPhone venga svolta dagli annunci pubblicitari ancor prima della vendita. Sono, al tempo stesso, marketing e istruzione. 

    E qui arriviamo a un nodo cruciale per quanto riguarda il discorso dell’innovazione nell’ambito dell’interfaccia utente:

    Pertanto, se si vuole provare a convincere il pubblico a cambiare il modo in cui svolge un certo compito, è meglio che questo porti con sé un vantaggio immediatamente ovvio e che non serva più di una manciata di secondi per spiegare come funziona. 

    Il problema che pone la metafora della scrivania per chi vuole innovare, è duplice: da un lato ci sono i metodi di input, dall’altro l’architettura dei dati.

    Problema 1: Ci dovremo portar dietro la tastiera (un retaggio della macchina da scrivere!) per sempre?

    Questo si chiede Steven Frank. E io rispondo: per sempre forse no, ma sicuramente ancora per molto. Che piaccia o no, la tastiera è a tutt’oggi il sistema più veloce per inserire testo in una qualsivoglia macchina. Tempo fa, nella lista NewtonTalk vi fu un’interessante discussione fra chi sosteneva che è più veloce e soprattutto naturale scrivere con una penna, e chi affermava invece che, per quanto veloce sia questo tipo di inserimento del testo, la scrittura mediante una tastiera è più rapida e (considerando lo stato attuale del riconoscimento della scrittura) meno soggetta a errori. Tendo a essere d’accordo con questa seconda linea di pensiero.

    Il fatto è che le due uniche alternative all’inserimento del testo in un computer sono il riconoscimento della scrittura e il riconoscimento vocale. Non c’è granché bisogno che faccia esempi concreti per sostenere che, purtroppo, la precisione, l’affidabilità e la velocità di queste due alternative sono oggi insufficienti per entrare in competizione con la scrittura mediante tastiera. Il nodo della questione è proprio il riconoscimento: in entrambi i casi entrano in gioco parecchie variabili che interferiscono con la comunicazione uomo-macchina. Nel caso della scrittura abbiamo l’inclinazione, la velocità, il tipo di calligrafia (chi separa le lettere, chi scrive in un corsivo fluido, ecc.), la distinzione di maiuscole e minuscole, i simboli, i glifi, e in generale il grande processo di disambiguazione della grafia di ognuno per fornire una traduzione e visualizzazione precisa del testo scritto a penna (per non parlare dei gesti aggiuntivi per ordinare la formattazione definitiva del testo: come dico al computer che voglio questa frase scritta in corsivo o in grassetto o sottolineata?). Nel caso della voce abbiamo le interferenze audio, il problema di configurare un sistema di input (microfono) particolarmente sensibile e in grado di sintonizzarsi perfettamente sulla ‘voce del padrone’, che può essere riconosciuta a prescindere da altezza, intensità, velocità di scansione; ma è solo l’inizio — pensate solo a uscire di casa e a usare in movimento un computer portatile il cui unico sistema per inserire testo è parlargli. Pensate se tutti avessero computer del genere — sarebbe un caos acustico inimmaginabile.

    La tastiera rimane il sistema più pratico, efficiente e preciso per l’inserimento di testo. Il fatto che sia un sistema di ‘vecchia concezione’ e che possa ormai odorare di cantina, per così dire, non lo rende necessariamente il sistema peggiore o un metodo obsoleto. Per alcuni può sembrare vincolante, specie per quanto riguarda la progettazione di un computer, destinato a portarsi appresso questa appendice (nel caso di un desktop), o destinato alla forma ‘a libro’ con uno schermo piatto da una parte e una tastiera dall’altra (nel caso di un portatile). Ma se consideriamo le problematiche di interazione nelle altre due alternative viste sopra, è facile rendersi conto che — a tutt’oggi — sistemi di riconoscimento di scrittura e di voce sono ancor più vincolanti della tastiera.

    Problema 2: Le antiche strutture gerarchiche

    Parliamo ovviamente di file, riuniti in cataloghi (directory), organizzati gerarchicamente. Ancora Frank:

    Tutti i principali sistemi operativi di oggi continuano a impiegare lo stesso sistema gerarchico dei file che stiamo utilizzando praticamente da sempre. È un concetto naturale per la mente umana? Non proprio. Ma è ‘artificialmente naturale’ in virtù del fatto che milioni di persone ne hanno grande familiarità. Se si ha un metodo innaturale per far qualcosa, e tale metodo viene accidentalmente compreso e subito interiorizzato da un’intera generazione, poi qualunque nuovo metodo, innovativo e ‘naturale’, di fare quelle stesse cose potrebbe essere avvertito come innaturale per il solo fatto di essere differente. 

    Frank poi fa alcuni esempi di sistemi operativi che hanno cercato di proporre innovazioni strutturali, guarda caso di provenienza Apple. Il Newton OS ha un approccio estremamente oggettuale. I dati vengono inseriti in ‘contenitori’ (soup) accessibili da tutto il sistema. Informazioni quali eventi in calendario, schede dei contatti dell’agenda, cose da fare (to-do tasks), impostazioni e configurazioni aggiunte, ecc., vengono archiviate e rese disponibili a tutte le applicazioni in grado di attingere a esse e manipolarle, senza bisogno che intervenga per forza l’applicazione che le ha generate.

    Altro esempio: l’utilizzo, nel vecchio Mac OS, dei resource fork e data fork come componenti essenziali di ogni elemento. Un sistema più intelligente e avanzato della dipendenza dei file dalle loro estensioni. Grazie al resource fork un elemento era immediatamente riconoscibile e apribile da una certa applicazione o da altra compatibile. Non era necessario mettere .doc o .psd per identificare un file di Word o Photoshop. Come non era necessario usare .exe o .app per distinguere fra programmi eseguibili e documenti.

    Come giustamente fa notare Steven Frank, però, il tallone di Achille di questi due approcci era la comunicazione con il mondo esterno, necessariamente mediata da componenti atte a ‘tradurre’ e ‘convertire’ per garantire una certa compatibilità bidirezionale, coi risultati alterni che tutti più o meno conosciamo. Alla lunga — nota Frank — l’interoperabilità ha vinto sull’innovazione.

    Conservazione e innovazione

    Il nodo della questione, qui, è il riuscire a conciliare queste due forze. Da un punto di vista di interfaccia uomo-macchina, se una certa idea vuole innovare e attecchire deve fare i conti con i dati già esistenti che abbiamo accumulato finora. Una nuova metafora che superi l’immagine ormai abusata della ‘scrivania’ su cui disporre ‘cartelle’ di ‘file’ deve da un lato essere semplice, convincente e utilizzabile con una curva d’apprendimento bassa o accettabile (ovvero che valga la pena considerando sacrifici e benefici); dall’altro deve poter gestire senza passaggi, conversioni, traduzioni (senza quindi transizioni traumatiche per l’utente) i dati vecchi mentre continua a produrne e organizzarne di nuovi.

    Steven Frank osserva:

    Sembra un po’ fatalista, ma non riesco a pensare a un sistema per rinnovare l’intera metafora della scrivania che non comporti un immediato passaggio da parte di tutta l’utenza mondiale (cosa che non accadrà), o che diventi una ‘isola di informazioni’ come lo furono il Newton OS e il Mac OS classico.

    Vorrei tanto essere smentito, ma l’unico metodo realistico per andare avanti pare essere quello di costruire sopra l’infrastruttura esistente, con tutta l’immondizia accumulatasi nel tempo, e procedere per astrazioni successive, tenendo le dita incrociate sperando che la Legge di Moore sia sostenibile ancora per qualche decennio. Le astrazioni sono difficili da digerire sotto l’aspetto delle prestazioni, ma attenuano i problemi di migrazione da un sistema all’altro per una specie — gli esseri umani — che in genere rifugge i cambiamenti.

    Quest’ottica, se notate, rappresenta l’approccio di Microsoft al proprio sistema operativo Windows, che a ogni nuova iterazione si faceva più colossale ed elefantiaco proprio perché costruito sull’infrastruttura esistente, con tutta l’immondizia accumulata versione dopo versione, allo scopo di mantenere una coerenza di facciata e una retrocompatibilità di sostanza. Apple ha scelto di procedere per transizioni e astrazioni. Vista con tutto il senno di poi, la migrazione fra l’ambiente Mac OS 9 e Mac OS X è stata portata avanti in maniera intelligente ed elegante, fornendo una rete di sicurezza rappresentata dall’Ambiente Classic, che poteva far funzionare vecchie applicazioni dentro il nuovo sistema, in attesa che comparissero sempre più applicazioni Mac OS X native e che venisse oliato e raffinato Mac OS X stesso. Questa migrazione è stata, se vogliamo, strutturalmente più dura e con un minor numero di compromessi rispetto a quella avvenuta in precedenza, con il passaggio dai processori Motorola 680x0 ai PowerPC, in cui la compatibilità con il passato era garantita da una capacità emulativa diretta, che rendeva quindi la transizione totalmente trasparente per l’utente.

    Sempre guardando Apple, possiamo notare le prime astrazioni comparire (come già accennato) nell’interfaccia utente di iPhone e (come dice anche Steven Frank) nelle tecnologie Spotlight e QuickLook in Mac OS X. Il percorso sembra essere quello di rendere l’antica struttura gerarchica dei file un qualcosa esistente all’interno della macchina, ma invisibile o quantomeno mascherato nel rapporto con l’utente. Su iPhone lo vediamo in azione di continuo: c’è, se vogliamo, una gerarchia di schermate dentro un’applicazione, ma la struttura generale appare all’utente come un unico piano orizzontale su cui organizzare gli elementi a piacere. Il piano è astratto, non è una scrivania di fogli e cartelle virtuali. Le icone di iPhone fluttuano su un fondo nero, su un non-fondo. In Mac OS X, Spotlight è un tentativo di rivisitare il concetto di ricerca: invece di doversi ricordare la posizione di un file all’interno di uno schema ad albero di cartelle (directory), l’utente esegue la ricerca in un campo di testo, e i risultati appaiono in un elenco che attinge, dietro le quinte, alle reali posizioni dei file, ovunque essi si trovino (sui dischi locali o sui dispositivi esterni collegati alla macchina). Le gerarchie vengono appiattite. Con QuickLook l’astrazione è data dalla possibilità di esaminare i contenuti di un elemento a prescindere dalla natura dell’elemento (file di testo, immagini, file audio, filmati, ecc.) e a prescindere dall’applicazione che lo ha creato. Steven Frank si chiede: Se un giorno verrà realizzata una controparte di QuickLook, un ‘QuickEdit’, avremo così completato il cerchio, ritornando alla premessa originaria di un software basato sui componenti, un software modulare come OpenDoc? E, aggiungo io, torneremo a un sistema operativo incentrato sui documenti invece che sulle applicazioni? Tutto sommato continua a non sembrarmi un’idea malvagia.

    Ovviamente la purezza di questo approccio astratto deve tenere in conto le aggiunte che gli sviluppatori di terze parti possono apportare al sistema. È molto bello e rilassante pensare al nuovo ambiente operativo come a un foglio bianco in cui iniziare qualsiasi progetto, ma come passare dall’attuale situazione “Devo realizzare un impaginato: apro Adobe InDesign CS4 e comincio a lavorare” (ovviamente con l’aiuto di altre applicazioni, come Illustrator e Photoshop) al nuovo scenario “Devo realizzare un impaginato: dico al sistema ‘Nuovo progetto di layout’ e si attivano gli strumenti di impaginazione intorno al documento vuoto”? A tutta prima immaginare una situazione capovolta, in cui sono i documenti ad avere un ‘volto’, e non le applicazioni che li creano (vedi una schermata e riconosci l’interfaccia di Illustrator, o di Aperture, o di Lightroom, o di Excel, ecc.) appare difficile e innaturale. È chiaro che in un sistema fondato su questa metafora, le applicazioni di una volta diventano plug-in, componenti che vanno a estendere le funzionalità del sistema ‘sparendovi dentro’, per così dire, in modo che all’esterno, nell’interazione con l’utente, tutto appaia omogeneo. Sotto questo aspetto, due esempi saltano subito all’occhio: Newton e iPhone. Sul Newton ogni software, che sia parte del sistema scritto da Apple o che sia prodotto da altri, va a integrarsi nel sistema operativo, tanto che certe applicazioni sono in realtà ‘servizi’ e ci si accorge della loro attivazione semplicemente perché aggiungono voci ai menu di sistema per la manipolazione dei dati. Su iPhone l’integrazione è più visuale che strutturale, ma l’effetto è analogo — un’idea di coesione con l’ambiente operativo (un esempio su tutti: la ricerca vocale dell’applicazione Google Mobile).

    Non dimentichiamo Internet

    Un altro aspetto imprescindibile di questo futuro sistema operativo è il nostro attuale stato di ‘online permanente’. Concludo lasciando la porta aperta, e la parola a Steven Frank:

    Oppure la nostra traiettoria è fissata verso le applicazioni Web? È impossibile ignorare la grande diffusione delle applicazioni Web, e già mantengono quella promessa di ‘funzionare dappertutto’ che non abbiamo ancora conseguito in maniera elegante con il software desktop. È la conclusione logica immaginare che i sistemi operativi siano destinati a divenire essenzialmente dei super-browser estremamente raffinati? In questo momento storico pare plausibile, in effetti, se non già un risultato inevitabile. Ma l’ultima volta che si è parlato di elaborazione e di informatica di rete abbiamo usato il termine thin client e non è che abbia avuto questo grande successo. Abbiamo esteso lo HTTP in direzioni nuove e ardite, ma anche l’applicazione Web più riccamente Ajax continua a essere priva di una certa reattività e coerenza che si incontrano frequentemente nei software desktop. Il problema sarà forse risolto da una maggiore ampiezza di banda e da un protocollo di trasporto ancor più raffinato?

    Riguardo all’ultima domanda che Frank si pone, continuo a nutrire forti dubbi sull’immediato. La fornitura di banda larga è ancora estremamente variegata a livello mondiale, nazionale, locale. E per quanto riguarda un più raffinato protocollo di trasporto occorre superare, fra le altre cose, gli attuali tempi biblici del processo di standardizzazione di, beh, qualsiasi cosa. Insomma, la strada è lunga e questa è solo un’infarinatura generale del panorama delle problematiche. Sia Steven Frank che io abbiamo certamente dimenticato di approfondire molti dettagli. Ma discuterci sopra è sempre stimolante, no?

    Un virus del 1986

    Mele e appunti

    In chiusura al mio post di ieri accennavo al fatto che la realizzazione di un virus per una determinata piattaforma non dipende (o dipende relativamente) dalla diffusione di tale piattaforma (in generale e su Internet). A titolo di curiosità pubblico qui ampi stralci di un articolo di Peter Ferrie (Symantec Security Response) apparso su Virus Bulletin di gennaio 2005, che parla di uno stealth virus ingegnoso e ben scritto, creato nel 1986 e che prendeva di mira… il Commodore 64. Il sito Virus Bulletin è un altro che consiglierei di mettere nei bookmark a chi interessa rimanere costantemente aggiornato in materia di malware.

    Per chiarezza: uno stealth virus è un virus in parte residente in memoria, che nasconde i cambiamenti che apporta a livello di sistema operativo, strutture di directory e dimensioni di file, facendo credere al programma che effettua la scansione che tutto stia procedendo normalmente. (Definizione presa da questa pagina).

    E ora l’articolo:

    Normalmente si dice che il primo stealth virus conosciuto che infettava file fosse Frodo, del 1989. E questo è vero, ma solo per quanto concerne la piattaforma IBM PC. La piattaforma Commodore 64 venne infettata tre anni prima da quel che probabilmente fu il primo vero stealth virus che infettasse file di sistema: C64/BHP.A (da non confonderlo con il boot-sector virus che colpiva gli Atari, anch’esso conosciuto con il nome di BHP).

    Tutte le descrizioni di BHP pubblicate a quel tempo erano imprecise; alcune di esse davano persino informazioni errate su come funzionava il processo di infezione. Il presente articolo mostrerà le reali operazioni di quel virus.

    Come per tutti i programmi per il Commodore 64, BHP iniziava con del codice scritto in Basic. Il codice era composto da un’unica riga, una chiamata di sistema (SYS) al codice assembler, dove risiedeva il resto del virus. A differenza di molti programmi, il codice del virus costruiva l’indirizzo da chiamare dinamicamente. È possibile che sia stato scritto da un programmatore molto attento, ma questa procedura si rivelò superflua perché l’indirizzo non cambiò nelle versioni successive della macchina.

    Una volta che il codice assembler otteneva il controllo, si inseriva nel blocco di memoria solitamente occupato dai dispositivi I/O [input/output] quando la ROM veniva allocata in banchi.

    A questo punto è necessario descrivere più dettagliatamente parte dell’architettura del Commodore 64.

    Il Commodore 64 utilizzava un processore MOS 6510, una versione più recente del chip MOS 6502 presente su molti computer della concorrenza a quei tempi, fra cui la famiglia degli Apple II e gli Atari 400 e 800. Dato che il bus dati del 6502 (e quindi del 6510) era a 16 bit soltanto, l’intervallo di memoria massimo indirizzabile direttamente era di 64 KB. Per aumentare la memoria disponibile venne implementata un’architettura ‘a banchi’, che permetteva di mappare aree diverse di memoria sotto il controllo dell’utente, semplicemente scrivendo il valore appropriato in una determinata porta mappata.

    […] Dato che le tutte le regioni mappate dovevano rientrare nell’intervallo dei 64 KB, un gruppo di intervalli di memoria forniva la base per tutta la memoria in banchi, così da offrire il quantitativo massimo di memoria sempre disponibile. Ciò riduceva di gran lunga la complessità del programma medio. D’altro canto, tuttavia, erano necessari svariati passaggi affinché un programma in esecuzione all’interno di un banco di memoria potesse accedere ai dati contenuti in un altro banco di memoria. Il primo passaggio era quello di inserire codice in una parte di memoria non allocata in banchi ed eseguirlo. In seguito, quel codice doveva togliere il programma dal banco, inserire nel banco i dati richiesti, accedere a quei dati e salvarli, poi togliere i dati dal banco, rimettere nuovamente il programma nel banco, ripristinare i dati e restituire il controllo al programma.

    Un effetto collaterale dell’allocazione in banchi della memoria: si trattava di un ottimo sistema per nascondere un programma, dato che il programma non risultava visibile se la sua memoria non veniva allocata in un banco. Ecco perché BHP piazzava il suo codice nella memoria allocata.

    Dopo essersi copiato nella memoria in banchi, il virus ripristinava il programma host alla sua posizione in memoria originaria e ripristinava la dimensione del programma ai valori originali. Questo permetteva al programma host di eseguirsi come se non fosse infettato. Tuttavia in questa fase il virus verificava il checksum del codice Basic del virus e se il checksum non corrispondeva, il virus sovrascriveva la memoria dell’host.

    Una nota interessante sulla routine di verifica del checksum è che ignorava i primi tre byte del codice (ossia il numero di riga e il comando SYS): ciò facilitava il lavoro alla persona che avrebbe prodotto la variante successiva del virus. Malgrado la variante successiva differiva solamente per il numero di riga, questo fu sufficiente a battere il programma BHP-Killer, poiché BHP-Killer controllava l’intero codice Basic, compreso il numero di riga.

    Il virus controllava se era già in esecuzione leggendo un byte di una specifica posizione in memoria. Se i valori corrispondevano, il virus assumeva che un’altra sua copia era in esecuzione. […] Se non vi era una copia del virus già in esecuzione, il virus copiava una porzione di codice in un indirizzo basso in un’area di memoria non allocata, agganciando svariati vettori e puntandoli verso il codice copiato.

    I vettori agganciati erano ILOAD, ISAVE, MAIN, NMI, CBINV e RESET. L’aggancio di MAIN, NMI, CBINV e RESET rendeva il virus immune dai comandi di interruzione Break, Reset e dalla combinazione Run/Stop-Restore. Tali agganci garantivano al virus di non perdere il controllo durante il riavvio della macchina. Una simile tecnica venne poi impiegata negli agganci Ctrl-Alt-Delete impiegati da virus successivi nella piattaforma IBM PC, e negli agganci Ctrl-Amiga-Amiga nella piattaforma Commodore Amiga.

    Una volta effettuati gli agganci, il virus eseguiva il codice dell’host. Il codice principale del virus sarebbe stato invocato a ogni richiesta di caricare o salvare un file.

    L’aggancio ILOAD veniva raggiunto quando occorreva effettuare ricerche su un disco. Ciò avveniva ogni volta che si richiedeva l’elenco di una directory, e poteva accadere quando si effettuava una ricerca utilizzando un nome file con caratteri jolly, oppure la prima volta che si accedeva a un file. Altrimenti, l’hardware del lettore salvava in cache fino a 2 KB di dati e li restituiva direttamente.

    Il virus chiamava il gestore ILOAD originale, poi controllava se era stato caricato un programma infettato. In caso positivo, il virus ripristinava il programma host alla sua posizione in memoria originaria e ripristinava la dimensione del programma ai valori originali. Altrimenti, anche se non era stato caricato alcun file, il virus invocava la routine di infezione.

    L’aggancio ISAVE veniva raggiunto a ogni salvataggio di un file. Il virus chiamava il gestore ISAVE originale per salvare il file, quindi invocava la routine di infezione.

    La routine di infezione cominciava controllando che il dispositivo richiesto fosse un lettore di dischetti. In caso positivo, il virus apriva il primo file nella cache. Il primo file in cache sarebbe stato il file salvato se questo codice veniva raggiunto attraverso l’aggancio ISAVE, altrimenti sarebbe stato il primo file nell’elenco della directory. Se il file era un programma Basic, il virus effettuava un veloce controllo di infezione leggendo il primo byte del programma e confrontandolo con il comando SYS. Inizialmente il virus leggeva soltanto un byte poiché i lettori di dischetti erano dispositivi seriali nella piattaforma Commodore 64, e quindi molto lenti. Tuttavia, se il comando SYS era presente, il virus verificava l’infezione leggendo e confrontando fino a 27 byte successivi. Un file veniva considerato infetto se tutti i 27 byte corrispondevano.

    Se un file non era infetto, il virus passava a leggere dati dalla cache hardware. Il primo controllo verificava la presenza del classico layout del disco: la directory doveva trovarsi sulla traccia 18, settore 0, e il file da infettare non doveva risiedere in quella traccia.

    Se tutti questi controlli erano positivi, il virus controllava l’elenco di tracce alla ricerca di settori liberi. Iniziava con la traccia contenente il file da infettare per poi muoversi all’esterno in direzioni alternate. Questo riduceva gli spostamenti che doveva effettuare il lettore per leggere il file in un secondo momento, e si trattava di un’ottimizzazione molto interessante, dato che alcuni virus multi-sector boot sull’IBM PC inserivano il loro codice a fine disco, e ciò causava spostamenti del lettore facilmente identificabili (da un punto di vista acustico: il lettore iniziava a produrre rumori sospetti).

    Se vi erano almeno otto settori liberi sulla medesima traccia, il virus allocava otto settori per sé e aggiornava la bitmap del settore per quella traccia. Il codice per aggiornare la bitmap del settore era bellissimo: allocava i settori e creava l’elenco dei numeri di settore allo stesso tempo. […]

    Il virus scriveva se stesso su disco in questo modo: il primo settore dell’host veniva copiato sull’ultimo settore allocato dal virus, poi quel primo settore veniva sostituito dal primo settore del virus. Dopodiché, il codice rimanente del virus veniva scritto sui settori allocati restanti. Qui era presente la directory stealth, ed era realizzata senza alcuno sforzo da parte dell’autore o degli autori del virus. Era un effetto collaterale del fatto che il virus non aggiornasse il conteggio dei blocchi nel settore della directory. Il conteggio dei blocchi non veniva usato dal DOS [l’autore si riferisce al Disk Operating System del Commodore 64, non al DOS dei PC IBM] per caricare i file — il suo scopo era puramente informativo.

    Infatti lo stesso problema si presentava sul DOS della famiglia degli Apple II, e un tale virus sarebbe stato più facile da realizzare per quella piattaforma, dato che la comunicazione con l’hardware è molto più semplice negli Apple II. L’unico effetto evidente nel caso di BHP era che il numero di blocchi liberi su disco era visibilmente inferiore, dato che il valore veniva calcolato utilizzando la bitmap del settore, non l’elenco della directory.

    Dopo qualsiasi chiamata a ILOAD o ISAVE, il virus verificava le condizioni di attivazione del payload, che erano le seguenti: a) la macchina doveva trovarsi in modalità ‘diretta’ (prompt dei comandi); b) il campo dei secondi del jiffy clock in tempo reale doveva essere un valore di 2–4 secondi; e c) la riga di scansione attuale del vertical retrace del monitor doveva essere almeno 128. Ciò rendeva l’attivazione un processo piuttosto casuale. Il payload doveva visualizzare un certo testo sul monitor, un carattere alla volta, cambiando in continuazione i colori del bordo.

    Il numero seriale visualizzato era il numero di volte che veniva invocato il controllo del payload. A ogni chiamata, veniva incrementato di una unità, e si resettava al valore zero solo dopo 65.536 chiamate.

    Adesso è chiaro: BHP era un virus molto avanti rispetto all’epoca.

    Il virus BHP era grande soltanto 2.030 byte.