Interface ramblings

Finalità

Scopo di questa pagina è raccogliere e dare forma, se possibile, alle riflessioni riguardanti l'interfaccia del portale RITMARE. La pagina è suddivisa nelle seguenti sezioni:

• • Struttura dell'interfaccia.
  • Soluzioni software (librerie) in grado di realizzare la precedente.
  • Lista dei widget
  • ...

Il workflow che si cerca di realizzare è il seguente:

1. Individuare le caratteristiche salienti dell'interfaccia. Ad esempio, si vorrebbe:
   • Presentare a utenti di profilo differente (ovvero con finalità presumibilmente diverse) una interfaccia personalizzata. Ad esempio, un utente interessato alla visualizzazione di dati sulla biodiversità nella laguna veneziana potrebbe trovare l'area dell'interfaccia dedicata alla mappa già focalizzata sull'area e, nell'area relativa ai data set disponibili, trovare elencati quelli che sono stati classificati secondo il tema di INSPIRE "Species distribution". Abbiamo identificato due direttrici per la personalizzazione dell'interfaccia:
     • L'insieme di servizi offerti (ai quali ci si riferirà d'ora innanzi come "widget", potendo questi assumere all'interno dell'interfaccia una posizione e un'aspetto variabili).
     • Le risorse che sono elencate all'interno di essi al momento dell'accesso al portale.
   • Realizzare un portale estremamente user-friendly che si distingua dai geoportali tradizionali, oltre che per i contenuti, per una curva di apprendimento meno ripida.
2. Selezionare una libreria software che consenta di realizzare quanto concluso al punto precedente e con essa costruire una generica "gabbia" per i contenuti con la quale sia possibile testare la parte di personalizzazione dell'interfaccia riguardante tipologia e disposizione dei widget.
3. Aggiungere, man mano che vengono prodotti, i vari widget all'interfaccia in modo che restino indipendenti tra loro (accessibili cioè come applicazioni distinte) e indipendenti rispetto alla posizione che, di volta in volta, andranno ad assumere nell'interfaccia. Questo comprende:
   1. Realizzazione del widget stesso.
   2. Correlazione del widget con le aree di ricerca di RITMARE in modo da consentire la personalizzazione dell'interfaccia.
   3. Creazione di un bus (verificare analogia con la nozione di "portal controller") che colleghi i differenti widget in modo che sia possibile, ad esempio, selezionare un elemento nel "widget dati" per il suo utilizzo nel "widget workflow".
4. Popolare l'infrastruttura di dati e servizi correttamente metadatati in modo da poter essere associati alle aree di ricerca di RITMARE.

Struttura dell'interfaccia

Il requisito principale dell'interfaccia è quello di non prevedere un layout statico. A parte definire una "griglia" di base (in un secondo momento si possono anche ipotizzare griglie alternative), ciascuno dei widget ospitati da essa deve potersi adattare ad ognuno dei box previsti dalla griglia ottenendo un aspetto gradevole. Dal punto di vista del design del layout, questo rappresenta una challenge non indifferente che richiede la scelta di criteri appropriati per la formattazione dei contenuti in ognuno dei widget. Due possibili alternative (lista non necessariamente esaustiva delle possibilità) sono le seguenti:

• Formattare i contenuti in modo che appaiano nella maniera desiderata nel box principale dell'interfaccia. L'adattamento dei contenuti alle dimensioni di un box differente avviene attraverso il ridimensionamento degli elementi (immagini, testo, ecc.).
  • PRO Non e' necessario studiare layout per ognuno dei box dell'interfaccia.
  • CON L'effetto grafico risultante potrebbe non essere il migliore perchè mescola testo di dimensioni differenti.
• Mantenere i contenuti invariati per quanto riguarda le dimensioni di immagini e testo ma organizzare i contenuti in modo che "scorrano" liberamente nello spazio che, di volta in volta, avranno a disposizione.
  • PRO Un effetto grafico probabilmente migliore.
  • CON Maggiore difficoltà nel CSS associato ai contenuti.

In ambo i casi, la presenza di box con caratteristiche differenti (es. più alto che largo vs. più largo che alto) potrebbe complicare le cose.

Soluzioni software

• Interfaccia: possibili soluzioni possono essere
  • Sencha Border
  • Sencha Anchoring
  • Sencha Portal

Lista dei widget

Amministrazione:

• Box autenticazione
• Accesso federato (SSO)
• User preferences

Discovery:

• Campi ricerca
  • WHO
    • selezione da utenti Ritmare
    • inizializzato con l'utente corrente
    • checkbox "ricerca non profilata"
  • WHAT
    • selezione da lista parametri
    • quick list "favorites" con parametri attinenti al profilo
    • elemento obbligatorio
  • WHERE
    • selezione da gazetteer
    • quick list "favorites" con ultime bounding box selezionate
    • elemento obbligatorio
  • WHEN
    • doppio slider per definire l'intervallo di tempo
    • inizializzato con periodo di default (es. ultimo mese)
    • tre slider che permettono la scelta di scale differenti
• Discovery dati (quali operazioni possibili su di essi, es. applicare un servizio al dato).
• Visualizzazione dati
• Discovery servizi (quali operazioni necessarie al lor utilizzo, es. scelta dei dati di input).

Note:

Si riesce ad appianare la dicotomia dati-servizi? Ovvero:

• l'utente potrebbe non aver chiaro cosa siano i servizi.
• I servizi sono cmq correlati a dati (es. dati di input) che potrebbero essere forniti dall'utente stesso (in che formato?) oppure essere frutto della discovery.
• A loro volta i dati, una volta identificati quelli d'interesse, potrebbero richiedere servizi per la loro conversione in un formato specifico.
• Sarebbe carino gestire in modo "unificato" dati e servizi senza richiedere che l'utente scelga espressamente se cercare dati o servizi.
  • Es: la scelta tra discovery di dati o servizi potrebbe discendere dalla scelta dei campi eseguita (campo WHEN esistente = ricerca dati, più parametri WHAT indicano forse gli input del servizio desiderato)
• L'idea di partenza (comune a tutti i geoportali) e' cmq quella di una scelta binaria a monte tra discovery dati-discovery servizi.

Strumenti:

• Calendario campagne
• Strumenti di collaborazione (???)
• Gestore di workflow
• Quality check
• News feeds

Funzionalità e use cases

• Gestione metadati (inserimento, modifica, ecc.)
• Visualizzazione dati
• Download dati
• Interrogazione bibliografia dati
• Gestione campagne
  • UC1: l'utente accede al portale per trovare una campagna alla quale aggiungersi
  • UC2: l'utente accede al portale per inserire una campagna che intende eseguire, modifcare i dati relativi ad una campagna inserita in precedenza dall'utente stesso oppure eliminare una campagna che ha precedentemente inserito