Search Fields

L'interfaccia all'indirizzo Search Fields ha il solo scopo di visualizzare in un'unica pagina quattro protipi per la compilazione dei campi di ricerca, utili per la discovery, e raccogliere feedback.

Generalita'

Tre dei quattro campi ("Who", "What" e "Where") prendono i dati per l'autocompletion dai dati RDF presenti nell'istanza di Virtuoso ospitata dal server. Il loro grado di maturità è il seguente:

• Who: persone all'interno di RITMARE, con tutti gli errori già riportati nella pagina relativa al Relation Editor.
• What: i circa 28.000 parametri di SeaDataNet/BODC (vedi Vocabolari SP7).
• Where: i circa 6.000 toponimi italiani ottenuti dal gazetteer GeoNames escludendo quelli di granularità troppo fine, tipo hotel, musei, ecc.

Una volta selezionato un elemento dalla lista di suggerimenti, il corrispondente URI viene inserito in un campo form nascosto per essere recuperato in un secondo tempo, nel momento in cui la ricerca verrà lanciata.

Il quarto campo ("When") è costituito da tre slider che permettono di selezionare un intervallo temporale con granularità differenti (giorni, mesi, anni).

Utilizzo:

L'interfaccia non è destinata ad un utilizzo diretto ma solo al debugging e alla raccolta dei requisiti per il widget dell'interfaccia definitiva.

Fig. 1: Interfaccia

Bachi/errori nel rendering del browser:

Errori nel rendering del browser (CSS o JavaScript)

• con il browser Goggle Chrome su Windows 8 e su MacOS (10.9) nella pagina di search non funzionano gli slider del "when" quando da <day> si passa a <month> o <year>; lo stesso accade con Safari su MacOS (10.9)

Bachi nell'applicazione:

Premessa 1: il codice Javascript che viene eseguito client-side proviene da un sito, http://www.fromvega.com, attualmente non accessibile e costituisce il principale limite: un nuovo metodo per gestire l'autocompletion è attualmente sotto esame.

Premessa 2: l'impaginazione in frameset ha il solo scopo di mostrare l'una accanto all'altra le quattro interfacce. Nell'interfaccia vera e propria si suppone che i campi per la discovery siano all'interno della stessa pagina (in modo da ovviare a problemi di scrolling dei suggerimenti di autocompletion).

• Capita spessso che, selezionando con il mouse un elemento dalla lista dei suggerimenti, questo non vada a completare il campo form (e il relativo campo nascosto).
  • Errore dovuto al codice Javascript, sparirà una volta trovata una soluzione migliore per l'autocompletion.
  • Non avviene mai quando il suggerimento viene selezionato dalla lista scorrendola con le frecce.
• Scorrendo la lista con le frecce, capita di dover premere il tasto più volte per tornare dal fondo della lista al primo elemento (o viceversa).
  • Per i termini del gazetteer, dipende probabilmente dagli elementi che non vengono inseriti nella lista (perchè duplicati dello stesso toponimo con posizione equivalente).
  • Per gli altri campi form, dipende probabilmente da un valore finale di un ciclo for.

Todo list:

• Identificare campi aggiuntivi da aggiungere ad ognuno dei campi form. Ad esempio:
  • Il campo "Who" potrebbe avere una checkbox per escludere dalla ricerca la profilazione utente.
• Trovare una visualizzazione efficace per i parametri, che hanno definizioni troppo lunghe che rendono la lista di suggerimenti difficile da scorrere.
  • Ci si potrebbe limitare alle sigle corrispondenti e mostrare la descrizione solo al mouseover (come avviene attualmente per l'URI corrispondente).
    • A questo punto però l'autocompletion dovrebbe, a rigor di logica, avvenire sulla sigla e non sulla descrizione.
• Trovare una interazione efficace per definire la bounding box per la ricerca a partire dalla posizione del toponimo nel campo "Where".
  • Si potrebbe definire un numero di bounding box incrementali e lasciare che l'utente ne selezioni una con un radio button, come per la granularità nel campo "When".
  • Il valore di partenza della bounding box potrebbe essere ricavato dalla tipologia di toponimo selezionata (es. più ampia per una regione, più ristretta per una città)