Guida
Sito, web app o app mobile: cosa vi serve
Un sito racconta, una web app fa lavorare, un'app mobile vi segue in tasca. La distinzione non è tecnica: cambia lo scopo, e da quello discende come si progetta, quanto costa e come si misura se ha funzionato.
Questa pagina serve a scegliere prima di spendere. Se la scelta è già fatta e vi interessa capire cosa aspettarvi dai preventivi, la guida ai costi è qui.
La domanda che scioglie il dubbio
Chiedetevi cosa fa la stessa persona la seconda volta che torna.
Se torna per rileggere le stesse informazioni, o non torna affatto perché ha già trovato quello che cercava, è un sito. Il suo lavoro è essere trovato, farsi capire in fretta e portare a un contatto. Il successo si misura in visitatori che arrivano da una ricerca e compiono l'azione che vi interessa.
Se torna per fare qualcosa che aveva già fatto, con dati suoi che nel frattempo sono cambiati, è una web app. Il suo lavoro è far compiere operazioni in meno passaggi possibile. Il successo si misura in tempo risparmiato ed errori evitati, non in visite.
Se deve raggiungervi ovunque, funzionare senza rete, mandare notifiche o usare la fotocamera e i sensori del telefono, è un'app mobile. Ma è la risposta giusta meno spesso di quanto si pensi: se nessuna di quelle ragioni c'è, un sito ben fatto costa una frazione e non deve superare una revisione degli store a ogni modifica.
Cosa cambia in pratica
La ricercabilità. Un sito deve avere i contenuti nell'HTML, indicizzabili da Google e leggibili dagli agenti AI. Una web app vive dietro autenticazione e non deve essere indicizzata: semmai lo deve essere la pagina pubblica che la spiega.
Il modo di progettare. Un sito si progetta per la prima visita: la persona non sa nulla e va guidata. Una web app si progetta per la centesima: la persona sa già cosa vuole e ogni passaggio superfluo è un costo che paga ogni giorno.
La struttura del costo. Un sito ha un numero finito di pagine e un costo prevedibile. Una web app ha stati, ruoli e casi limite che crescono più in fretta delle schermate, e per questo si affronta a incrementi invece che tutta insieme.
Cosa succede dopo. Un sito pubblicato può restare fermo un anno senza danni. Una web app in uso genera richieste di modifica dal primo giorno, perché le persone che la usano scoprono cose che nessuno aveva previsto. Va messo in conto.
Se serve un'app: nativa o cross-platform
Il nativo serve davvero quando l'app dipende dall'hardware o deve spremere prestazioni: fotocamera con controlli avanzati, elaborazione in tempo reale, realtà aumentata, funzionamento continuo in secondo piano. Qui la differenza non è sottile: è la differenza fra funzionare e non funzionare.
Se l'app è fatta di interfacce e dati, che è la maggior parte dei casi, il cross-platform copre iOS e Android con una base di codice sola. Due app native costano quasi il doppio, e il doppio si paga anche negli anni successivi: ogni correzione si scrive due volte, ogni funzione nuova si progetta due volte, e con il tempo le due versioni divergono in modi che nessuno ha deciso.
Il cross-platform ha un costo suo, che si scopre dopo: la dipendenza da un livello intermedio. Quando iOS introduce qualcosa di nuovo bisogna aspettare che il framework lo supporti. Nella pratica si tratta di settimane, e riguarda funzioni che la maggior parte delle app non usa, ma va saputo prima.
I casi ibridi, che sono la maggioranza
Molti progetti reali sono più cose insieme, e l'errore ricorrente è applicare un solo criterio a tutto.
Un e-commerce ha un catalogo che deve essere trovato dai motori di ricerca e un'area ordini che deve essere veloce da usare. Una piattaforma di prenotazioni ha pagine pubbliche che vendono e un pannello di gestione che serve a lavorare. In questi casi le due parti vanno progettate con criteri diversi: statica e indicizzabile la parte pubblica, applicativa la parte riservata.
Trattare tutto come applicazione produce un sito invisibile ai motori di ricerca. Trattare tutto come sito produce uno strumento faticosissimo per chi lo usa ogni giorno.
Come lo affrontiamo noi
Partiamo sempre dalla seconda visita, non dalla prima. È la domanda che in mezz'ora di conversazione dice cosa serve, e a volte la risposta è che serve qualcosa di più piccolo di quello immaginato.
Prima di scegliere una tecnologia elenchiamo i vincoli reali e li pesiamo: quante funzioni dipendono dall'hardware, quanto sono centrali, quanto spesso verranno usate. La scelta viene motivata per iscritto, con le alternative scartate e il perché. Serve a voi per rivalutarla fra un anno, e serve a chiunque erediti il progetto dopo di noi.
Domande frequenti
Un e-commerce è un sito o una web app?
Entrambe le cose, ed è per questo che confonde. Il catalogo e le schede prodotto sono contenuto pubblico che deve essere indicizzato; il carrello, il pagamento e l'area ordini sono applicazione. Un buon e-commerce tratta le due parti con criteri diversi invece di applicarne uno solo a tutto.
Possiamo partire da un sito e aggiungere funzioni dopo?
Sì, ed è spesso la scelta giusta, purché sia una decisione presa in anticipo. Un sito nato senza prevedere autenticazione e dati strutturati può essere esteso, ma la parte applicativa nasce sopra una fondazione che non era pensata per reggerla.
Il cross-platform si vede che non è nativo?
Non più, se è fatto bene. Si vede quando si trascurano i dettagli che le persone percepiscono senza saperli nominare: il ritardo nello scorrimento, la tastiera che copre il campo, il gesto di ritorno che su iOS deve funzionare dal bordo. Sono difetti di cura, non di tecnologia.
Conviene partire da una sola piattaforma?
Se il pubblico è chiaramente sbilanciato, sì: si valida su una e si estende dopo. Ma se si prevede di coprire entrambe entro un anno, partire nativi su una sola porta a riscrivere tutto per la seconda, e il cross-platform torna a essere la scelta economica.
Parliamone
Descriveteci cosa deve fare il progetto, non come. In mezz'ora si capisce quale dei tre serve, se ci sono vincoli che impongono il nativo, o se state per pagare qualcosa che non vi serve.