1 LA APP-MOBILE PER IL PUBBLICO
GEO - Rappresenta- zione sul territorio e mappe tematiche
CARD - Schede personalizzabili
e business
GAME – Gaming, al- tro (chat, ‘social’,
foto, ecc.)
Allo stato e sia pure come prototipo disponiamo di una app-mobile con diverse funzioni, articolata in ‘tab’ accessibili col click sull’iconcina a fondo pagina.
Il proseguo schematizza lo stato dell’arte in quanto scenario di riferimento e in- dicazione per possibili varianti.
2
➢ GEO: consente la pubblicazione di oggetti sul territorio e la loro gestione (percorsi, schede esplicative, ecc.).
La mappa dell’esempio guida lungo percorsi turistico culturali, e le tappe (nel caso specifico dei monumenti) sono collegate a giochi e indovinelli, col relativo punteggio. I markers, individualmente, possono avere comporta- menti dinamici (al click ingrandiscono la zona, centrano la mappa, …) e co- munque caricano la scheda dell’oggetto.
La grafica dei markers è libera, così come i comportamenti di ciascuno.
Una presentazione alternativa espone punti di interesse, mappe tematiche, eventi e altri filtri selettivi che individuano il contesto che inte- ressa in quel momento.
Sono sempre disponibili i servizi di Google Maps (geolocalizzazione, percorsi, altro).
Non ultimo gli utenti potranno fare foto e pren- dere appunti, che saranno catalogati nel repo-
sitory e resteranno a disposizione per qualche periodo. Gli abbonati (cfr. #11) conserveranno le loro memorie e, tra-
mite un servizio specifico, potranno sempre rivedere la loro visita corredata dalle proprie immagini.
Su queste opzioni si potranno innestare dei servizi, quali i reclami per il de- grado ambientale, delle funzioni sociali, e delle interazioni coi partecipanti a una visita.
➢ CARD: una scheda è un contenitore che espone i soggetti rilevanti per la APP secondo la o le grafiche definite dai modelli sottostanti.
Diverse tipologie di schede -per i POI, per gli eventi, per le categorie di eser- centi- definite attraverso il back office personalizzano le presentazioni; sono contenitori multimediali (cfr. #6, sezione ‘Back office) con tutti gli elementi per la caratterizzazione dell’oggetto, e le possibili azioni (telefonata, trasmis- sione email, chat, funzioni gestionali).
➢ GAMING/ALTRO: nell’esempio abbiamo collegato degli indovinelli alle tappe di un percorso, per offrire motivi di competizione e di interesse a certe categorie di utenti. In altri casi il tab potrà qualificare il servizio offerto: po- trebbe essere una scheda di prenotazione, oppure una chat, o altro ancora.
Gli elementi grafici della mappa (confini, percorsi, evidenziazioni) sono ‘dise- gnati’ con editor specifici, e tra questi Google My Maps.
‘Esperti’ e utenti finali possono creare specifici contesti, a disposizione della co- munità o di target predefiniti. Il caricamento è semplice.
3 Il progetto ha tre attori principali:
✓ Il pubblico in quanto fruitore e consumatore
✓ Associazioni ed enti come gestori del loro contesto in quanto innestato sul ter- ritorio.
Qualche soggetto potrà creare dei percorsi in una zona e qualificarli attraverso i ser- vizi offerti dagli associati in uno col contesto culturale in cui siamo immersi, pubbli- care i propri eventi e organizzarne di particolari.
L’Associazione potrà esporre la propria struttura organizzativa e le pagine degli asso- ciati, in uno coi servizi che offrono (prenotazioni, altro).
4
✓ Gli associati, e in specie gli esercenti e gli operatori professionali, disporranno di una miglior visibilità e potranno aggiornare in prima persona le loro schede.
I servizi del business saranno verticalizzazioni gestite dai partner che le hanno create.
--- Quanto sopra apre uno scenario di servizio.
Il cuore è un nucleo centrale, ragionevolmente contenuto (cfr. #8), che gestisce il data base e il repository, normalizza l’innesto di nuove tecnologie e garantisce l’ag- giornamento del software di base.
A lato c’è spazio per aziende e professionisti ICT 1.
E’ auspicabile la presenza di agenzie di comunicazione che potranno creare, con qualche beneficio, specifici progetti 2 oppure disegnare percorsi e mappe di inte- resse generale.
Serviranno organizzazione e regolamentazione (un ‘moderatore’).
1 Es: un e-commerce, meglio se centrale, e servizi ‘di prossimità’ per esercenti e professionisti.
2 Ad esempio potranno posizionare nel territorio gli eventi che gestiscono e, nei casi più importanti, fruire di APP-locali personalizzate sull’evento.
5 Come visto l’associazione o l’ente potranno pubblicare periodicamente i propri
eventi, esporre le schede degli associati e quelle di soggetti terzi e porgere una prima assistenza ai propri utenti.
Correderanno il sito con pagine addizionali incentrate sulla mappatura del territorio, quella dei propri servizi e le schede degli associati (le stesse che vengono esposte attraverso la APP-mobile).
Il back office consentirà di gestire agevolmente il prodotto sia da parte dell’associa- zione che dell’associato.
---
6 Tutte le informazioni devono confluire in un data base centralizzato, che rappresenta il reale patrimonio del progetto.
Tra l’altro molti contenuti, e in particolare i percorsi storici, i punti di interesse cultu- rale e molte mappe tematiche di interesse generale, saranno fruiti da tutte le asso- ciazioni e gli esercenti che insistono sul territorio.
Le informazioni che non sono strettamente personali devono essere immediata- mente accessibili e comprensibili, e questo comporta omogeneità e normalizzazione per l’intero data base.
Parimenti servono funzioni tipiche dei software ERP: tanti professionisti potranno proporre prodotti e servizi e questa gestione di primo livello deve essere semplice per l’esercente, e naturale per il pubblico.
Gestioni particolari saranno affidate a verticalizzazioni di terzi (modello ‘premium’).
---
Un progetto di normalizzazione, ‘CubicERP’ (cfr. nota 3), innesta le logiche tipiche della Business Intelligence (gli ipercubi e le gerarchie 4) su un data base relazionale classico e quindi individua le varie entità attraverso le loro coordinate piuttosto che la ricerca nelle varie tavole.
Quale estensione ulteriore le gerarchie del modello sono trasversali rispetto agli assi dell’ipercubo (le dimensioni nella nomenclatura canonica) e questo consente di ap- plicare tecniche di programmazione ricorsiva, quali quelle usate per la distinta base, all’intero spazio e ai vari livelli, che siano aggregati oppure entità elementari, piutto- sto che, ad esempio, ai soli prodotti a magazzino.
3 Il link diretto è http://www.metodologie.it/ProgettoCubicERP.pdf
4 Esempio: una categoria merceologica è una aggregazioni di prodotti (gerarchia a due livelli)
7 Le frecce che raccordano i nodi di gerarchie su di- mensioni diverse esprimono questo concetto: la navigazione è libera e trasversale; tutte le informa- zioni, semplici oppure aggregate, sono raggiungi- bili attraverso una solo modello.
Questa tecnica ad esempio consente di affiancare e raffrontare degli aggregati anche quando i dati di base hanno codifiche eterogenee.
--- Le gerarchie sono entità editabili, e possono ve- nire create ‘ad hoc’ per gli utenti: in questo modo ad esempio un esercente potrà elaborare delle of- ferte organiche gestendo una vista ad albero e re- cependo i prodotti e le immagini dalle loro loca- zioni, a prescindere dalle ‘dimensioni’ in cui sono state allocate all’origine.
---
La slide rammenta altre funzionalità importanti, in questo caso collegate al gestore del DBMS (cfr. #6, sezione ‘DATA BASE’):
- l’adozione simultanea di due linguaggi sui dati: SQL e la sua estensione pro- cedurale per l’aspetto relazionale, e JSON -la notazione del Web- per l’inter- faccia con la APP
- Strumenti di calcolo geografici e spaziali.
- Tecniche di programmazione ricorsiva 5, piuttosto che SQL ‘standard’
- L’esposizione dei data base ‘json’, locali per la APP, secondo due formati semplici (la tree-view classica e un array a due livelli)
La strumentazione fornita dal DBMS e la modellazione dei dati semplificano in modo essenziale la programmazione lato-server della APP.
---
L’innovazione rappresentata nel nucleo centrale potrà qualificare ulteriormente la partecipazione a un bando.
5 Per l’essenza il DBMS è un pool di tabelle ‘relazionali’ semplici, con una PK univoca, mentre i documenti com- plessi e meno rilevanti per l’architettura (indici e ricerche) vengono catalogati in campi ‘JSON’ articolabili libe- ramente. Una relazione trasversale collega tutte le entità e viene esaminata ricorsivamente per individuare la catena, o le catene, che portano all’elemento di interesse.
8 Alla base e come visto c’è un data base assimilabile a un data warehouse e in grado di supportare e normalizzare tutti i dati che servono.
Il back-office restituisce l’informazione attraverso un insieme di procedure del data base (‘store procedures’), ‘appoggia’ in un repository mappe e altre strutture ragione- volmente statiche, che saranno prelevate ed elaborate dalla APP, oppure interagisce direttamente e in tempo reale con la APP attraverso il framework-linguaggio node.js Altro modulo portante è il repository, cioè uno spazio sul server che contiene gli og- getti che saranno prelevati ed elaborati dalla APP: le immagini, i documenti, i data base ‘locali’ già visti; ricomprende anche gli spazi dei vari utenti che vorranno con- servare le informazioni personali.
Tutti gli oggetti del repository sono referenziati attraverso il data base.
TECNOLOGIA E INFRASTRUTTURA
La APP è/verrà sviluppata coi linguaggi e gli ambienti (‘framework’) allo stato dell’arte nel Cloud e nel Web: node.js, già visto, per le elaborazioni sul server e Ionic, supportato da Angular 6, per il back office e la APP mobile.
E’ ibrida secondo la nomenclatura corrente e quindi lo stesso programma può venire ‘compilato’ e funzionare su Android, su IOS e sugli altri sistemi.
Il repository è sui server di Google (Google Cloud-Google Firebase): questo perché i costi sono risibili finché la APP non raggiunge il successo (ad esempio 50 G/disco costano pochi Euro-mese, i primi 20.000 -più o meno- ‘click/giorno’
6 Angular è il framework-linguaggio progettato da Google, e presumibilmente è il più potente tra i competitors.
Ionic è un framework innestato su Angular e specializzato per le APP-mobile.
9 di Google Maps sono gratuiti, e così via), le APP sono sempre affidabili e ve-
loci, e non serve un sistemista per bilanciare periodicamente l’ambiente.
La scelta del server non è vincolante in assoluto 7.
Parimenti, e col giusto lavoro e competenze, i framework utilizzati per i moduli di base (Angular e Ionic) potranno venire affiancati da moduli sviluppati con altri lin- guaggi.
CLOUD
I grandi server offrono di servizi avanzati in tempo reale (chat, triggers, fino all’intelligenza artificiale); in caso di necessità problemi complessi o computa- zionalmente onerosi potranno venire risolti sul server e riportati al client senza che l’utente percepisca dei rallentamenti.
Quanto sopra potrà rilevare: ad esempio computazioni particolarmente onerose collegate al business di qualche categoria potranno venire risolte su un server, ed esperti in A.I. potranno sviluppare applicazioni specifiche per il pubblico e il data mining.
DATA BASE
DATA BASE: il data base è PostgresSQL, di classe entreprise e tra i più diffusi.
Quali peculiarità opera sia come base relazionale/SQL che con la notazione JSON, cioè quella fruita direttamente dalle APP sul Web, e risolve il calcolo spaziale e geodetico.
Queste opzioni, e l’adozione del linguaggio procedurale interno (PL/pgSQL) semplificano in modo essenziale la programmazione. Tra l’altro il DBMS può venire programmato nel linguaggio Phyton, ottimale per il calcolo numerico e la AI.
Una semplificazione ulteriore è fornita dalla normalizzazione del data base in forma ortogonale, e dalla programmazione ricorsiva (cfr. #5).
SCALABILITA’
Questa separazione, tra il back offiche che predispone gli oggetti e la APP-mo- bile che li elabora localmente, potrà garantire l’integrità e agevolerà la non-sca- labilità del sistema.
Infatti, ribadiamo, il codice cablato sulla APP-mobile elabora localmente le infor- mazioni predisposte attraverso il back office.
7 Il trasferimento del repository comporterebbe, quanto al software, la mera sostituzione del link di base, da https://storage.googleapis.com/ al nuovo riferimento.
10 Un competitor potrà creare un software concorrente solo ricostruendo l’intero
scenario (lato-server e lato-client), e non sarà semplice subentrare quando lo scenario sarà consolidato.
DATA BASE GEOGRAFICI
Molti data base geografici sono già disponibili liberamente e, con un impegno ragionevolmente moderato (pulizia, cambio di formato, omogeneità nelle codifi- che) potranno venire catalogati nel data base e fruiti liberamente per le rappre- sentazioni sul territorio.
Ad esempio ISTAT pubblica i confini di Comuni, Provincie e Regioni, SAT (So- cietà Alpinisti Tridentini) i sentieri del Trentino, e molto altro è in rete 8.
La catalogazione organica di queste mappe agevolerà le rappresentazioni sul territorio.
Potrà venire seguita da qualche esperto.
BACK OFFICE
Di seguito schematizziamo il lavoro in corso. Le prime transazioni riguardano:
Gestione utenti Alimentazione del repository
Schede di presentazione/servizio IN SVILUPPO:
schede-contenitori spe- cializzati per categorie e gestiti dal diretto inte- ressato
✓ Gestione Utenti, riservata alla fruizione (es: le pagine visitate) e alle azioni (es: i markers cliccati, i siti visitati). La traccia autorizzata delle azioni consentirà di rico- struire l’essenza di una visita e riportarla agli interessati.
✓ Alimentazione del repository:
immagini, documenti ed entità geografiche (files .kml) sono ottimizzati per il cari- camento; ad esempio le immagini dispongono di un formato per le iconcine e di altri per definizioni più puntuali.
Tutte le entità sono referenziate nel data base coi loro elementi descrittivi e, fin- ché possibile, riportano le coordinate del luogo.
8 Un articolo è al link http://www.datajournalism.it/ecco-i-dati-geografici-per-costruire-mappe/
11 In questo modo potranno venire organizzate in albi o espositori che a loro volta qualificheranno le schede dei luoghi e degli operatori.
✓ Schede per la presentazione dei soggetti.
Si tratta di modelli con un tracciato generalizzato (un titolo, un abstract, l’imma- gine principale, l’indirizzo, …, liste di ‘diapositive’ e allegati multimediali, fino all’innesto di un mini sito -una pagina .html completa- per le presentazioni più qualificate.
Questo pool di modelli (per i siti storico-culturali, per gli eventi, per le peculiarità di qualche categoria, ecc.) semplifica il caricamento delle schede individuali
---
All’atto pratico la APP riceve degli oggetti che seguono standard predefiniti e li elabora localmente innestando le regole del business.
La presentazione di base è omogenea, la complessità (e quindi, se del caso, il ri- corso a una suite di APP-mobile e/oppure a elaborazioni nel cloud) potendo risie- dere soprattutto nelle regole dei vari business.
12 Il cliente primario è il cittadino-turista e comunque il visitatore di una zona, e poten- ziale fruitore dei servizi del territorio.
Questi saranno seguiti e customizzati dalle associazioni e dagli operatori interessati, in uno con professionisti e aziende ICT e qualche categoria specializzata; tra queste le agenzie di comunicazione (cfr. #2).
Un nucleo centrale dovrà garantire l’integrità del sistema, ma molto lavoro originerà e verrà risolto sul territorio.
Questo modello comporta una crescita logistica, con un massimo correlato alla satu- razione del-delle categorie già avviate; il prolungamento della crescita può avvenire attraverso l’innesto di nuovi servizi, con la miglior fidelizzazione derivante da questo approccio, e con l’avviamento di nuove categorie.
Il modello di crescita rappresentato nell’istogramma è ripreso da #9, e tiene conto di uno scenario competitivo.
13 Si ribadisce il concetto di #7: molti benefici potranno essere indiretti, e riversarsi sul territorio.
In tutti i casi un nucleo centrale dovrà autofinanziarsi e generare reddito mantenendo una struttura qualificata ma ragionevolmente contenuta.
14 La tabella rappresenta un campionamento delle associazioni in tre provincie rappre- sentative (Bologna, Milano e Modena).
I canoni mensili ipotizzati sono solo dei riferimenti; in tutti i casi la marginalità poten- ziale è significativa.
In particolare l’impianto (l’unico costo una-tantum) è semplificato dal fatto che le as- sociazioni dispongono dell’anagrafe dei loro associati, e il procedimento potrà venire ingegnerizzato.
---
PS: nelle ipotesi di questa tabella l’associazione che acquisisce il servizio può abili- tare ai servizi della APP i propri associati, fatta salva la componente premium (es:
royalties sul venduto). In questo senso non è direttamente sovrapponibile a #10.
In tutti i casi il pricing di queste slides è un mero indicatore.
15 Abbiamo rapportato la simulazione alla categoria più importante (le micro aziende dell’agricoltura); con canoni moderati (Euro 100/anno) e un tasso di acquisizione tranquillo (meno dell'uno per cento al IV anno) il beneficio atteso si misura in milioni di Euro.
Per contro tante microaziende riceverebbero benefici essenziali potendo esporre al pubblico i prodotti caratteristici nella loro stagione e mostrare il percorso per la fatto- ria in prossimità di sagre e fiere.
Quale ‘attrattore’ nella slide abbiamo ipotizzato la mappatura dei campi, semplice e graficamente gradevole su un dispositivo mobile (campo A: ettari …, campo B: …);
se ne può derivare un piccolo budget, qualche raffronto con lo storico e qualche inte- razione strutturata coi conferitori e la propria associazione.
In tutti i casi la scelta è ampia.
---
Per altre categorie, con numerosità di gran lunga inferiori, valgono considerazioni as- similabili nel rispetto delle specificità di ciascuna.
In molti casi potranno bastare i moduli di base quali l’offerta del prodotto-servizio e una forma di comunicazione col potenziale cliente, in uno con soluzioni ‘premium’ di partner che già ne possiedono.
16 Come opzione, appunto ‘Premium’, il fruitore finale (tipicamente un privato) potrà di- sporre di una tracciatura più precisa 9 e trasferire sul server foto e filmati, annotazioni e quant’altro collegato alla propria visita: ad esempio eventuali chat e le fasi dei gio- chi sul territorio oltre che, volendo, comunicazioni o quant’altro potrà interessare.
Le mappe e le schede del territorio in uno con le informazioni personali permette- ranno di ricostruire la visita e dare continuità, se del caso, al gaming e alle chat.
---
Il pricing potrà essere moderato, e il trend atteso riguarda una crescita stabile e con- tinua.
9 Si ipotizzano ad esempio una geolocalizzazione in continuo e l’uso del contapassi per la traccia del percorso.
