Buongiorno a tutti,
sono molto contento che qualcuno abbia sollevato questo argomento: provo a dire la mia (scusate per la prolissità, ma ci sono molte cose da dire… leggete con calma, se volete e ne avete il tempo):
-
personalmente credo che una GUI amichevole e ben fatta sia un aspetto chiave per la buona riuscita di un qualsiasi software. Lo scoglio culturale con cui mi sono maggiormante dovuto scontrare nell’ambiente degli sviluppatori è la considerazione che le GUI siano solo strumenti per utenti inetti ed incapaci: IMHO tutto ciò è pura follia. Non continuerò oltre spiegando i motivi per i quali credo che una GUI ben fatta sia assolutamente uno strumento necessario, e non solo per i neofiti, piuttosto preferirei fare alcune considerazioni basate sulla mia esperienza nel mondo GIS. Sono entrato in contatto con il mondo GIS solo da pochissimo tempo, e, tra le altre cose, solo per vie traverse (non faccio parte, infatti, di quelle classiche figure professionali che, tipicamente, costituiscono il bacino d’utenza dei software GIS). Posso dire di avere solo una conoscenza di base per quanto riguarda il mondo della programmazione, ed una discreta conoscenza (direi a 360°) del lato utente, in quanto utilizzo correntemente molti strumenti di tipo diverso (data la mia configurazione di Ingegnere AllRound) e su diversi sistemi operativi (MS, Linux e Mac). In qualità di utente low level, posso descriversi quali sono attualmente le mie scelte operative: utilizzo principalmente QGIS, in quanto più intuitivo, più rapido, sia perchè mappa e strumenti sono in un’unica finestra, sia perchè la gestione delle proprietà dei layer è estremamente completa, compatta ed intuitiva. Detto questo, devo anche aggiungere che, per quanto mi riguarda, lo strumento QGIS sarebbe assolutamente inutile se non disponesse del plugin di GRASS, a meno che non si intenda utilizzare sepraratamente GRASS per l’elaborazione dei dati e QGIS per la sola creazione delle mappe. Capita spesso che utilizzi i comandi di GRASS direttamente da shell (da GRASS toolbox), ma questo dipende solo da alcune limitazioni della GRASS toolbox di QGIS, piuttosto che dall’effettiva maggiore comodità di un comando in linea piuttosto che il relativo in GUI. Ritengo, comunque, che l’utilizzo di due software diversi per l’elaborazione e manipolazione dei dati da un lato, e la rappresentazione degli stessi dall’altro, sia disagevole e rappresenti una fastidiosa perdita di tempo (nonchè possibile fonte di confusione ed errori nel trattamento dei dati e dei flussi di lavoro).
-
in base a quanto detto sopra, si possono fare due semplici considerazioni:
2.1. GRASS
è ottimo per l’elaborazione dei dati, ma presenta gravi lacune dal punto di vista della GUI, non in quanto bellezza dell’interfaccia, chiaramente (era ovvio, ma è sempre meglio essere chiari), ma in quanto intuitività e facilità di gestione dei processi di lavoro; in particolare risulta molto complicato generare delle mappe accattivanti per l’utente finale.
2.2. QGIS
è estremamente facile ed intuitivo (anche se un po’ confusionario sotto certi aspetti) e permette di creare mappe complete e belle con pochi semplici passi. Tuttavia, se non disponesse del plugin di GRASS (e di altri python plugins), sarebbe disarmante la sua carenza dal alto elaborazione… cosa peraltro gravissima! se i dati non li elaboro, che me ne faccio di un bel strumento che me li mostra solamente?
- Per quanto mi riguarda la GRASS toolbox è un punto chiave di QGIS: permette di ottenere, all-in-one, la potenza di elaborazione dei dati di GRASS con la facilità d’uso e la capacità di rendering grafico di QGIS. Tuttavia c’è moltissimo lavoro da fare ancora su tale strumento, al di là della sua necessaria migrazione da QT3 a QT4, che è un aspetto meramente tecnico e non progettuale:
3.1. LIMITI DELLA GRASS TOOLBOX:
una delle cose che preferisco della GUI di GRASS è che posso lanciare direttamente un modulo senza doverlo cercare fra le molteplici opzioni dei menu a tendina: digito il nome del modulo nella finestra di output e premo semplicemente il pulsante Run GUI… fantastico! approccio ricalcato dalla GRASS toolbox… con la differenza che questa presenta tutti i comandi in unica schermata, a volte ripetuti (per esempio più comandi g.region, in funzione della finalità del comando e delle opzioni necessarie, cosa che non gradisco assolutamente) e disposti in maniera alquanto poco leggibile e poco pratica. Un ulteriore grosso limite della GRASS toolbox è la non completezza dei comandi (nella GUI): in primis l’impossibilità della gestione di file multipli in input (cosa che in pratica rende impossibile l’utilizzo di comandi fondamentali quali r.patch e v.patch), infine la non completezza delle opzioni previste per ogni singolo comando; sarebbe fantastico poter disporre di una GUI per ogni comando che ricalchi esattamente quella disponibile in GRASS.
3.2. COME VORREI LA GRASS TOOLBOX:
il mio desiderio? disporre di una struttura di comando a tendina che ricopi quella attuale di GRASS e la possibilità di lanciare comandi singoli proprio come in GRASS; il che permetterebbe, inoltre, di facilitare la manutenibilità e la compatibilità della GRASS toolbox con l’evoluzione di GRASS stesso.
3.3. COSA MANTENERE DELLA GRASS TOOLBOX:
cosa mantenere dell’attuale GRASS toolbox? sicuramente la comodità di aprire le GUI dei comandi in finestre tab, comprese la finestra relativa al manuale e all’output (in GRASS, per esempio, tutte le volte che apro il manuale di un comando mi apre una nuova finestra di explorer… troppo confusionario!). Ritengo estremamente comoda e ben fatta, inoltre, la tab browser, che mi permette di visualizzare a colpo d’occhio i raster e vettoriali contenuti nella location, con relative info e la possibilità di eliminare i raster (o i vettoriali) dalla location o di rinominarli. Infine, assolutamente da mantenere è la possibilità di eseguire i comandi GRASS da shell, imprescindibile per un power user.
3.4. SVILUPPO DELLA GRASS TOOLBOX
personalmente sarei molto felice di poter partecipare in prima persona allo sviluppo di una nuova GRASS toolbox, ma purtroppo al momento non posso per gravi mancanze di tempo. Tuttavia, su questo tema, vorrei fare un’osservazione: ho cercato in rete e chiesto al team di sviluppatori alcune informazioni relativamente alla documentazione di progetto, ritenendo l’attuale lavoro un ottimo (direi addirittura essenziale) punto di partenza per un futuro sviluppo dello strumento, ma purtroppo ho scoperto che nessuno ne sa nulla e, per di più, sembra non esistere alcuna documentazione a riguado… cosa, questa, molto, molto grave!
- Alcune considerazioni sulla GRASS GUI
cosa detesto, invece, della GRASS GUI? sostanzialmente che ogni comando (Run GUI) mi apre un’ulteriore finestra, oltre alle 3 già aperte di base, e che se non mi ricordo di chiuderla mi può capitare, dopo pochi minuti, di averne aperte altre 6 o 7, di cui alcune relative allo stesso comando (se non mi sono ricordato di chiuderle)…
Se uno dovesse utilizzare solo o pricipalmente GRASS per il proprio lavoro potrebbe essere un aspetto trascurabile… per quanto mi riguarda, invece, non lo è proprio: se a tutte le finestre di GRASS aggiungiamo: mail client, browser web, file browser (nel caso windows spesso multipli), editor di testo, fogli di calcolo, chat e/o voip, CAD, strumenti software specifici (dalla gestione db alla gestione file in remoto)… insomma, di norma lavoro con almeno 10 applicazioni/finestre aperte, per ogni finestra un’applicazione… se aggiungo 5 o 6 finestre attive solo per GRASS comincio veramente a sclerare!!!
infine alcune considerazioni sulla nuova wxPython GUI: è decisamente migliore della GUI in tcl/tk, anche se prevede ancora due finestre separate per la gestione delle mappe e per i controlli/comandi. In generale sono state effettuate molte modifiche verso una migliore usabilità, anche se molte questioni rimangono ancora aperte… l’unica cosa veramente grave che ho notato è la generale estenuante lentezza dell’interfaccia: spesso mi impalla windows per qualche secondo anche solo per inserire un nuovo raster.
- Considerazioni conclusive:
Scusatemi, mi rendo conto di aver scritto troppo, ma almeno ho espresso definitivamente ed apertamente molte delle considerazioni che in questi ultimi mesi ho continuato a sottoporre ad elementi singoli di questa ed altre liste di discussione. Spero sinceramente (vista anche la partecipazione al thread sia di Paolo che di Markus) che questo possa essere uno spunto di riflessione costruttivo per una svolta (relativamente all’argomento GUI) di strumenti quali QGIS e/o GRASS. Siamo ad un punto in cui il mercato comincia a proporre molte opportunità, un punto in cui è assolutamente necessario proporsi con forza e decisione: gli utenti comiciano ad abituarsi al discorso software GIS, abbandonando molte vecchie ed inadatte soluzioni informatiche, ma richiedendo al contempo uno strumento completo, intuitivo e con ulevato tasso di interoperabilità; gli strumenti GIS opensource cominciano a nascere come funghi, ma non tutti dispongono dei numeri necessari, soprattutto dell’esperieza maturata in anni da un fornito ed altamente referenziato gruppo di sviluppatori e ricercatori… ma (come spesso capita in qualsiasi ambito professionale) con una forte capacità di comunicazione ed una notevole (anche se spesso ingannevole) appetibilità nei confronti dell’utente finale (leggi GUI ed usabilità da parte di utenti base) rischiano di prendere il sopravvento anche nei confronti di strumenti più avanzati e completi che, sulla carta, sono maggiormente competitivi.
Lo ripeto ancora, rischiando di essere noioso e ripetitivo: il software GIS sta definitivamente approcciando il punto di svolta: da software per ricercatori smaliziati e very skilled, a strumento diffuso e con un bacino d’utenza molto ampio, sia dal punto di vista della tipologia professionale e d’uso, che dal punto di vista delle capacità informatiche dell’utente che andrà ad utilizzarlo…
… e non aggiungo altro (per fortuna! direte voi…).
Distinti saluti a tutti,
Marco Pasetti
