Ecosistemi e iPhone: applicazioni vs. siti ottimizzati
In questo periodo vi ho parlato spesso di come i servizi che progettiamo possono doversi differenziare nell’architettura informativa, nei contenuti, nell’interazione e in molte altre caratteristiche a seconda dell’ambiente d’uso in cui vengono utilizzati dagli utenti.
A dipendenza del supporto fisico attraverso il quale tale servizio (sito) viene utilizzato (ma in generale il supporto fisico è solo uno degli elementi che fanno differenziare un ambiente d’uso da un altro), le sue caratteristiche andranno a cambiare.
Di Facebook per esempio esistono più versioni: il sito web tradizionale, il sito ottimizzato per iPhone e l’applicazione per iPhone.
In ognuno di questi ambienti Facebook va ad offrire agli utenti l’anima, il cuore, del suo servizio specificandosi e ottimizzandosi per il particolare ambiente d’uso.
Secondo questo principio, sito per iPhone e applicazione per iPhone dovrebbero avere entrambi ragione d’esistere (con specifiche diverse del servizio) se effettivamente l’ambiente d’uso risultasse essere differente.
Che cosa differenzia quindi l’ambiente d’uso di un’applicazione per iPhone dall’ambiente d’uso della navigazione web dello stesso servizio sempre su iPhone?
Anzitutto la possibilità di funzionare o meno offline.
In un post della settimana scorsa mi sono soffermata a riflettere con alcuni lettori del fatto che se un’applicazione per iPhone può funzionare solo in presenza di connessione, allora non c’è più motivo di differenziarla da un sito web ottimizzato.
Sicuramente la possibilità di utilizzare un’applicazione offline è un grande valore aggiunto per il servizio offerto.
Tuttavia se prendiamo come esempio Facebook, questo non ha ragione d’esistere scollegato dalla rete perchè il cuore dell’applicazione è appunto l’interazione con gli amici.
Dicevo nella discussione: “La forza di FB sta nel suo aggiornamento (il tempo reale): cosa stanno facendo i miei amici ora. Senza contare poi che i FB addicted controllano lo status delle attività dei propri amici ogni dieci minuti. E infine un altro punto di forza è la chat…”
E allora cosa differenzia Facebook dal suo fratello web based?
La maggiore potenzialità funzionale e tecnologica.
Le applicazioni hanno sempre motivo di esistere perchè nonostante l’iPhone sia sempre l’iPhone (sia quando navigo su Safari, sia quando uso un’applicazione), l’ambiente d’uso è comunque diverso (compreso il relativo approccio mentale degli utenti).
Le applicazioni hanno infatti la capacità di accedere in modo più completo alla potente tecnologia insita nella struttura dell’iPhone (accellerometro, GPS, macchina fotografica, ..).
Senza contare poi la velocità di utilizzo: il browser ha pur sempre bisogno di caricare i contenuti con lo sfogliare delle pagine.
Concludo questo post segnalandovi la funzionalità in cima alla todo list degli sviluppatori di facebook: in futuro sarà possibilie, tramite la tecnologia GPS dell’iPhone, condividere la propria posizione con gli amici e verificare la presenza o meno degli amici nelle proprie vicinanze.
Buon divertimento 
Vista così ad esempio su FB la questione della dualità della web-app e dell’app vera e propria
ha più sentore di hype che di una mera necessità.
Sinceramente non ho seguito l’evolversi della presenza di FB su iPhone può anche essere (salvo
smentite, ditemi voi…) che sia nata prima la versione web ottimizzata, diciamo relativamente
più rapida da realizzare al più si parla di css e js quindi know how che sicuramente era già
disponibile all’interno del team di sviluppo di FB.
Nel mentre veniva realizzata la versione per iPhone, quindi una sorta di “placebo” momentaneo che
dopo con il senno di poi non avrebbe più nemmeno ragione di esistere dato che l’applicazione
è disponibile gratuitamente.
Al più l’utilità della web-app potrebbe essere per chi non si è ancora registrato all’iTunes store,
ma credo che sia un caso molto remoto.
Decontestualizzando da FB direi che due applicazioni identiche, una web e una locale, abbiano ragione
d’esistere solo per motivi di hype e marketing, o a seguito di un processo di “tamponamento tecnologico”
che può essere fatto con la web-app e poi colmato del tutto con l’applicazione stand-alone.
Il vantaggio della web-app è però quello spesso di essere usabile anche su device come i cellulari
che sfruttano Android, quindi in teoria dimezzerei il costo dell’ottimizzazione su due device, mentre
la realizzazione dell’applicazione è valido solo per una tecnologia alla volta.
Certo lo svantaggio tangibile delle web-app è l’impossibilità di interfacciarsi alle componenti
avanzati che ogni device propone… o meglio la cosa è parzialmente vera, dato che potenzialmente
ad esempio Safari mobile potrebbe essere riscritto per supportare delle chiamate javascript per
ottenere informazioni sulla posizione gps, sugli accelerometri, sulla fotocamera.
Ovviamente a questo punto sta ad Apple decidere se implementare queste chiamate, ma molto probabilmente
così facendo il numero di applicazioni calerebbe drasticamente…
C’è anche da dire, e qui concludo, che Safari mobile, come anche il suo fratello gemello per mac,
segue le specifiche di HTML5 e quindi supporta anche i database locali… potenzialmente si potrebbero
fare degli specie di backup locali di un sito e fruirne offline anche usando il browser.
Ciao Lyo, però hai esposto unicamente i vantaggi di un’app e gli svantaggi di una web app!!!
Lo svantaggio principale delle app native è che rinunci ad averne il controllo.
Lo scriveva bene Baekdal qualche settimana fa (http://www.baekdal.com/notes/work/app-store-no-up-to-date/).
Il problema dell’accesso alle funzionalità del device via js è già in fase di soluzione così come quello dello storage offline.
Insomma, se escludiamo per ora i giochi, direi che avrebbe senso lavorare per migliorare l’efficienza e l’usabilità delle webapps piuttosto che concentrarsi sulle app.
Beh l’unico problema, dal punto di vista Apple, è che per creare una app bisogna essere sviluppatori autorizzati e pagare una quota associativa. Per fare una web-app il costo è 0.
Da qui nascono i dubbi sull’implementazione nativa delle chiamate al device via javascript nelle applicazioni come Safari.
Ad ogni modo chiunque ora può già implementare queste feature in una webview e creare il suo browser ibrido per utilizzare le sue webapp avanzate. (tra l’altro questo vale anche per android).
Matteo posso chiederti una delucidazione su questo punto?
Ps. Ero comunque curioso di leggere sulla questione controllo delle app, ma il link non va purtroppo
Disdetta! Deve essere successo qualcosa sul sito di Baekdal.
Comunque sia.
Thomas scrive in sostanza che (semplifico molto) per vedere pubblicata un’app sullo store devi sottostare a tutte le limitazioni note di Apple, aspettare il tempo necessario per avere la loro approvazione, rischiare di continuo di non averla… infine vedere pubblicato finalmente il proprio lavoro, cedendo una sostanziosa quota di revenue.
Dall’altra parte, con una web app, mantieni il controllo di tutto il processo produttivo e commerciale.
Insomma…
@Matteo e Matteo: Quello che mi interessa non è tanto capire quale versione sia meglio dell’altra (web-app o app) ma capire perchè ha senso che esistano entrambe e come sono stati sfruttati e declinati al meglio i due differenti ambienti d’uso.
Come le due versioni sono state progettate per essere fruite al meglio (nei contenuti, nella navigazione, nelle funzionalità offerte) nel loro contesto particolare.
Come, sulla base dello scopo (e sulla base dell’ambiente), si differenziano (senza tuttavia, in quanto ecosistema, mutare il cuore del servizio).
@Matteo Crippa: Sì è nata prima la versione ottimizzata per web, circa un anno fa (quindi ben prima che uscisse l’iPhone) proprio per poterla testare e costruire un primo know how per iPhone.
Questo però non dimostra che la versione web sia semplicemente “propedeutica” all’applicazione e che il suo destino sia essere soppiantata.
Cioè è vero che il servizio offerto è lo stesso (è sempre Facebook) ma non per questo si può dire che le applicazioni siano identiche.
Vorrei entrare nella testa del signor Facebook e sapere gli obiettivi di app e wep-app ma sospetto comunque che i due sistemi siano stati concepiti per sopravvivere indipendentemente..
Riguardo al vantaggio della wep-app adattabile a più piattaforme (android..), questo è certamente vero ma non riguarda più la versione web per iphone. Son proprio due cose diverse.
Sicuramente la web-app potrebbe in futuro, come dici tu, conquistarsi del valore aggiunto interfacciandosi con la tecnologia dell’iPhone (e non vedo l’ora perchè si aprirebbero degli scenari interessanti).
@Matteo Balocco: Mi sono soffermata sulle caratteristiche della wep-app perchè è la versione che più a bisogno di giustificazioni
Ma come dicevo sopra non è il mio scopo confrontare le due versioni per capire la migliore..
Se veramente tra breve non ci saranno più problemi di accesso alle funzionalità del device allora sì che alcune app rischieranno grosso. Sull’iPhone probabilmente le icone presenti nella dashboard potrebbero essere sempre più semplici favicon
Per quanto riguarda il controllo di Apple sulle applicazioni Luca ha scritto un post l’altro giorno che potrebbe interessarvi
Ciao Leonora, avevo già letto il post di Luca ma anche rileggendolo ora non vedo grosse contraddizioni rispetto a quanto ho scritto io (forse sono stroppo stanco e ho bisogno delle vacanze di natale come nessun altro), anzi, Luca riporta l’indicazione di una particolare severità di giudizio di Apple per consentire la distribuzione delle applicazioni native. Scelta peraltro sacrosanta ma che ancora una volta sposta l’ago del controllo fuori dall’ambito della coppia cliente/fornitore.
Se ciò può piacere comunque al progettista, perchè in ogni caso ne valorizza e giustifica il costo d’investimento, può apparire un po’ più azzardata per il cliente.
Voglio aggiungere che se (caso limite) l’applicazione si basa su api private – la maggioranza dei casi, credo, nel panorama commerciale italiano – non esiste problema di concorrenza sulla qualità del prodotto stesso.
Tornando a ciò che scrivevi tu, invece.
Se, come credo, astraendo all’eccesso il discorso assume importanza primaria l’analisi delle funzionalità di un’applicazione in mobilità, un’applicazione (indifferente che sia web o nativa) ha valore nella misura in cui sa/può adattarsi alle condizioni contestuali in cui viene fruita/utilizzata.
Un core applicativo web based, in alcune situazioni (quello a esempio di servizi distribuiti) è preferibile.
Diciamo non sempre, ok? Ma spesso sì.
Ora, tu scrivi che non è il tuo scopo capire quale approccio sia migliore.
Personalmente non credo ci sia un approccio migliore a priori e in assoluto, ovviamente.
Ma presto o tardi arriverà un momento in cui, commercialmente e progettualmente, questa decisione, all’interno di un’azienda, dovrà essere presa.
Se già non è stata presa a livello strategico aziendale (es.: si lavora su mobilità per iPhone e solo su app native).
E’ questo il vostro caso?
@Matteo Balocco: sì sì sicuramente se si parlasse di progetti concreti di un’azienda, questa dovrebe avere per forza una strategia e definire gli obiettivi per ogni ambiente d’uso (eventualmente preferire un ambiente ad un altro).
Ma in questo momento sono ancora in fase esplorativa (non sto progettando applicazioni per iPhone..). Quello che mi interessa è conoscere a fondo le caratteristiche di ogni ambiente per saperlo sfruttare al meglio quando verrà il momento
E’ verissimo quello che dici! “un’applicazione (indifferente che sia web o nativa) ha valore nella misura in cui sa/può adattarsi alle condizioni contestuali in cui viene fruita/utilizzata.
Un core applicativo web based, in alcune situazioni (quello a esempio di servizi distribuiti) è preferibile”
Quoto
Vi ho linkato il post di Luca solo perchè parlava appunto di quei cattivoni dei controllori Apple
..non è in contraddizione con quello che dici tu 
Ciao Leonora, ecco un caso abbastanza emblematico di quanto scrivevo.
http://landonf.bikemonkey.org/code/iphone/Apple_Lesson_Huh.20081213.html
Questo sviluppatore si è visto rifiutare (dopo 33 giorni) un’applicazione per un presunto uso non consentito di librerie private.
Cosa peraltro non vera. Risultato, doppio danno: lunga attesa e quindi mancato guadagno, e penalizzazione ingiusta.
Alla fine fortunatamente tutto è andato a posto, ma a che prezzo, in realtà?
Pingback: 19 Febbraio 2009, Social e Business Networking in Veneto (Nord Est Creativo)