Griglie che parlano la lingua dell’utente: filtri visuali, viste personali, azioni configurabili

Premesse

Un motore dati generico e configurabile, di cui ho parlato nell’articolo precedente, risolve il problema di come costruire velocemente un’interfaccia per una nuova entità. Ma risolve solo metà del problema: l’altra metà riguarda quanto quella interfaccia sia davvero utilizzabile da chi non scrive query SQL per mestiere. Un building manager che deve trovare “tutti gli asset critici del terzo piano non ancora verificati quest’anno” non dovrebbe dover chiedere aiuto a un tecnico informatico per formulare quella domanda al sistema.

Questo è il punto in cui la qualità dell’esperienza utente smette di essere una questione estetica e diventa una questione di autonomia operativa reale: quanto un utente non tecnico riesce a fare da solo, senza intermediazione, determina quanto quello strumento verrà davvero usato ogni giorno invece di essere aggirato con un foglio Excel parallelo.

Come funziona un costruttore di filtri visuale capace di esprimere logiche complesse senza scrivere SQL?

Il problema tecnico è tradurre in un’interfaccia grafica intuitiva un concetto logico che, sotto il cofano, è un’espressione booleana con gruppi annidati di condizioni in AND e in OR – esattamente ciò che un utente esperto scriverebbe come clausola WHERE in una query SQL. Un costruttore di filtri ben progettato, sul modello ormai familiare a molti grazie a strumenti diffusi come i fogli di calcolo collaborativi più evoluti, rappresenta ogni condizione come un blocco visuale componibile – campo, operatore, valore – e permette di raggruppare più condizioni con un connettore logico esplicito, annidando gruppi dentro gruppi quando la logica lo richiede.

Dietro questa interfaccia, il sistema deve tradurre la struttura visuale in una query parametrica sicura, senza mai concatenare stringhe che potrebbero aprire a un’iniezione SQL, e deve farlo in modo generico per qualunque tabella configurata, non con codice scritto ad hoc per ogni possibile combinazione di filtri. È un esercizio di ingegneria del software non banale, perché il numero di combinazioni possibili di campi, operatori e raggruppamenti è enorme, e il motore deve gestirle tutte con lo stesso percorso di codice.

Che differenza c’è nell’uso quotidiano, tra un filtro salvato come default del task e una vista personale?

Sono due meccanismi che rispondono a esigenze diverse e devono restare distinti. Un filtro salvato come default del task è una configurazione condivisa: chiunque apra quella schermata la vede applicata, ed è pensata per riflettere una policy organizzativa – per esempio, mostrare di default solo gli interventi non ancora chiusi. Una vista personale, salvata nel pannello dei preferiti di ogni singolo utente, è invece una combinazione di colonne visibili, ordinamento e filtri che riflette il modo di lavorare di quella specifica persona, senza toccare in alcun modo la configurazione condivisa vista da tutti gli altri.

Tecnicamente, questo richiede due livelli di persistenza separati: una configurazione a livello di task, applicabile da un amministratore e valida per tutti, e una configurazione a livello di singolo utente, applicabile autonomamente e valida solo per chi l’ha creata. Confondere questi due livelli – per esempio permettendo a un utente di modificare inavvertitamente il default condiviso mentre pensa di star salvando solo la propria vista – è un errore di progettazione che genera confusione operativa reale, ed è uno dei dettagli che vale la pena verificare concretamente in una demo prima di adottare uno strumento.

Come si progetta un sistema di azioni configurabili sufficientemente ricco da coprire processi diversi senza scrivere codice per ognuno?

Un elenco di record utile non serve solo a essere consultato, ma anche ad agire su di esso: aprire una scheda di dettaglio, aggiornare un campo, inviare una notifica, generare un documento, cancellare una selezione multipla. Un motore maturo dovrebbe offrire un catalogo ampio di tipi di azione configurabili – nella pratica, un sistema completo copre bene oltre una decina di tipologie diverse, dall’apertura di un form alla modifica diretta di una colonna, dall’invio di un’email alla stampa di un documento – ciascuna parametrizzabile senza scrivere codice, assegnabile al menu contestuale di una riga o di una selezione multipla.

Il caso tecnicamente più interessante è la possibilità di concatenare più azioni in sequenza in un’unica operazione configurata – aggiornare un campo, poi inviare una notifica, poi aprire un documento generato al volo – senza dover implementare un motore di workflow completo con tutta la sua complessità. È un compromesso deliberato: non la potenza illimitata di un motore di processo generico, ma una catena di azioni semplice, comprensibile e configurabile da un amministratore senza competenze di programmazione, sufficiente a coprire la stragrande maggioranza dei processi operativi reali di un’organizzazione FM.

In che modo l’editing inline, incluso l’aggiornamento massivo, cambia il ritmo del lavoro quotidiano?

Poter modificare un valore direttamente nella cella della griglia, senza dover aprire un form separato per ogni singola modifica, è una differenza di produttività che si accumula nel tempo su un uso quotidiano intenso. Ancora più rilevante, tecnicamente e operativamente, è la possibilità di applicare lo stesso aggiornamento a un’intera selezione o a un intero risultato di un filtro con un solo comando: cambiare lo stato di cento asset filtrati in un’unica operazione, invece di aprirli uno per uno. Questo richiede che il motore sappia tradurre l’operazione in un aggiornamento massivo lato database, rispettando comunque, riga per riga, gli stessi controlli di permesso che si applicherebbero a una modifica singola – un dettaglio di sicurezza che analizzeremo più a fondo negli articoli dedicati alla sicurezza applicativa più avanti in questa serie.

Come vivono questa flessibilità le quattro figure che usano lo strumento ogni giorno?

Il building manager guadagna l’autonomia di costruirsi le proprie viste di lavoro senza dover richiedere assistenza tecnica ogni volta che cambia la sua priorità operativa. Il manutentore interno beneficia soprattutto delle azioni rapide e dell’editing massivo, che gli permettono di chiudere in blocco attività ripetitive invece di ripeterle una per una. Il proprietario osserva l’effetto indiretto ma concreto sul costo di gestione: meno tempo speso su operazioni ripetitive significa più tempo dedicato ad attività a maggior valore. La ditta esterna o il global service, infine, apprezza la possibilità di configurare azioni e filtri diversi per contesti contrattuali diversi, mantenendo un unico strumento adattabile invece di uno strumento rigido uguale per ogni cliente indipendentemente dalle sue esigenze specifiche.

Conclusioni

Un motore dati generico diventa realmente utile solo quando chi lo usa ogni giorno – senza competenze tecniche, senza saper scrivere una query – riesce a costruirsi da solo i propri filtri, le proprie viste e le proprie azioni ricorrenti. È la differenza tra uno strumento che si usa per obbligo e uno strumento che si sceglie di usare perché fa risparmiare tempo reale. Nel prossimo articolo vedremo come questa stessa piattaforma dati si estenda dalla scrivania al cantiere, con un’esperienza pensata per il lavoro mobile sul campo.

Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui