Tempo fa ho innescato una certa polemica con gli utenti Apple (tra cui un sedicente ingegnere che non aveva idea di cosa fossero i protocolli MM1, MM3, MM4, MM7 ma parlava di obsolescenza degli MMS “come protocolli”) e ancora la polemica continua. A quanto pare gli articoli in questione sono ancora linkati e ogni tanto mi arriva lo sciroppato Apple che mi scrive (visto che i commenti sono chiusi). Ora, vorrei chiarire una cosa: per chi e’ del mestiere e fa l’architetto di sistemi, i vantaggi e i limiti di Apple e della sua filosofia di sviluppo sono chiarissimi. E specialmente e’ chiarissimo il “valore” di quel che si compra. Lo dico anche perche’ mi e’ stato regalato, btw, un ipod aziendale e mi sto divertendo a dissezionarne il firmware per scoprire la paranoia di Jobs.(1)
Torniamo al punto di partenza. Spiegare che cosa sia in realta’ la “facilita’ d’uso di Apple”, di cui si lavano la bocca in moldi, equivale a dover spiegare la differenza tra una “feature” ed uno “use case”. Quello che Apple fa e’ di vendervi del software che ha, apparentemente, tutte le features di cui parliamo, ma soddisfa un numero enormemente inferiore di use cases. Il che, essenzialmente, e’ la sua forza quando si deve diffondere tra utenti informaticamente bolsi, ma anche il suo limite quando non riesce ad entrare nelle aziende come invece fa Microsoft con tutte le sue suite di office automation.
Posso tentare di fare un esempio grossolano, e spiegare la differenza tra le due filosofe.
Sia chiaro che e’ un esempio a scopo didattico,
QUINDI per favore non venite a sofisticare sull’esempio.
Torniamo a noi.
Supponiamo di dover:
- Inviare fax ad uno o piu’ destinatari.
- Inviare email ad uno o piu’ destinatari.
- Inviare MMS ad uno o piu’ destinatari.
- Il destinatario e’ scelto da una rubrica.
Queste sono, per intenderci, le “features” del nostro software. Si tratta cioe’ di un elenco di capacita’ funzionali semplici, che non stanno tenendo conto dei cosiddetti “use cases”. Mettiamo adesso a confronto le due filosofie.
Microsoft fara’ un solo programma che fa tutto. Siccome un programma che fa tabelle si chiama “Excel” e uno per fare slides si chiama “Powerpoint”, e uno che fa database si chiama “Access”, allora un programma che fa questo si chiamera’ “Caffettiera Plasmatica”, in modo che sia facile immaginare che cosa fa. Apple invece fara’ al suo solito: produrra’ tre piccoli programmi chiamati Apple iSend Suite: iFax, iMail, iMMS.
Se adesso andiamo a livello di interfaccia grafica, ecco che capiamo le differenze. iFax parte, chiede il destinatario o i destinatari, e invia il fax. iMail parte, chiede l’indirizzo del destinatario o dei destinatari, e invia. iMMS(2) parte, chiede il numero del destinatario o dei destinatari, e invia il messaggio.
Microsoft invece proporra’ di: avviare Caffettiera Plasmatica, scegliere il destinatario, indicare
Se cerchiamo di descrivere le esperienze, nel caso apple abbiamo tre rubriche, una per i fax, una per gli mms e una per le email:
- Avvia iFax => metti destinatario(i) => invia.
- Avvia iMMS => metti destinatario(i) => invia.
- Avvia iMail => metti destinatario(i) => invia.
Questo fatto, essenzialmente e’ quello che vi produce la sensazione di “facilita’ di uso”: non dovete mai fare scelte reali. Una volta deciso che volete inviare un FAX, il programma NON PUO’ fare altro, visto che e’ di fatto one-purpose. Nel mondo Apple, l’albero di scelte dell’utente e’ piccolo o inesistente. Un programma fa MENO use-cases che puo’, tuttavia fornisce la feature.
Andiamo al caso di Microsoft: avremo una sola rubrica, nella quale per ogni utente e’ inserito sia il numero di fax, che di mms, che di email:
- Avvia Caffettiera Plasmatica => metti destinatario(i) => digli che vuoi inviare un fax => invia.
- Avvia Caffettiera Plasmatica => metti destinatario(i) => digli che vuoi inviare un MMS => invia
- Avvia Caffettiera Plasmatica => metti destinatario(i) => digli che vuoi inviare una email => invia
Come vedete, il programma Microsoft richiede una scelta in piu’, che ho evidenziato, cioe’ allunga la funzione semplice di un passaggio operativo. Nel singolo use-case appiattito alla funzionalita’, Microsoft perde 4 click a 3. Di conseguenza, chi vuole fare cose semplici trovera’ piu’ “usabile” il mondo MAC. Questa e’ la ragione per la quale il mondo MAC e’ famoso per essere “semplice”: Apple funziona quando lo use-case dell’utente e’ enormemente simile alla mera funzionalita’ richiesta. “Il programma manda i fax” significa , molto semplicemente “IO ci posso mandare i fax”.
Sia chiaro, questa non e’ una scelta di Apple: e’ una necessita’. Se andiamo a vedere come viene costruito il software, e pensiamo ad una fase di test, apple deve testare questi tre use-cases:
- Invia un messaggio ad un utente(i) della rubrica fax.
- Invia un messaggio ad un utente(i) della rubrica mms.
- Invia un messaggio ad un utente(i) della rubrica email.
Microsoft, invece, dovra’ testare circa questo:
- Invia un messaggio ad un utente(i) fax.
- Invia un messaggio ad un utente fax E ad un utente MMS.
- Invia un messaggio ad un utente fax E ad un utente email.
- Invia un messaggio ad un utente fax e allo STESSO utente in mms.
- Invia un messaggio ad un utente fax E ad un utente mms E ad un utente email.
- Invia un messaggio ad un utente via fax e allo STESSO utente via email E allo stesso utente via mms.
- Invia un messaggio ad un utente(i) della rubrica mms.
- Invia un messaggio ad un utente(i) della rubrica email.
In definitiva, cioe’, il fatto di aver unificato le funzionalita’ in Caffettiera Plasmatica, a parita’ di numero di funzionalita’, ha generato una GIGANTESCA quantita’ di possibili use-cases, i quali VANNO TESTATI TUTTI. E questo rende enormemente piu’ lunga e costosa la fase di sviluppo, perche’ nei casi di interfaccia utente i test ricalcano gli use cases, e non le mere specifiche funzionali.Il programma Apple iFax manda solo fax: ha due use cases: manda fax a uno, manda fax a tanti. Microsoft Caffettiera Plasmatica, invece , unificando le funzionalita’ si trova con una caterva di use-cases da affrontare. E per ognuno di loro dovra’ prevedere un qualche menu’ che dica al computer che cosa vogliamo fare.
Fin qui, e’ chiaro che il nostro utente singolo che compra un laptop di Apple per fare il libero professionista senza infrastrutture trovera’ comodissimo Apple. Lo considerera’ “facile”. E apple risparmiera’, perlomeno in fase di testing, un sacco di soldi.
LA filosofia di apple consiste, cioe’, nel supportare ogni funzionalita’ riducendo al MINIMO il numero di use-cases. Questo fa si’ che l’utente abbia pochissime scelte sul da farsi, perche’ una singola funzionalita’ e’ implementata SENZA alberi decisionali. Fa quello, solo quello e solo in un modo.
Adesso pero’ entriamo dentro una corporate, e la nostra segretaria chiede: ehi, devo mandare lo stesso messaggio a 376 utenti, alcuni mms, alcuni mail, alcuni fax. Che faccio?
La risposta di Apple e’
- Avvia iFax => metti destinatari => invia.
- Avvia iMMS => metti destinatari => invia.
- Avvia iMail => metti destinatari => invia.
La risposta di Microsoft e’:
- Apri Caffettiera Plasmatica => metti destinatari fax => metti destinatari mail => metti destinatari mms => invia.
E in questo use-case, Microsoft Caffettiera Plasmatica batte Apple iSend Suite 5 click contro 9.
Capite adesso perche’ Outlook + Exchange straccia , sul mercato, Apple iCal+iMail : il 90% delle installazioni corporate, enterprise e business (appunto, dove ci trovate la coppia Outlook+Exchange) ha da affrontare degli use-cases che non coincidono strettamente con la mera funzionalita’.
L’utente Apple, che generalmente non scrive software e se lo scrive accrocchia codice di merda che funziona solo sul suo computer(3), ovviamente e’ entusiasta del suo computer “per la produttivita’ PERSONALE”. Essendo una macchina per la produttivita’ PERSONALE, tutti gli use-cases si avvicinano moltissimo alla mera funzionalita’. In tal caso, iSend Suite dell’esempio e’ tutto quel che gli serve.
Questa differenza e’ , insieme , il punto di forza e il punto di debolezza di Apple. Certamente se dovete fare uno smartphone, cioe’ un computer per deficenti, (4) la filosofia di Apple vince. Chi usa uno smartphone usando un telefono per cose che dovrebbe fare con un computer e’ un idiota cosi’ stupido da non saper usare un PC. Di conseguenza, nella filosofia di Apple , che prevede use-case semplici, ci sguazza: un idiota non avra’ mai uno use-case complesso. La frase “devo mandare un messaggio ad una lista di persone di cui alcuni fax, alcune email e alcuni mms” non sta (tutta intera) nella sua mente primordiale: al massimo puo’ capire “devo mandare un fax”, o “devo mandare una email”, o “devo mandare un mms”.Ma quando saliamo di complessita’ degli use-case, cioe’ di QI, ci troviamo con cose piu’ complesse. E l’appiattimento dello use-case sulla mera funzionalita’ ovviamente ci complica la vita.
L’utente apple dice “io non devo avere un Outlook che ha dentro la possibilita’ di fare fatture per i pescivendoli, devo solo scriverci”. Aha. Certo. A meno che tu non faccia il pescivendolo.
LA frase “a meno che tu non faccia il pescivendolo” e’ il motivo per il quale il software Microsoft copre il 90 e rotti per cento della Office Automation. Microsoft ha capito una cosa importantissima che sembra sfuggire ad Apple: il software non si vende maggiormente se implementa piu’ funzionalita’, ma se implementa piu’ use-cases.
Questo sfortunatamente rappresenta il limite commerciale di Apple.
Se io mangio solo riso, tu mangi solo olive e lui mangia solo cetriolini, la stessa insalata mista copre tutte e tre le esigenze. Useremo tutti “solo il 30% dell’insalata, e’ vero”. Ma entreremo tutti nello stesso ristorante, che vende insalate. Se invece vendi solo riso, per quanto fatto bene, su tre clienti ne prenderai solo uno., e il tuo ristorante che vende solo riso non vincera’ mai sul mercato.
Se il mio software e’ molto semplice e si limita a fare poche cose ma bene, sara’ venduto solo a chi deve fare poche cose, cioe’ a pochi.
Se il mio software fa molte cose, anche un poco peggio, sara’ venduto a quei tanti che devono farci tante cose. Cioe’ a molti.
La gente dice “ma l’utente usa si e no il 10% di Microsoft Word”. Vero. Ma microsoft Word contiene anche (quasi sempre) proprio il 10% che serve a TE.
Il fatto che tutti usino solo il 10% di Word, cioe’, non significa che tutti usino LO STESSO 10%. Ed e’ qui il punto di maggiore diffusione: dieci utenti che usino il 10% di Word, e usino tutti un 10% diverso, riescono ancora a stare dentro lo stesso word. Un programma che faccia il 10% di word ne soddisfa solo uno su dieci.
In definitiva, i soloni che parlano di “usabilita” sono in genere early users prestati al giornalismo, i quali non riescono a capire che la “facilita’” di uso che Apple fornisce non e’ altro che il completo appiattimento della lista di use-cases alla lista delle specifiche funzionali.
Quando la lista di use-cases concide, o quasi, con la lista delle specifiche tecniche, state in genere parlando di un programma di Apple. Quando gli use-cases supportati sono la permutazione di tutte le possibili specifiche tecniche in un unico framework, di solito parlate di una filosofia di sviluppo tipica di Microsoft. (5)
Questa filosofia e’ obbligatoria per Apple in quanto non ha l’esperienza per gestire la moltiplicazione di use-cases, (l’esperienza di Gil Amelio insegna) , e rappresenta il punto di forza da un lato (il mondo puramente consumer, vedi iPad, iPod, iPhone, iBook, ma anche gli stessi computer ormai one-purpose per il DTP di piccoli professionisti) , ma dall’altro rappresenta la sua piu’ tremenda debolezza di mercato per quanto riguarda il mondo business e il mondo corporate.
Indubbiamente, un’azienda ha il compito di fare soldi, e li fa. Quindi Apple e’ ok. Ma gli utenti, ovviamente, ci fanno la figura che ci fanno.
Quindi, quando venite a dire che “apple e’ usabile”, o “apple e’ semplice da usare”, e lo dite di fronte a chi disegna servizi e software, vi ritrovate a farci una figura misera, perche’ in ultima analisi mostrate di non capire che non parliamo ne’ di usabilita’ ne’ di semplicita’, ma di mero appiattimento della lista degli use-case alla lista delle specifiche funzionali.
Chiunque , nel disegnare un software, puo’ prendere una lista di specifiche funzionali e trasformarla pari-pari in una lista di use-cases singoli. Otterra’ un software che vendera’ solo ad una piccola fetta del mercato, oppure ad un mercato fatto di utenti che non vanno oltre la singola specifica funzionale. Non occorre ne’ genio ne’ bravura ne’ competenza per questo: basta solo avere gli utenti giusti e farseli bastare.
E quindi, insomma, ci fate una discreta figura da incompetenti, proprio nella materia ove vi sforzavate di sembra competenti , da bravi early users non professionisti. Magari prestati al giornalismo. Mica potevate fare altro, del resto.
Uriel
(1) L’ ipod mi appartiene. Ergo posso farci il cazzo che mi pare, compreso passarlo in un NMR e vedere come sia fatto dentro , micron per micron. Se mi va di capire come funzioni il firmware piazzando un analizzatore di protocollo sul cavo USB, sono tutti cazzi MIEI. E’ mio, ricordate? L’analizzatore gira sul MIO PC, e io voglio sapere cosa succeda al MIO pc. Cosa che ho tutto il diritto di fare.
(2) L’ “ingegnere” del forum di Apple non lo sa, ma nel SOAP usato nel protocollo MM7 , nel campo riservato al destinatario, ci puo’ essere anche un indirizzo IPv4 o IPv6. Insomma, si possono mandare MMS a qualsiasi software capace di leggere uno SMIL, ovvero di serializzare un multipart mime.(3) Quando devo parlare con uno sviluppatore per sapere come funzioni un software e mi compare davanti con un fesso con un Apple, in genere annullo il meeting e faccio reverse engineering del suo software: imparero’ molte piu’ cose di quante ne sappia lui che lo ha scritto. E non mi sentiro’ dire che il software e’ ok perche’ “su localhost funziona”, dio banana.
(4) Abbiamo venduto un PC a chiunque avesse abbastanza neuroni per usarne uno. Per quelli ancora piu’ idioti, ci sono gli smartphone. E se qualcuno e’ ancora piu’ cretino, gli daremo un tablet. What’s next? Informatizzare i vegetali, suppongo. O i morti: e’ un mercato molto vasto, dopotutto.
(5) Se non riuscite a distinguere le specifiche tecniche dagli use cases, in genere state parlando con IBM. Se la cosa vi puo’ consolare, ricordate che neanche in IBM ci riescono.
Correlati
