Nelle ultime settimane ho avuto occasione di aiutare alcuni di noi della community di Instant Developer a impostare progetti con l’edizione Cloud a partire dalle proprie idee di app. È stata un’esperienza molto interessante perché mi ha aiutato a capire quali sono gli ostacoli da superare per chi ha già sviluppato tanti software e adesso si vuole cimentare con le app.
Come viene naturale fare, si affronta il mondo nuovo con i criteri che già si conoscono, e chi sviluppa software di mestiere è tentato quindi di ridurre il problema ad un livello tecnologico pensando che la soluzione per riuscire a creare app sia imparare a usare nuovi linguaggi, nuovi framework, nuove piattaforme.
Qual è l’inconveniente di questo approccio? Che fra le applicazioni classiche e le app ci sono delle differenze fondamentali difficili da percepire a prima vista; solo comprendendole appieno si potranno creare app in grado di dare la giusta concretezza alle tante belle idee che ho avuto modo di conoscere.
Ma quali sono queste differenze? Credo che si possano riassumere in tre punti principali.
La prima e fondamentale differenza è che le app non sono contenitori general purpose che permettono di fare un po’ di tutto. Si occupano invece di processi specifici e ben caratterizzati. Una regola molto importante da tenere sempre presente è quindi focalizzare sempre l’app.
La seconda è che le app sono software as a service. Nessuno si occuperà mai di installare fisicamente le app nei device, lo fanno gli utenti in autonomia; nessuno si aspetta di seguire un corso di formazione per imparare ad usare un’app, perché il funzionamento deve essere naturale.
La terza differenza è che le app devono offrire un livello di esperienza utente allo stato dell’arte. E oggi questo stato dell’arte è alto, molto alto: grafica professionale, funzionamento real time, supporto alle caratteristiche native dei dispositivi sono i requisiti minimi per tenere il passo con la concorrenza.
Chi, come tanti di noi, ha già sviluppato molto software usa criteri diversi: analizza, sviluppa e testa con una modalità che solitamente non tiene in considerazione queste differenze. Quello che può aiutare è lasciare l’aspetto tecnologico ad un momento successivo e inserire una fase iniziale di design di prodotto.
Non voglio qui rubare il mestiere a chi fa il designer di professione; sicuramente è una figura necessaria nei casi complessi. Penso però che ci sia un livello base alla portata di tutti, spesso sufficiente a realizzare prototipi in grado di colpire l’obiettivo.
Nei prossimi articoli vorrei entrare nel dettaglio e vedere come abbiamo affrontato questo livello base nei casi che ho avuto occasione di seguire, così da potervi proporre un metodo che può essere valido per tutti.
Vi può interessare? Avete mai affrontato questo livello di design nella costruzione di un software?
