Tognazzini's Proposals to improve the iPhone Springboard

Software

I had been waiting for Bruce Tognazzini to update his AskTOG column with some juicy contribution. When I realised that his most recent article talked about solutions to improve the interface of the iPhone / iPod touch, I immediately started reading, with much trepidation. But I have to admit that I was rather disappointed by his analysis, and I find none of his proposals particularly elegant or persuasive. His analysis is interesting and well thought out and deserves to be read in full, of course, he’s the interface and usability guru, not me. In the introductory paragraph, What’s wrong with today’s Springboard 1.0? (Springboard being the formal name of the home screen on the iPhone / iPod touch), Tognazzini makes an interesting premise:

Unlike the Finder or Desktop, rather than giving access to as many apps as you could possibly want, the current Springboard limits you to 180 apps. Paradoxically, this would not be a bad upper limit on a Mac or PC, as apps tend to equal trouble and the more you have, the more trouble you’ll encounter. On the iPhone/iPod Touch, however, 180 apps is terribly limiting as iPhone/iPod Touch apps translate to fun, not trouble, and the more apps you have, the more fun you can have.

The big limitation of the current system of screens on the iPhone is that you cannot sort the applications in a very efficient way:

Yes, Apple does give you the ability to sort out your apps, but that quickly breaks down when you have, for example, one and a half pages-worth of travel apps, a quarter page of medical, 7/8ths pages of scientific instruments, etc. With a fixed upper limit of 11 pages, with no way to label pages, and without sufficient space on pages to hold all one’s apps for that category, things begin to break down. As one approaches the 180-app upper limit, the pages descend into chaos, as new apps randomly place themselves in any available spaces, with nowhere logical to move them.

Once you hit the maximum number of apps, apps just start falling off the edge. This is apparently already happening in sufficient numbers that Apple, in 3.0, released an all-too-typical programmer hack: They enabled users to have invisible apps they can call up using Search as long as they can remember the app’s exact Name. For example, if you have the American Automobile Association app, you have to type in “AAA”. Oh, wait! It’s not called “AAA”, it’s called “Roadside”! What are the chances you’re going to remember that two years from now when your car breaks down?

Tognazzini suggests five alternatives for improving the situation.

The first is to enable users to have identification labels associated with pages:

SpringboardTravelAppPage.jpg

True, Tognazzini suggests that “Apple could initially show no labels at all so that the new user would encounter no added complexity,” but for me this solution is less effective than it looks. Example: what do you do when applications that fall under a certain category (or label) are more than 16? Suppose we have 22 applications under the label “Dictionaries and reference”: the first screen of 16 applications will have that label at the top, but what about the following screen, containing the other 6 apps? What label will it have? Still “Dictionaries and reference”? Or “Dictionaries and reference 2”? It does seem impractical to me.

And for those with 500 applications this is still a patched-up solution to say the least, as the only form of shortcut is to hold the finger on the label to display a drop-down menu with all the labels; this way the user can reach the screen with the desired application slightly more quickly. However, this creates two further problems, or rather two sides of the same problem: how to handle applications that do not belong to any label? (Because if you have only two IM apps, for instance, it seems pointless to devote one full screen to them). To better take advantage of the functionality the user should necessarily break applications into categories, a rather tedious task. Not to mention the interface itself, which becomes unnecessarily crowded from a visual standpoint, and unnecessarily complicated from an operational standpoint.

The second proposal (perhaps keeping in mind the partial ineffectiveness of the first) is vertical scrolling.

SpringboardScrollingPage.jpg

Vertical scrolling would not move page-at-a-time the way horizontal scrolling does, Tognazzini writes, Users, instead, could scroll row-by-row. They could also “throw” the page vertically and have the window scroll down rapidly, in the manner of the address book. This way you would circumvent the limit of the previous proposal (that is, how to handle more than 16 applications under the same label across more than one screen). With vertical scrolling you could have, say, 27 travel apps on a single labelled screen, for example. You keep the most used on top and scroll down to reach those you use less frequently.

It’s more appealing a proposal for sure, but I get the impression that being able to scroll in both directions, horizontally and vertically, will end up confusing users. Then I’d also like to know whether Tognazzini has thought about setting a limit to the vertical scroll or not. How many applications could be included in a vertically extended screen? I also think that by extending the app placement over the two axes requires more steps to reach an app. Imagine this scenario while you’re on the go: to find app XYZ you have to flip three screens horizontally, then scroll ‘a bit’ vertically, but since vertical scrolling doesn’t move one page-at-a-time but row-by-row as a list, finding the application you are looking for isn’t so straightforward because it is more difficult to memorise its position in your muscle memory, so to speak.

The third proposal: User-Controlled Icon Positioning; that is, letting the user place application icons anywhere in a page in some characteristic way, to be able to recognise a certain page at a glance:

SpringboardThreePages.jpg

Uhm, no, I can’t find this convincing enough. I admit I have no rational objection to it, just a gut reaction: I do not find this improvement particularly elegant or effective. As you keep buying and adding apps, it’s difficult to maintain these distinctive layouts.

The fourth proposal: Containers. A lot of people talk about the problem of organising applications on the iPhone, and the idea of enclosing them in containers (or folders, drawers, stacks, what you will) is usually the first that comes to mind, especially to tech-savvy users who are used to the metaphor of the desktop computer. I have already addressed part of this argument in the past, and I still think that the introduction of folders would be a step backwards with regard to the immediacy and simplicity of the iPhone’s interface. It would be necessary to devise a way (or command or gesture) to create a new folder, then another to visually differentiate each folder, then another to insert / change the name, then another to move items in and out of a folder, to manage a folder hierarchy, and so on.

Yes, I have my own proposal, which I’ll explain in a moment. Now comes Tog’s fifth proposal: multiple links, namely the possibility to have aliases to reach a certain application from different points.

No, no, absolutely not. It’s complicating and confusing things to the highest level. It is, once again, looking at the iPhone and thinking that its interface is extensible in the same way as a computer interface is. Or considered as such. On iPhone spaces and paradigms are different, and one must take these differences into account when navigating its interface. Any addition should consider how much it affects the whole interface, how much complexity it adds, how many new gestures it introduces and whether they’re worth it, and so on.

My modest proposal

I, too, have been reflecting on how to tackle the problem and limitations of the iPhone springboard mentioned by Tognazzini. My proposal takes into account something I find essential: the problem of managing more than 180 applications installed on your iPhone or iPod touch directly affects only a minority of users (we are talking about a lot of people for sure, but considering the global amount of iPhones out there, those who manage more than 180 apps are still a minority). Such a proposal for improving the iPhone springboard must therefore be as non-intrusive as possible for the majority of users, who should be able to keep using their iPhone as usual. The proposal must not complicate the iPhone UI and must not introduce visual clutter or new commands or gestures that are difficult to memorise.

My proposal is the possibility to view the contents of the iPhone in an alternative, optional, transparent way. It doesn’t move or change anything permanently — it’s the ability to switch to a different view that hopefully can help those who have a disproportionate number of applications. My proposal is to create on the iPhone OS the equivalent of this application (or widget):

gestisci-widget.png

Say you have an application that is called “Manage Apps” or “App Manager”. Tap the icon and you’re presented with a MobileMail-like UI: apps are displayed in ‘List view’. Want to put all weather apps in a specific folder? Tap on [+] and you create that folder. You can even choose between a set of default folders, possibly with distinctive icons (e.g. reflecting the App Store categories). Folders always appear at the top of the list, followed by any application you don’t want to put into a folder. Folders and apps are sorted alphabetically, and to browse them quickly there’s the familiar A‑Z column on the right. There might even be Smart folders, like in the Finder or in iTunes. User-definable Smart folders, of course, but also with presets to automatically organise the applications following the App Store categories and criteria (a quick solution for those who can’t be bothered to create ad hoc categories).

To manage the movement of large numbers of applications inside folders you may select them in advance and then move them, just like email messages within MobileMail. Or at worst you could resort to iTunes and do it from your Mac.

All this sorting and organisation would happen only within the “Manage Apps” application, and would be an easier, more powerful option for those with large volumes of applications. You would return to the familiar screens of icons and classic iPhone view by quitting the app at any time. So it would still be easy to have access to the apps we use most (the ones we generally place on the first 2–3 screens) and there wouldn’t be any unnecessary complexity.

Those who have a lot of apps would benefit from having the ability to set alternative views within a sort of ‘app browser’. Those who only have four or five screens of apps can easily ignore this new app browser/manager and continue to use the iPhone or iPod touch without any visible change in the UI they know and love. I think it’s an elegant and potentially effective way to manage large amounts of apps, but obviously it’s not for me to say.

Le proposte di Tognazzini per migliorare l'interfaccia di iPhone

Mele e appunti

Aspettavo da un po’ che Bruce Tognazzini [Wikipedia ITA | Wikipedia ING] aggiornasse la sua rubrica AskTOG con qualche contributo succoso. Quando ho compreso che il suo articolo più recente parlava di soluzioni pensate per migliorare l’interfaccia di iPhone / iPod touch, mi sono buttato a capofitto nella lettura. Ma devo ammettere di essere rimasto piuttosto deluso dalla sua analisi, e non trovo nessuna delle sue proposte particolarmente elegante o convincente. La sua analisi rimane interessante e ponderata e merita di essere letta integralmente; ovvio, il guru dell’usabilità è lui, non io.

Nel paragrafo introduttivo, What’s wrong with today’s Springboard 1.0? (Che cosa non va con l’attuale Springboard 1.0? — ‘Springboard’ è la denominazione formale della schermata principale di iPhone / iPod touch), Tognazzini fa una premessa interessante:

A differenza del Finder o della Scrivania, invece di fornire accesso a tutte le applicazioni che un utente potrebbe volere, l’attuale sistema di schermate pone un limite a 180 applicazioni. Paradossalmente questo non sarebbe male se si trattasse di un Mac o un PC, dato che [su un computer] le applicazioni possono essere problematiche, e più ne installiamo, più il rischio di incappare in qualche problema aumenta. Su iPhone / iPod touch, però, 180 applicazioni è una quantità estremamente limitata, dato che le applicazioni per iPhone / iPod touch sono spessissimo sinonimo di divertimento, intrattenimento, e non di problemi, e pertanto più applicazioni installiamo, più giovamento ne possiamo trarre. 

Il grosso limite dell’attuale sistema di schermate su iPhone è dato dal fatto che non è possibile ordinare le applicazioni in maniera davvero efficiente:

Sì, Apple offre un metodo per ordinare le applicazioni, ma diventa rapidamente inefficace quando si possiede, per esempio, una pagina e mezzo di applicazioni dedicate ai viaggi, un quarto di pagina con applicazioni mediche, 7/8 di una pagina pieni di programmi scientifici, eccetera. Con un limite prefissato di 11 pagine, senza alcuna possibilità di apporre etichette alle pagine, e senza spazio sufficiente sulle singole pagine per contenere le applicazioni di una certa categoria, le cose cominciano a farsi difficili. All’avvicinarsi al limite di 180 applicazioni, le pagine diventano caotiche, dato che le nuove applicazioni acquistate vengono sistemate un po’ a caso dove c’è spazio, senza una posizione logica ove spostarle.

Arrivati al tetto massimo di applicazioni, le cose si complicano. E il problema ha raggiunto un’entità tale che Apple, con la versione 3.0 di iPhone OS, ha affrontato il problema con un classico hack da programmatori: il limite delle 180 applicazioni rimane, ma è possibile continuare a installarne altre, solo che non saranno visibili. Gli utenti le possono cercare utilizzando Spotlight a meno che si ricordino il nome esatto dell’applicazione. Per esempio, se avete l’applicazione della American Automobile Association, dovrete immettere “AAA”. Ah no, un momento! Non si chiama “AAA”, ma “Roadside”! Quante sono le probabilità che vi ricorderete della differenza fra un paio d’anni quando avrete problemi con la vostra auto?

Tognazzini propone 5 alternative per migliorare la situazione.

La prima consiste nel dare la possibilità all’utente di avere etichette identificative associate alle pagine:

SpringboardTravelAppPage.jpg

È vero, Tognazzini suggerisce che Apple potrebbe fare in modo di non visualizzare alcuna etichetta inizialmente, così che il nuovo utente non incontri nessuna complessità aggiunta, ma per me questa soluzione è meno efficace di quel che sembra. Esempio: che si fa quando le applicazioni che rientrano sotto una certa categoria (quindi etichetta) sono più di 16? Supponiamo di avere 22 applicazioni sotto l’etichetta “Dizionari e consultazione”: la prima paginata di 16 applicazioni avrà quell’etichetta in alto, e la seconda pagina (contenente le altre 6) che etichetta avrà? Ancora “Dizionari e consultazione”? O “Dizionari e consultazione 2”? A me sembra poco pratico.

E per chi possiede 500 applicazioni è comunque una soluzione a dir poco provvisoria, in quanto l’unica forma di scorciatoia offerta è quella di tener premuto sull’etichetta per far comparire un menu a discesa con tutte le etichette impostate: l’utente può così raggiungere più rapidamente la pagina con l’applicazione desiderata. Ciò tuttavia crea due problemi ulteriori, o due facce dello stesso problema: come gestire le applicazioni che non appartengono a nessuna etichetta (sì perché se si possiedono soltanto due applicazioni dedicate alla messaggeria istantanea, per esempio, mi sembra inutile dedicare loro un’intera pagina con relativa etichetta)? L’utente, per meglio approfittare della funzionalità, dovrebbe obbligatoriamente suddividere le applicazioni in categorie, un compito piuttosto tedioso. Per non parlare dell’interfaccia stessa, che diventa inutilmente affollata da un punto di vista visivo, e complicata da un punto di vista operativo.

La seconda proposta (forse tenendo in mente la parziale inefficacia della prima): lo scorrimento verticale.

SpringboardScrollingPage.jpg

Lo scorrimento verticale non si muoverebbe ‘a paginate’ come avviene quello orizzontale, scrive Tognazzini, ma si sposterebbe di riga in riga per individuare le applicazioni in maniera raffinata. In questo modo si potrebbe sopperire al limite della proposta precedente che ho evidenziato (ossia come gestire un numero maggiore di 16 applicazioni appartenenti alla stessa ‘etichetta’). Con lo scorrimento verticale si potrebbero avere 27 applicazioni di viaggio su una sola pagina-con-etichetta, per esempio; si tengono in alto le più importanti o usate, e si scorre col dito verso il basso per accedere alle altre. È una proposta più accattivante, ma ho l’impressione che il doppio scorrimento, in orizzontale e in verticale, finirebbe col disorientare gli utenti. Sarei poi curioso di sapere se Tognazzini ha pensato di stabilire un limite allo scorrimento verticale o no. Quante applicazioni si potrebbero inserire? Inoltre ho l’impressione che estendere sui due assi la disposizione delle applicazioni finisca col richiedere all’utente un maggior numero di movimenti per raggiungere una tale applicazione. Immaginiamoci lo scenario in movimento: per trovare l’applicazione X bisogna sfogliare tre volte orizzontalmente, poi verticalmente, ma dato che lo scorrimento in verticale non procede ‘a pagine’ ma come un elenco, non è così immediato trovare l’applicazione cercata perché risulta più difficile memorizzarne la posizione nella memoria muscolare.

La terza proposta: posizionamento manuale delle icone, ovvero lasciare all’utente la possibilità di disporre le applicazioni su una pagina in maniera caratteristica, potendo lasciare spazi vuoti in modo da riconoscere una certa pagina a colpo d’occhio:

SpringboardThreePages.jpg

Uhm… No. Non riesce a convincermi. Ammetto di non avere obiezioni razionali, solo una reazione istintiva: non mi pare elegante o particolarmente efficace. Con il continuo aggiungersi di applicazioni sarebbe comunque difficile mantenere questi layout distintivi.

La quarta proposta: Contenitori.

Tantissima gente ha tirato fuori il problema di organizzare le applicazioni su iPhone, e l’idea di racchiuderle in contenitori (cartelle, cassetti, stack, quel che volete) è in genere la prima che viene in mente, specie agli utenti più ‘tecnici’ e che provengono dal continuo contatto con la metafora della scrivania sul computer. Ho già trattato in parte questo argomento, e continuo a pensare che l’introduzione delle cartelle sarebbe un passo indietro per quanto riguarda l’immediatezza e la semplicità dell’interfaccia di iPhone. Occorrerebbe inventare un sistema (o comando, o gesto) per creare una nuova cartella, poi un sistema per differenziare visivamente una cartella dall’altra, per inserire/modificare il nome, per spostare elementi dentro e fuori da una cartella, per gestire una gerarchia di cartelle, e così via. Questi sono compiti da tablet, non da smartphone.

Sì, ho una mia proposta, che esporrò alla fine. Ora manca la quinta proposta di Tognazzini: link multipli, ossia la possibilità di introdurre alias per raggiungere una certa applicazione da punti diversi.

No, no, assolutamente no. È complicare e confondere le idee al massimo livello. È, ancora una volta, guardare a iPhone pensando che l’interfaccia sia estensibile come quella di un computer. O considerabile come tale. Su iPhone gli spazi sono diversi, i paradigmi anche, e la navigazione al suo interno deve tenere conto di queste differenze. Ogni aggiunta deve considerare quanto va a impattare sull’interfaccia, quanto la complica, quali gestualità nuove introduce, e via dicendo.

La mia modesta proposta

Anch’io è da un po’ che rifletto su come affrontare il problema di cui parla Tognazzini. La mia proposta tiene in considerazione un aspetto che trovo fondamentale: il problema di gestire più di 180 applicazioni installate su iPhone o iPod touch è di una minoranza di utenti (stiamo sempre parlando di numeri considerevoli, di una ‘ricca’ minoranza, ma comunque di una minoranza). La proposta deve essere quindi intrusiva il meno possibile per la maggioranza dell’utenza, che deve poter continuare a usare iPhone come sempre. La proposta non deve complicare l’interfaccia e non deve introdurre affollamenti visivi né comandi o gestualità difficili da memorizzare.

La mia proposta riguarda la possibilità di visualizzare i contenuti di iPhone in maniera alternativa, opzionale, trasparente. Non si sposta nulla, non si cambia nulla potenzialmente, ma si può scegliere di passare a una vista differente che possa aiutare chi ha un numero spropositato di applicazioni. La mia proposta è creare su iPhone OS l’equivalente di questa applicazione:

gestisci-widget.png

Immaginiamo di avere un’applicazione che si chiama “Gestisci Applicazioni”. Tap sull’icona e si entra in un’interfaccia simile a quella di MobileMail: le applicazioni vengono visualizzate in ‘vista elenco’. Si vogliono mettere tutte le applicazioni per le previsioni del tempo in una cartella apposita? Tap su [+] e si crea la cartella. Si può persino scegliere fra una serie di cartelle predefinite, magari dotate di icone distintive (per esempio che rispecchiano le categorie dell’App Store). Le cartelle appaiono sempre in cima all’elenco, e fuori rimangono quelle applicazioni che non vogliamo inserire in nessuna cartella. Fuori e dentro le cartelle l’ordine prestabilito è alfabetico, e per muoversi rapidamente appare la colonna verticale con le lettere dalla A alla Z come nell’applicazione Contatti. Possono persino esserci delle cartelle speciali, come nel Finder o in iTunes, che dividono automaticamente le applicazioni nelle categorie dell’App Store (una soluzione rapida per chi non ha voglia di mettersi a creare categorie ad hoc). Per gestire spostamenti di grandi quantità di applicazioni in cartelle si potrebbero selezionare previamente e poi spostare, come si fa con i messaggi in MobileMail. O nella peggiore delle ipotesi ricorrere a iTunes e farlo dal Mac.

Tutti questi ordinamenti avverrebbero però soltanto all’interno della fantomatica applicazione “Gestisci Applicazioni” e sarebbero una vista facilitata per chi ha grossi volumi di applicazioni. Uscendo dall’applicazione ci ritroveremmo con le classiche schermate di iPhone, senza cambiamenti superficiali, così sarebbe facile avere accesso alle applicazioni che usiamo di più (e che in genere mettiamo nelle prime 2–3 schermate). In questo modo non si complica nulla. Chi ha molte applicazioni trae beneficio dalla versatilità delle viste e ordinamenti alternativi messi a disposizione dal gestore di applicazioni; chi ne ha poche può bellamente ignorare tale applicazione e continuare così, senza alcun cambiamento né imposizione di interfaccia. Mi sembra un’idea elegante ed efficace, ma ovviamente non sta a me dirlo.

Trovando la porta chiusa, Flash cerca di entrare dalla finestra

Mele e appunti

In una maniera o nell’altra, Adobe vuol fare entrare la tecnologia Flash su iPhone. È un’insistenza che fatico a comprendere, e che oltretutto può anche rivelarsi controproducente per l’azienda stessa. Ma tant’è. Non riuscendo a far sì che iPhone supporti Flash, cercano di fare il contrario, ossia di sfruttare la tecnologia Flash per creare applicazioni per iPhone. Come scriveva John Nack sul suo blog una settimana fa: Oggi ad Adobe MAX, l’azienda ha annunciato che i Flash tools saranno in grado di costruire applicazioni per iPhone che potranno essere regolarmente distribuite sull’App Store. Una versione beta di Flash Professional CS5 con questa nuova capacità dovrebbe essere rilasciata verso la fine di quest’anno. Non si tratta di file SWF di Flash, ma di applicazioni iPhone native.

Spiega Gruber, riportando la notizia: Non si tratta di un porting del runtime Flash. Non si può utilizzare per caricare contenuti Flash sul Web. Significa invece che gli sviluppatori Flash possono esportare applicazioni per iPhone native — file binari di codice ARM compilato in package con estensione .ipa — che possono poi essere inviati ad Apple attraverso il consueto processo di approvazione per l’ingresso nell’App Store. Esistono già sette applicazioni così realizzate disponibili nell’App Store (costruite grazie a versioni beta dei nuovi developer tools Flash).

La lettura delle FAQ sul sito di Adobe riguardanti la realizzazione di applicazioni per iPhone con Flash è istruttiva. Fra le altre cose si scopre, per esempio, che non è possibile utilizzare i controlli nativi di iPhone OS nelle applicazioni create con Flash. Ciò ovviamente non può che invitare alla realizzazione di un’interfaccia utente fatta di controlli arbitrari e differenti dallo standard a cui ci hanno abituato le applicazioni per iPhone costruite con metodi e strumenti canonici.

Ho aspettato alcuni giorni prima di trattare l’argomento sul mio blog più che altro per vedere se le mie reazioni istintive erano giuste. Non sono un programmatore, e mi sembrava presuntuoso scagliarmi contro Adobe mancando di informazioni. Ma le reazioni di persone che sanno il fatto proprio hanno confermato certi miei sospetti, ossia che scegliere di sviluppare applicazioni per iPhone via Flash non è proprio questa gran soluzione.

Jeff Rock (che, fra l’altro è l’autore di Tumblr per iPhone, un’ottima applicazione) scrive:

In sostanza: non è possibile compilare Actionscript 3 in un’applicazione iPhone. Adobe ha realizzato un qualche tipo di traduttore AS3 — Objective‑C selettivo. Alcuni dei motivi per non usarlo:

  • Bug. È già abbastanza arduo effettuare il bug testing sull’Objective‑C in forma nativa, figuriamoci attraverso una qualche scatola nera fatta da Adobe. […]
  • Gestione della memoria. Volete davvero affidarvi a un’entità di terze parti per la ritenzione e il rilascio di oggetti? Questo non è il genere di cose che è preferibile lasciare in mani altrui.
  • Cambiamenti nel SDK. Apple va avanti con il suo classico ritmo. Stare al passo con il suo SDK è fondamentale, e aspettare che Adobe (o una qualsiasi altra entità che non siate voi) si adegui ai cambiamenti non è una mossa intelligente.
  • Rottura delle HIG (Linee Guida dell’Interfaccia utente). Ho letto le FAQ e pare che non si possa accedere a UIKit. Quindi non è possibile utilizzare nessuno degli ottimi controlli messi a disposizione da Apple. Quindi siamo costretti a sorbirci qualunque pasticcio di interfaccia utente lo sviluppatore Flash di turno vuole imbastire. Vi lascio un istante per rifletterci su.
  • Capacità. Non avete a disposizione nemmeno l’intero SDK. Solo quel che Adobe ha voglia di supportare. Se vi imbarcate in un progetto e a un certo punto vi rendete conto che vi occorre l’accesso a una particolare API Apple non supportata, beh, si mette male per voi. 

Tutti questi fattori si uniscono al fatto che un’entità inaffidabile [Adobe] diventa il singolo punto di errore. E prima che ce ne dimentichiamo, Adobe stessa è a malapena in grado di scrivere applicazioni in Objective‑C. Stiamo ancora aspettando un aggiornamento alla Suite CS4 che le impedisca di andare in crash quando si muove il mouse troppo in fretta. Volete davvero fidarvi di loro per la gestione della vostra memoria, per la traduzione del vostro codice e nello stare al passo con il SDK di Apple?

Louis Gerbarg, dopo aver esaminato i contenuti del package .ipa di un’applicazione iPhone creata con Flash CS5 beta, scrive:

Tecnicamente parlando, pare davvero che [i contenuti] siano in linea con l’accordo dell’SDK, se si considera però il fatto che Adobe sembra effettuare chiamate ad API private. Dovrebbe essere in grado di fare ciò che le serve senza dover fare quelle chiamate, per cui alla fine questo dovrebbe essere un non-problema.

Ora, l’idea che il prodotto di questa cosa sia indistinguibile da quanto produce Xcode è risibile. Sono due risultati molto diversi, e non in senso buono. Se da un lato le applicazioni [realizzate in Flash] possono arrivare a ottenere frame rate accettabili su un iPhone 3GS, ciò non accade su hardware meno recente, e quasi certamente consumano più batteria rispetto ai giochi creati nativamente. 

Insomma, a me sembra piuttosto chiaro dove il tutto stia andando a parare. Il fatto che Adobe voglia fare in modo che la prossima versione di Flash sia in grado di realizzare applicazioni per iPhone, più che una grande novità, mi sembra invece una conferma di quanto davvero Flash sia alla frutta. Per la serie: se HTML 5 gli darà il colpo di grazia sul Web, almeno lo si potrà usare per… fare qualcosa.

Adobe dovrebbe fermarsi un momento e fare quel che Apple ha fatto con Snow Leopard: ottimizzare l’esistente invece di continuare a gonfiare la Creative Suite aggiungendo funzioni di dubbia utilità e creando applicazioni sempre meno Mac e sempre meno affidabili.

Innovare è difficile

Mele e appunti

In questi giorni di silenzio ho raccolto qualche riflessione sull’argomento innovazione, più che altro perché ormai il termine mi pare davvero abusato e mi vien voglia di fare qualche distinguo, e poi perché mi è stata data l’occasione durante un mini-corso di informatica e design a cui ho partecipato in veste di ‘opinionista’, o co-conduttore che dir si voglia. L’incaricato di tenere il corso è un mio conoscente che ho aiutato nel suo passaggio da Windows a Mac, e con il quale abbiamo avuto modo di chiacchierare più volte su temi di tecnologia, usabilità, accessibilità, design, eccetera. Quando gli è stato affidato questo mini-corso, ha pensato di dargli un’impostazione un po’ insolita e di coinvolgermi — una maniera simpatica per estendere la conversazione a un pubblico più vasto, e chi meglio dei giovani virgulti universitari che fra pochi anni, se tutto fila liscio, saranno ingegneri, disegnatori industriali, e quant’altro.

Durante questo corso ci sono stati momenti estremamente istruttivi, ed è a uno di essi che mi voglio congiungere per affrontare il discorso innovazione in questa sede. Durante la prima giornata del corso, l’insegnante e il sottoscritto hanno lanciato una serie di argomenti più o meno provocatori per suscitare il dibattito. A me è venuto in mente l’articolo di Steven Frank sul dispositivo mobile ideale di cui ho parlato un paio di settimane fa, e così abbiamo provato a tastare il polso al nostro pubblico di studenti modificando leggermente la richiesta: “Pensate al panorama attuale dei computer portatili e dei dispositivi mobili in generale; una grande azienda del settore vi ha incaricato di realizzare un nuovo prodotto che contenga qualcosa di innovativo — un elemento, una tecnologia, un’idea che permetta di distinguere questo prodotto dagli altri”. Non volevamo creare un’atmosfera troppo austera, per cui abbiamo detto agli studenti di considerarla una seduta di brainstorming, per la serie ‘buttate carne al fuoco, cercate di non soffermarvi sull’immediata fattibilità dell’idea, ma cercate al tempo stesso di non sprofondare troppo nel fantascientifico’.

Ne sono venute fuori delle belle. Portatili realizzati con materiali derivati da plastica e gomma, per essere totalmente antiurto. Portatili con una tavoletta grafica al posto della tastiera. Computer di tipo Tablet che possono diventare un normale portatile agganciando la tastiera e chiudendosi a libro. Portatili con telecamera capace di effettuare la scansione della retina e che smettono di funzionare se non c’è il proprietario davanti. E via dicendo.

Non è e non voleva essere un test per trarne deduzioni scientifiche o statistiche, ma l’impressione che ho avuto ascoltando le proposte dei ragazzi è che innovazione debba spesso manifestarsi come qualcosa di radicale, di vistoso, di fantascientifico. È vero che avevamo detto agli studenti di non soffermarsi troppo sull’immediata fattibilità dell’idea, ma certe proposte tendevano a sfociare nel fantastico e nell’astratto. Non che le idee in sé fossero poi tanto male (a chi non piacerebbe un portatile che si ricarica con il movimento, come gli orologi automatici?), ma troppe avevano il sapore di essere feature fine a se stesse.

Innovare per innovare è un esercizio senza dubbio interessante. Senza ricerca, senza esplorazioni e brainstorming anche folli, non si va da nessuna parte e non si innova. Le novità in ambito tecnologico saltano fuori a ritmi considerevoli. Ma innovare in questo modo non è sufficiente. Non basta avere un’idea ‘originale’ o ‘innovativa’. Non basta nemmeno arrivare a costruirla e a brevettarla. A mio avviso l’innovazione, quella vera, non deve essere sempre necessariamente radicale, vistosa, fantascientifica. Deve soprattutto lasciare un segno. Mai come in questo campo (la tecnologia) occorre far tesoro dell’adagio “Non è tutt’oro quel che luccica”.

Una cosa davvero lampante saltata fuori durante la sessione con gli studenti è che le loro idee per una funzionalità innovativa in un computer portatile (o palmare) erano sempre svincolate dalla macchina stessa, non considerandone i limiti attuali, non considerando il contesto in cui mettere in pratica la loro idea geniale. Quando nelle discussioni a cui partecipo di persona con amici, oppure online, tiro in ballo usabilità e design sembro sempre ‘il solito fanatico della Mela’ e molti ancora erroneamente associano questi concetti a un discorso soltanto estetico, quando in realtà c’entrano poco o nulla. Il fatto è che senza considerazioni di design e di usabilità, un’idea (parlo sempre a livello tecnologico e informatico, ma il concetto si può estendere ad altre discipline) può essere innovativa finché vuole, ma farà poca strada.

Provo a fare qualche esempio. Quando si tira in ballo l’innovazione in materia di hardware, un elemento che tutti sentono il bisogno di modificare, alterare, eliminare, ridefinire, è la tastiera. È un retaggio delle macchine da scrivere, sa di vecchio. E allora ci si sbizzarrisce a creare dispositivi di input ‘innovativi’. Ho visto tastiere ad accordi, tastiere ergonomiche che permettono di scrivere con una mano sola, tastiere anatomiche, ecc. ecc. Alcuni solo prototipi, altri in commercio. Tutte idee strabilianti, molte con sistemi che permettono effettivamente una maggiore efficienza e velocità nell’immissione, ma tutte con un problema di fondo: per sfruttarle al massimo occorre imparare a usarle, e spesso la curva di apprendimento è abbastanza alta da scoraggiare l’utente (a meno che non sia costretto da una qualche disabilità che gli impedirebbe di utilizzare proficuamente una normale tastiera QWERTY). A questo si aggiunga la quasi totale ubiquità della tastiera classica: nel momento in cui il nostro utente diventato provetto nel maneggiare una tastiera esotica e innovativa si ritrova davanti a una QWERTY, ecco che il vantaggio e l’efficienza guadagnati vanno a farsi benedire.

Ci sono alcune pagine interessanti sulla tastiera nel classico The Psychology of Everyday Things di Donald Norman. Qualche breve estratto:

[…] Baloccarsi con il progetto della tastiera ideale è un passatempo diffuso. Alcuni schemi mantengono la configurazione esistente dei tasti, ma distribuiscono le lettere in maniera più efficace. Altri migliorano anche la disposizione fisica, adattandola in modo da rispettare la simmetria speculare delle due mani e tener conto della diversa agilità e distanza delle dita. Altri ancora riducono drasticamente il numero di tasti: un gruppo di tasti — un accordo — rappresenta una parola, permettendo di scrivere con una sola mano o con due mani a maggior velocità. Ma nessuna di queste innovazioni è stata realizzata perché la tastiera QWERTY, con i suoi difetti, è sufficientemente buona. Benché la sua disposizione pensata per evitare l’accavallarsi dei martelletti [della macchina da scrivere] non abbia più nessuna giustificazione meccanica, resta il fatto che molte coppie di lettere di uso comune sono assegnate alle due mani: una mano può prepararsi a battere il suo tasto mentre l’altra sta finendo, cosicché la velocità di battuta è migliore. […] 

Poco oltre parla anche del sistema Dvorak:

C’è un sistema migliore [della QWERTY] — la tastiera Dvorak — laboriosamente messa a punto da uno dei fondatori dell’ingegneria industriale (da cui prende il nome). È più facile da imparare e permette un aumento di velocità di circa il 10%, ma questo non è un miglioramento sufficiente a legittimare una rivoluzione nella tastiera. Milioni di persone dovrebbero reimparare a scrivere a macchina. Milioni di macchine dovrebbero essere cambiate. I vincoli sostanziali della pratica preesistente impediscono il cambiamento, anche quando questo sarebbe un progresso. 

E di seguito menziona le tastiere ad accordi, quelle usate dagli stenografi dei tribunali, che permettono un numero di combinazioni superiore e una velocità superiore a quella di qualsiasi dattilografo, dato che stampano direttamente sillabe e non singole lettere. Ma:

Le tastiere ad accordi presentano uno svantaggio tremendo: sono difficilissime da imparare e difficilissime da ricordare […]. Vi avvicinate per la prima volta a una tastiera normale e potete usarla subito: basta cercare la lettera che volete e pigiare sul tasto. Con una tastiera ad accordi bisogna premere vari tasti simultaneamente. Non c’è modo di contrassegnare i tasti e non c’è modo di capire come si fa solo guardando. […]

(D. Norman, La Caffettiera del Masochista — Psicopatologia degli oggetti quotidiani, Saggi Giunti, pagg. 167–168)

Adesso, tenendo presente queste considerazioni, guardiamo due esempi, tratti dallo stesso studio di design industriale, Art Lebedev. Forse ne avrete sentito parlare: sono i creatori della Optimus Maximus, una (costosissima) tastiera in cui ogni tasto è pienamente ridefinibile in quanto è un piccolo schermo che può visualizzare segni differenti. L’idea è eccellente e la realizzazione di ottima fattura. Affronta un problema non indifferente (l’uso agevole di più layout di tastiera senza usare mascherine per i tasti o, peggio, munirsi di più tastiere) e lo risolve in maniera innovativa e pratica.

Il secondo esempio è la Optimus Tactus. È ancora un concetto e non un prodotto finito, ma qui stiamo valutando l’idea sulla base dell’innovazione ‘vera’. Si tratta di una tastiera priva di tasti fisici, e quindi la versatilità di configurazione va ben oltre i singoli segni e si estende alle dimensioni dei tasti e alla loro disposizione. Nelle immagini di esempio si può vedere come sia riduttivo parlare di ‘tastiera’ con il progetto Tactus. È un dispositivo che può mostrare una grande quantità di varianti, anche riprodurre video. Un’idea innovativa? Potenzialmente sì, ma mi ricorda una delle idee tirate fuori dagli studenti durante il brainstorming di cui parlavo all’inizio. Il concetto di questa tastiera è attraente ma mi pare non tenga conto del fatto che in assenza di tasti fisici, e quindi di contorni e forme percepibili sotto i polpastrelli, è impossibile digitare senza osservare la tastiera, cosa che nessun dattilografo fa. Un conto è la tastiera virtuale di uno smartphone: vista l’area ristretta in cui si opera, area che viene spartita fra schermo e tastiera virtuale, è naturale che si scriva osservando la tastiera; in particolare, l’implementazione di iPhone, con il caratteristico feedback visivo e sonoro, la rende più facile da maneggiare. Ma una tastiera virtuale delle dimensioni di una tastiera normale (e soprattutto pensata per essere utilizzata in ambito desktop) non mi convince per niente.

Sempre per la serie “Non è tutt’oro quel che luccica”, prendiamo il nuovo Dell Latitude Z. È un portatile ultrasottile con schermo da 16″ e un sacco di ‘soluzioni innovative’. Intendiamoci, Dell ha realizzato un portatile senza dubbio interessante e uno dei pochi che ho visto finora che non cercano a tutti i costi di essere brutte copie di prodotti Apple. La tecnologia EdgeTouch (è possibile accedere alle applicazioni più usate toccando direttamente il bordo laterale dello schermo) mi sembra interessante e con un minimo di progettazione dietro: i controlli si trovano più o meno nel punto in cui l’utente afferra lo schermo con la mano per regolarne l’inclinazione, quindi sono piuttosto intuitivi da trovare e utilizzare.

Ma passiamo a un’altra delle tante innovazioni vantate da Dell per questo portatile — il sistema di ricarica della batteria a induzione. Il concetto, in breve, è lo stesso implementato da Palm con il Touchstone, un caricabatterie opzionale per il Pre che ricarica il telefono per induzione: nessun cavo, il telefono si aggancia alla stazione di caricamento con un magnete, e la batteria si ricarica grazie al contatto dei due oggetti. Questa idea, applicata a uno smartphone come ha fatto Palm, non è malvagia; considerate le piccole dimensioni del Pre, il Touchstone ha il suo perché e una certa praticità d’uso. Ma Dell ha voluto creare un simile caricatore per il Latitude, in forma di stand su cui appoggiare il portatile (è visibile nella pagina di Dell a cui ho linkato prima, in fondo al centro, dove dice “business package”). A parte il costo dello stand (349 dollari) e a parte il fatto che non è regolabile né in inclinazione né in altezza, chiamare questo sistema ‘rivoluzionario’ perché ‘senza fili’ mi pare un po’ esagerato. Per ricaricarsi, il portatile deve starci appoggiato sopra, e lo stand viene collegato alla corrente con un cavo. Nei video di presentazione delle caratteristiche e del design del portatile, viene sottolineata la praticità di questa soluzione mostrando l’utente tipo del Latitude Z che, giunto nel suo ufficio, appoggia il portatile sullo stand e poi usa il portatile in configurazione desktop, ossia collegato a monitor, tastiera, mouse esterni. Mentre lavora alla scrivania, il Latitude si ricarica. Comodo, ma chi non ha un monitor, tastiera, mouse esterni, se vuole utilizzare quello stand-ricaricatore mentre usa il computer non si ritroverà una soluzione altrettanto comoda. È chiaro quindi che quel tipo di utente non se ne farà nulla del rivoluzionario stand e si limiterà a usare il normalissimo alimentatore con cavo fornito di serie. Ah, e se poi si compra un monitor e vuole acquistare anche lo stand di ricarica, non avrà vita facile, perché l’apposita scheda da inserire nel computer per permettere questo sistema di ricarica a induzione, stando a quel che dice il sito, deve essere richiesta al momento dell’acquisto del computer (e sono altri 50 dollari). Insomma, occorre avere le idee chiare fin da subito.

Se vogliamo brutalmente metterci a fare la tabellina con i vantaggi e gli svantaggi, questa feature innovativa non ne esce tanto bene, e non pare ponderata in modo approfondito. L’impressione è proprio quella di sbandierare caratteristiche che provochino un effetto ‘wow’ ma poco altro. Specchietti per le allodole. O, se vogliamo essere meno trancianti, funzionalità ideate considerando un ventaglio limitato di utilizzi. Poco testate sul campo. Comode se utilizzate esclusivamente nella maniera presentata, un totale impaccio se si estende il raggio d’azione. Se alla fine risulta più pratico e maneggevole l’alimentatore classico, dov’è la reale innovazione dello stand di ricarica a induzione pseudo-wireless? L’innovazione, secondo me, sta altrove.

Innovare non è sempre infilare un elemento hardware o una tecnologia ‘mai vista prima’. A volte è riconfigurare elementi già esistenti in una maniera differente, originale e che, soprattutto, funziona. Che lascia il segno. Che spinge all’imitazione. Per questo mi scappa un po’ da ridere quando sento dire che Apple non sta innovando più e che pensa solo all’iPhone. iPhone stesso è tremendamente innovativo ed esemplare nel mostrare come sia possibile realizzare un prodotto di questo calibro riconfigurando ingredienti che, bene o male, erano già presenti nell’industria. Chi innova non sempre e non necessariamente deve essere un pioniere: basta che sappia applicare in maniera geniale anche un’idea non propria o non ricercata internamente. La tecnologia multi-touch esiste da prima di iPhone, ma l’implementazione di tale tecnologia su un dispositivo di piccole dimensioni da parte di Apple l’ha resa decisamente più praticabile di quei video dimostrativi che giravano per il Web con il tizio che si sbracciava su un intero tavolo multi-touch. Per questo sostengo che l’idea potenzialmente innovativa deve essere filtrata dal design e dall’usabilità per essere praticabile e per diventare vera innovazione arrivando a cambiare interi paradigmi di utilizzo. Per questo innovare davvero è difficile, e non basta il gadget, per sofisticato che sia.