Portal development frontend

ultimo aggiornamento ottobre 2016

Spunti per il design del widget di discovery del portale

Panoramica

Allo scopo di conoscere i principali meccanismi utilizzati ad oggi per l’accesso ai cataloghi di dati con componenti geografiche, sono stati visionati diversi portali e sistemi di ricerca via web.

I principali spazi dedicati all’ accesso ai cataloghi (o a generici archivi) sono:

strumenti di ricerca su pagina web generica (spesso link e spazi “search” sulla homepage o su pagina di alto livello gerarchico)
interfaccia di ricerca complessa (avanzata) su pagina dedicata
maschera di ricerca integrata al catalogo
maschera di ricerca integrata in un map-viewer

I meccanismi di ricerca più frequentemente proposti sono:

ricerca testuale semplice (linguaggio naturale)
ricerca incrociata/faceted “what, where, when”
ricerca incrociata per categorie/faceted (tema, provider, formato, licenza, …)
ricerca per catalogo o servizio
ricerca geografica (bbox o selezione area o geocoding)
selezione da un elenco (indice alfabetico o ordinato per numero visualizzazioni, data, …)
selezione da un set di tags (o di categorie ordinate gerarchicamente)
selezione da un set di layers o mappe mostrati in un carousel
con recupero dati da sessione di lavoro precedente o salvata

Solitamente più meccanismi vengono proposti nella stessa pagina, come alternative o in sequenza progressiva per un affinamento della ricerca.

Di seguito sono riportati una serie di esempi riferiti alle casistiche prima elencate, corredati da alcuni commenti.

ricerca testuale semplice (linguaggio naturale)
Inspire geoportal: [1] (fig 1a)
CSIRO data access portal: [2] (fig 2a)
Dati.gov.it: [3] (fig 3a)
Open Data del Comune di Milano: [4] (fig 4a)
European Union Open Data Portal: [5] (fig 5)
Presente su quasi tutte le homepage o pagine principali di indirizzamento ai repositories. Utile perché intuitivo, ma solo se i termini cercati corrispondono effettivamente ad almeno uno dei campi dei metadati (ad esempio alla ricerca di “acqua” sfuggiranno i dati registrati come “water”).
Si può pensare di adottare con l’ausilio di un auto completamento o menù a tendina o una compilazione assistita.

ricerca incrociata “what, where, when”
geoportale Regione Piemonte: [6] (fig 6)
Deims repository (discovery): [7] (fig 8b)
Moltissime opzioni per raffinare la ricerca a partire dal semplice “cosa, dove, quando”: almeno una parola, frase esatta, titolo, …, bbox, coordinate, compreso in, intersecante, …, periodo modifica metadato, estensione temporale dato, …
Ai 3 criteri di ricerca sono spesso affiancati altri: tema Inspire, tipo di risorsa, ambito, …
E’ la ricerca standard adatta a interfaccia web (scrittura con tastiera e schermo ampio) e a ricerche mirate in cui l’utente già conosce i contenuti del repository.

ricerca per catalogo o servizio
geoviewer ISPRA: [8] (fig 13)
geoportale nazionale: [9] (fig 9)
Opzione doverosa nel caso di cataloghi confederati, può essere utile anche per filtrare la ricerca dell’utente Ritmare per nodi, o per filtrare i servizi sos dai wms-wfs-wcs. Può rientrare tra le opzioni di una faceted search.

ricerca incrociata per categorie – faceted search (tema, provider, formato, licenza, …)
deims repository: [10] (fig 8b-c)
the shift project data portal: [11] (fig 11)
Open Data del Comune di Milano: [12] (fig 4b)
Geoportale Regione Lombardia: [13] (fig 10)
Meccanismo molto frequente su repositories ampi. Occorre riflettere su quali categorie includere nella ricerca per ottimizzare le possibilità di scelta minimizzando la complessità (e lo spazio necessario sullo schermo)

ricerca geografica (bbox o selezione area o geocoding)
CSIRO data access portal: [14] (fig 2d)
the world bank group climate change knowledge portal:[15] (fig 7)
geoportale nazionale tedesco: [16] (fig 12)
La selezione può avvenire con diversi meccanismi, visibili negli esempi: tracciamento area su mappa (comodo solo con uso del mouse), scrittura coordinate (preciso ma cavilloso), click su area pre-settata (intuitivo ma limitante), scrittura di un termine avente riferimento geografico (da ricercarsi nel metadato, su gazetteer esterno, con strumenti di geocoding ecc).
A mio avviso, mentre per la modalità di ricerca via web si potrebbe adottare il tracciamento di bbox su mappa, per la modalità touchscreen potrebbe essere proposto un set di bbox (ad es Europa, Italia, ogni singola regione) da selezionare con click su mappa (come nell’esempio della world bank) e corredato dalle opzioni “compreso in”/”intersecante”. Gli strumenti di ricerca testuale per poter essere efficaci devono essere corredati da un raggio di ricerca, poiché la località digitata non necessariamente si può trovare all’interno del metadato o in un gazetteer (ad es pensare ai punti a largo e alle boe).

selezione da un elenco (indice alfabetico o ordinato per numero visualizzazioni, data, …)
Inspire geoportal: [17] (fig 1b)
European Union Open Data Portal: [18] (fig 5)
deims repository: [19] (fig 8c)
A mio parere una tra le modalità di selezione meno utili nell’economia dello “spazio widget”. Potrebbe avere senso invece come utilizzo dei log di sessione, proponendo (in un elenco o con delle preview) gli ultimi dati visualizzati dall’utente.

selezione da un set di tags o categorie gerarchiche
Inspire geoportal: [20] (fig 1a)
Dati.gov.it: [21] (fig 3b)
European Union Open Data Portal: [22] (fig 5)
Includo in questa modalità non solo I tag-cloud, ma anche le soluzioni che permettono di individuare graficamente categorie e termini di particolare rilievo, perché, ad esempio, associate ad aree di maggiori dimensioni in un grafico o una torta (vedi fig 3b).
Differisce dalla selezione per categoria soprattutto per l’ordinamento gerarchico, che può seguire diversi criteri: termine più richiesto, tema più ricco di dati, tema consigliato per l’utente, …
La modalità è adatta ad un uso da touchscreen. Può anche essere abbinata ai log di sessione o al profilo utente.

selezione da un set di layers o mappe mostrati in un carousel
geoportale nazionale: [23] (fig 9)
the world bank group climate change knowledge portal:[24] (fig 7)
geoportale nazionale tedesco: [25] (fig 12)
Molto efficace visivamente perché offre una preview del layer, o del servizio o della mappa. Può essere utilizzato per una selezione rapida o per recuperare dati salvati o provenienti da sessioni di lavoro precedenti. Lo spazio che occupa sullo schermo è tuttavia un limite, per cui bisogna riflettere se utilizzarlo sul widget mappa, sul widget discovery o come widget a sé stante.

con recupero dati da sessione di lavoro precedente o salvata
geoviewer ISPRA: [26] (fig 13)
geoportale nazionale: [27] (fig 9)
Può essere molto utile poiché è probabile che gli utenti del portale utilizzino con alta frequenza set ridotti di dati e composizioni degli stessi. Il recupero di dati da sessioni precedenti o da salvataggi può avvenire nel widget di discovery, sul widget mappa o anche su widget a sé stante.

Considerazioni e spunti di lavoro

Molti portali adottano una discovery a passaggi: una prima ricerca (ad es per categorie tematiche) conduce a una selezione di risorse che possono essere filtrate nuovamente (ad es per tipologia/formato di dataset) e così passo passo la ricerca si raffina fino al singolo strato informativo. Tale modalità di ricerca ha il grande pregio di offrire una visualizzazione adatta a piccole aree dello schermo, e secondariamente quello di guidare l’utente verso risorse e archivi noti, ma deve essere studiata attentamente nella sequenza di passaggi e nelle modalità proposte per il filtering, allo scopo di non creare confusione e non porre all’utente “domande” a cui non sa rispondere.
Un primo passaggio del widget di discovery potrebbe smistare le ricerche tra le due modalità principali faceted search (what, where, when + eventuali provider, data type) e filtering progressivo (ad es ricerca per macroarea > tema > estensione geografica > … > elenco datasets ). La prima modalità è adatta a ricerche mirate a ad un utilizzo del portale via web. La seconda è adatta ad un utilizzo da touchscreen e deve avere grafica semplificata (ad es uso di icone, tags, diagrammi, … ).
La selezione di una risorsa dal widget di discovery deve essere accompagnata da una preview del metadato. La preview deve sintetizzare, anche con utilizzo di icone, le informazioni principali contenute nel metadato: titolo, parole chiave, istituto fornitore del dato, estensione geografica.
Si può pensare di organizzare queste informazioni con un xml editor collegato al metadato (ad es il portale Inspire utilizza ALTOVA).
Da valutare se lo spazio dedicato al metadato viene ritagliato all’interno del widget o viene aperto in un altro widget.
Il widget di discovery deve fornire un sistema per collegarsi al widget mappa (ad es un tasto “visualizza layer su mappa”, o la possibilità di trascinamento, ecc. ).
Valutare se creare un widget separato, collegato ai widget mappa e discovery, per il recupero di dati/mappe o sessioni di lavoro o per il salvataggio di progetti. La modalità di selezione potrebbe essere attraverso preview delle risorse (es fig 9).

La documentazione tecnica che ha guidato lo sviluppo del portale è disponibile ai seguenti indirizzi:

Immagini

1a.png

1a
1b
2a
2b
2c
2d
3a
3b
4a
4b
5
6
7
8a
8b
8c
9
10
11
12
13.png

13

Confronto GeoNode/C-KAN

Tra gli strumenti per effettuare l’organizzazione e la distribuzione delle risorse, molto utilizzato è CKAN (o la versione per php e drupal DKAN).
Di seguito sono elencati strumenti per la creazioni di portali di accesso adatti a Open Data con relativi esempi. Sono riportati anche due link utili e una matrice per la conoscenza e il confronto tra le tecnologie.
Portale open data con CKAN: [28]
Portale Open Data con DKAN: [29]
Portali con Socrata (cloud-based SaaS Open Data catalog platform): [30] [31]
Portale con Swirrl (cloud-based SaaS Open Data platform built on linked data technologies): [32]
Esempi di open data platforms e modelli di open data catalogs: [33]
[Confronto tra Open Data portals]: [34]

Product (Technology)	Vendor/ Sponsor	Delivery Model	Data Management	Support Community
CKAN (Python)	Open Knowledge Foundation	Open Source (cloud hosting available)	All-in-One or Federated	Python developer community
DKAN (PHP/Drupal)	Nuams	Open Source (cloud hosting available)	All-in-One or Federated	Drupal developer community
Junar	Junar	SaaS	All-in-One	Vendor
OGPL (PHP/Drupal)	Funded by Gov. of India & Gov. of U.S.	Open Source	All-in-One or Federated	Drupal developer community
Socrata		SaaS	All-in-One or Federated	Vendor

Un confronto interessante tra tecnologie si può attuare sul sistema C-READ.
Il sistema è costituito da diversi moduli open source. Ne fanno parte un presentation node (hub) basato su CKAN (http://ckan.c-read.net/ ) e un data node implementato con geonode ( http://geonode.c-read.net/).
L’hub (CKAN) è la principale interfaccia di accesso ai dati per gli utenti e attua un harvesting tra cataloghi differenti (che usino un protocollo CSW o APIs CKAN o altro), ma non consente all’utente di caricare i propri dati né di intervenire per modificare quelli esistenti.
Il data node (geonode) al contrario gestisce il principale set di dati e relativi metadati, li offre tramite OGC web services, ne consente l’upload e la modifica.
L’hub CKAN propone sulla homepage una prima scelta per categoria (land cover, water, emergency, …), realizzata graficamente con grandi icone che riportano il numero di dataset corrispondenti. Dalla home è anche possibile fare una ricerca attraverso testo libero (vengono proposti alcuni tags). Una volta effettuata la prima selezione, le risorse corrispondenti vengono visualizzate in un elenco ordinato (per rilevanza, alfabetico, ultima modifica), sintetizzate dai principali metadati (titolo, abstract, categoria) e da un thumbnail. Le risorse sono pdf, wms e csw. Per ogni layer geografico è possibile chiedere una preview o il caricamento su mappa (viewer Map Store). Ogni layer può anche essere scaricato in diversi formati. Si può visualizzare anche l’activity stream dei dataset selezionati. Sulla colonna di sinistra sono disponibili numerose opzioni per l’affinamento della ricerca (data provider, categoria, tag, formato, licenza)

C-KAN home
C-KAN resources

Geonode propone un primo filtro tra layers, mappe e documenti già nella homepage. La ricerca tramite testo libero è a compilazione assistita. Geonode consente poi su ogni altra pagina di affinare la ricerca incrociando diversi criteri (what, where, when, free text, categories, data type, keywords). Le risorse che si confanno alla ricerca vengono visualizzate in un elenco ordinato (più recente, ordine alfabetico, o più popolare) con una preview del metadato (thumbnail, titolo, categoria, provider, abstract, data di creazione, rating e utilizzo risorsa). Ogni risorsa geografica può essere scelta per creare una nuova mappa da personalizzare ed eventualmente salvare. La differenza principale da CKAN sta nella possibilità per l’utente, tramite login, di intervenire su dati e metadati, facendo nuovi upload o modificando l’esistente.

GeoNode home
GeoNode explore layers

	C-KAN	GEONODE
faceted search	x	x
manage uploading		x
edit permissions		x
support commenting		x
support mapping	x	x
generate charts
sorting options	x	x
rate datasets		x

Spunti per il design del widget di mappa del portale

Strumenti utili

Interessante lo strumento “duplica mappa” (affiancata/continua) del geoportale nazionale (fig 9).

Piattaforme, viewer, tools e librerie

Strumenti Open Source già noti e testati dai ricercatori di SP7 per la pubblicazione di risorse geografiche e web services secondo gli standard internazionali (ISO, OGC, INSPIRE) sono GeoServer, MapServer, GeoNetwork e la piattaforma GeoNode (con viewer costruito in OpenLayers, GeoExt). Ad esse si affiancano i molto usati strumenti server e client della ESRI (proprietario ma con moduli free).

il Sistema Oskari [35]consente di costruire applicazioni di web mapping utilizzando SDIs distribuite, secondo il modello INSPIRE. Il codice è rilasciato con licenza Open Source (MIT/EUPL). Oskari si basa su componenti Open Sources come OpenLayers, GeoTools, GeoServer, Jackson e jQuery. Oltre a dati spaziali, consente la visualizzazione e l'analisi di dati statistici. Oskari è estensibile e flessibile: diversi bundles (gruppi di classi) e plugins possono essere utilizzati e aggiunti sia al lato client sia al lato server, e le application libraries possono essere cambiate. Consente di gestire WMS e WFS, mentre va verificato come gestirebbe WCS e SOS. Ulteriori informazioni alla pagina [36] e nella sezione documentazione. Il geoportale finlandese utilizza la versione piùà recente di Oskari [37]

Geonorge [38] è il geoportale norvegese, da cui si accede al viewer [39] e ad un catalogo che ha modalità di visualizzazione interessanti[40]. Il viewer ha funzionalià base e uno stile essenziale molto gradevole. Tutto il portale è in norvegese ed è difficile trovare informazioni sui componenti e sull'architettura. Potrebbe essere stato sviluppato exnovo dal servizio cartografico nazionale.
Il geoportale del Lussemburgo [41] è interessante sotto diversi aspetti: funzionalità, grafica, interazione tra strumenti e finestre. In particolare offre accessi personalizzati a diverse categorie di dati (professionisti, turisti, ...). La stessa personalizzazione e "user-friendlyness" è presente nel viewer (il nuovo viewer dall'aspetto davvero accattivante, ha sostituito la vecchia versione di tipo OpenLayers classico)[42]. La disposizione degli strumenti di mappa e la loro interazione col catalogo è originale a mio giudizio ben riuscita. Il geoportale indirizza anche ad una serie di strumenti collaterali al viewer: un mini-portale per i dati INSPIRE (con strumenti di search e un viewer ESRI), le app del geoportale, la map API, strumenti di routing stradale, calcolo distanza, geocoding,... oltre che al catalogo. Il geoportale offre anche accesso a una wiki che funziona da userguide ma non dà informazioni architetturali o sulle tecnologie usate.

Il Geoportale spagnolo [43] ha un accesso ai dati nazionali-regionali-locali molto intuitivo dalla home. Ha un viewer [44] con funzionalità base che probabilmente è stato sviluppato ad hoc. Gestisce solo WMS, ha una disposizione degli strumenti potenzialmente interessante ma è limitato per efficacia e intuitività degli strumenti (velocità, collegamento tra dato e metadato, interrogazione dei layers, ...)
Una lista di geoportali è all'indirizzo [45]
Un confronto più dettagliato tra i map viewer nminati è alla pagina wiki Geoportali

OpenGeo Suite [46] è una piattaforma open per la gestione e la visualizzazione di geodati per web e mobile. Costruita dalla Boundless con PostGIS, GeoServer, OpenLayers, qGIS, interagisce anche con altri DBMS, gis e server di mappe. Gestisce wms, wfs, wcs, wps, sld, gml, kml.

MapBox [47] offre prodotti free e non per la creazione, personalizzazione e visualizzazione di mappe (piattaforme, client, APIs, SDKs, per web e mobile, android e iOS), condividendo parte del codice su github. Da verificare l'interoperabilità e la gestione di servizi OGC. MapBox Studio ha rilevato anche l'applicazione TileMill [48], dedicata alla creazione e persolnalizzazione di mappe (da considerare, almeno per la grafica accattivante)
Mapbender [49] è un framework (back office software e client) per SDIs, basato su Symfony2, JQuery e OpenLayers; utilizza PHP e JavaScript con licenza MIT e interagisce con map services OGC (anche SOS??). E' un progetto ufficiale dell'Open Source Geospatial Foundation. Molto utilizzato in Germania, ne è un esempio il portale in fig 12.
Geozilla [50] è un semplice wms browser OpenSource.
OpenGeo Suite [51]
OpenLayers [52] è la libreria JavaScript più nota e utilizzata per applicazioni web con contenuti geografici.
Leaflet[53] è una libreria JavaScript molto leggera, utilizzata in mapping applications su web e mobile.
Modestmaps [54] è una libreria open ed estremamente leggera per creare applicazioni di mapping interattive.
GeoEXT [55] è un toolkit JavaScript che riunisce le funzionalità di OpenLayers e del framework EXT JS
D3 [56] è una libreria JavaScript che fornisce molte funzionalità per visualizzare, manipolare ed analizzare geodati e per lavorare con le proiezioni geografiche.
Mapael [57] è una libreria jQuery library per visualizzare geodati vettoriali su mappa.
Cesium [58] è una libreria open JavaScript specifica per virtual globes ma utile anche per mapping applications 2D, web e mobile. Un demo a tema acquatico al link [59]
AmMap [60] è una map library HTML5, con versioni free e commerciale.
jQuerygeo [61] è un plugin jQuery open source che fornisce una API JavaScript per la creazione di mappe.
GeoPrisma[62] è una applicazione compatibile con OpenLayers per gestire l'accesso ai dati e alle mappe (permessi, login...). Fornisce anche una serie di widget per il querying, il filtrering, lo zoom e altre funzionalità
Stamen[63]
Mapstraction[64]è una libreria Javascript che offre un'interfaccia unica per molte APIs di mapping Javascript (supporta le principali mapping APIs: CloudMade, ESRI ArcGIS, Google – v2 and v3, Leaflet, MapQuest and MapQuest Open, Microsoft Bing – v6 and v7, Nokia Here, OpenLayers, Ordnance Survey OpenSpace, Nokia Ovi, Yandex).
Polymaps[65] è una libreria JavaScript per image-based web maps, particolarmente mirata a offrire visualizzazioni alternative e rapidità negli zoom.
Tra i web tools utili a creare web map applications (alcuni sono nati per abbinarsi a MapServer e va verificato come interagiscono con altri server) si nominano: CartoWeb [66], Dracones [67], Fusion [68], GeoMoose [69], ka-map [70], MapFish [71], i3geo [72], HSLayers [73].
MapQuery è un plugin per creare mapping applications su web o aggiungere semplici mappe a pagine preesistenti [74].

Implementazioni e client SOS

vedi anche pagina SOS client development

Poichè il widget mappa dovrà consentire la visualizzazione di servizi WMS, WFS, WCS insieme a servizi SOS, si rende necessaria una panoramica di implementazioni, software e librerie che sono state utilizzate per creare client di SOS (N.B. lo standard SOS definisce il servizio ma non l'implementazione).
Alcune implementazioni SOS open source sono:

implementazione in Java di 52°North [75]
implementazione in Java SOS con il framework deegree della compagnia lat/lon: informazioni[76] e demo (viewer OpenLayers) [77]
implementazione in C in MapServer [78]
implementazione in Java, Perl e Python nel progetto OOSTethys[79]
implementazione in Python come istSOS: informazioni [80] e demo (senza viewer) [81]
implementazione di CSIRO [82]

Una ulteriore implementazione di SOS proprietaria è al link [83]

Una review di SOS client si trova al link [84]

Un esempio basico di map viewer OpenLayer connesso a un SOS è all'indirizzo [85]

Il client utilizzato dalla 52° north e noto come sos-js [86] è probabilmente il più diffuso per ricercare e visualizzare su mappa osservazioni provenienti da sensori. Una sua implementazione arricchita, pur con una veste grafica elementare, è attiva al link [87]. Qui è possibile effettuare una selezione di sensori a partire da una mappa o all'interno di una lista (offering), scegliere il parametro di interesse (observed properties) e visualizzarne l'andamento nel tempo su tabella o plot. La finestra temporale può essere modificata e più registrazioni possono essere sovrapposte graficamente. I dati sono disponibili per il download.

Client comprensivi di map viewer costruiti con software ESRI e implementazione 52°north sono quelli del NOAA, ad es [88] e [89]
Sono stati sviluppati un plugin (in phyton) e un modulo (chiamato gvSOS) per abilitare rispettivamente qGIS e gvSIG a funzionare da SOS client. Plugin qGIS[90] articolo che presenta gvSOS [91]. Lo stesso gruppo di sviluppatori di gvSOS (Alain Tamayo, Pablo Viciano, Joaquin Huerta, Laura Diaz, Carlos Granell, Ricardo Quiròs, principalemte della Universitat Jaume I ) ha creato anche un client SOS per sistemi mobile Android (File:Sensor Observation Service Client for An.pdf)
Il progetto Briseide ha prodotto una suite che da accesso su mappa ai servizi OGC WMS, WFS, WCS, SOS, CSW, OLS, WPS. La suite (client/server) si basa interamente su stumenti Open Source (postgis, geoserver, geonetwork, 52°north, pgrouting, NASA WorldWind, uDIG) e può essere installata in un unico pacchetto o per moduli (da verificare) al fine di integrarsi con tecnologie preesistenti. Informazioni alla pagina [92]). Il coordinatore di Briseide era GraphiTech, che commercializza il prodotto Geobrowser 3D, il quale ha ereditato le funzionalità studiate in Briseide, in particolare il supporto ai diversi servizi OGC, compreso SOS. Esempi di utilizzo del geobrowser 3D alla pagina [93]. Geobrowser 3D ha anche la sua mobile app
Il progetto Cross-Fire ha prodotto un SOS client. Informazioni nelle pubblicazioni [94].

Il progetto eENVplus offre una serie di componenti per creare SDIs e applicazioni secondo la dir. INSPIRE. Al sito [95] si trovano esempi applicativi, informazioni e pilot applications dei vari "pacchetti". In particolare l'applicazione di air Quality al link [96] utilizza un SOS. Il SOS usa l'implementazione e il web client della 52°north. Il web client si trova al link [97] e il mobile client al link [98]. Esiste anche un client molto semplice creato con MapStore (GeoServer, OpenLayers,...) che credo integri WMS e SOS al link [99]

PlanetOS[100]
pubblica dati e metadati climatologici col suo THREDDS Data Server (TDS), attraverso OPeNDAP, OGC WMS e WCS, HTTP, e altri protocolli. Nella versione free non esiste un vero viewer per sovrapporre o confrontare layers o caricare servizi esterni.

Il progetto COLABIS (iniziato nel 2015 dura 3 anni) vuole creare una piattaforma che fonda dati da sensori, da crowdsourcine, cartografia ufficiale e geosimulazioni per finalità di urban early warning. Per farlo ha implementato tre prototipi, rispettivamente dedicati alla gestione dei dati, al catalogo delle risorse (con CKAN) e all'accesso ai dati da sensore (con la 52° North Sensor Web REST Proxy API ). Informazioni di dettaglio qui [101] e accesso al client sos, con map viewer leaflet, qui [102].

CO-OPS NOAA IOOS mette a disposizione una interfaccia che guida nella formulazione di GetObservation requests [103]
Terenovisualizza sul suo sito le ultime registrazioni da sensore e permette di variare la finestra temporale (ma l'utilizzo degli strumenti, per quanto basici, è molto poco comprensibile) [104]

Spunti per il design di altri widget

Valutare se creare un widget separato, collegato ai widget mappa e discovery, per il recupero di dati/mappe o sessioni di lavoro o per il salvataggio di progetti. La modalità di selezione potrebbe essere attraverso preview delle risorse (es fig 9).
Valutare se dedicare un widget alla visualizzazione degli utenti on-line e alla eventuale comunicazione con loro (via chat, via mail, via skype, …)

Meetings