Home Risultati Fase 1 Elaborazione
Italian - ItalyEnglish (United Kingdom)
Elaborazione
 

Analisi Funzionale

Profilatura utenti

Come definito nelle Specifiche Funzionali riguarda la realizzazione di :

  • controllo dell’accesso: accettato o negato a seconda del profilo o del gruppo di appartenenza;

 

  • possibilità di gestione di tutti o parte dei dati da immettere: cioè dovrà essere possibile presentare una schermata in cui l’utente A immette una parte dei dati e l’utente B un’altra;

 

  • poteri attribuiti: cioè la possibilità di immettere e successivamente vedere solo i propri dati o di avere un accesso di tipo “supervisore” per gestire dati relativi a gruppi di utenti;

 

  • livello di competenza: cioè la capacità individuale di immissione di dati; si tratta cioè di dare al gestore l’informazione sul livello di rapidità e di competenza nel data entry di ogni utente (1= utente abile ed esperto, 2= utente abile ma non esperto ecc.), così che, per lui, possa essere preparata la quantità di lavoro adeguata al tempo di immissione disponibile.

 

Nella prima versione, tutti gli operatori del Data Entry dovevano essere definiti al momento della progettazione dello stesso. Questo è risultato un po’ troppo vincolante, costringendo chi volesse la libertà di gestire in un secondo momento gli operatori ad ovviare a ciò a definire un certo numero di operatori fittizi: es. operatore1, operatore2, ecc… per poi assegnarli in un secondo momento ad un utente specifico, semplicemente dandogli le referenze di accesso.

 

Per ovviare a queste carenze e per integrare le nuove funzionalità si è deciso di non far specificare al progettista del Data Entry tutti gli utenti al momento della progettazione. Sarà necessario per questo definire un amministratore e dei profili generici. Questi profili generici sono stati divisi in 3 gruppi:

  • inseritore semplice;
  • inseritore esperto;
  • supervisore.

 

L’inseritore semplice al momento del login, se supera il controllo dell’accesso e quindi viene riconosciuto dal sistema, verrà assegnato al suo profilo utente e ne prenderà quindi le caratteristiche e le autorizzazioni.

Sarà assegnato ad una parte del Data Entry, con funzionalità limitate, non potrà per esempio fare operazioni quali “Esporta” o “Archivia”. Inoltre se viene definito che una parte dei dati sono riservati ad utenti esperti, questo non potrà né visualizzarli né modificarli.

 

L’inseritore esperto, una volta superato il controllo dell’accesso sarà assegnato al suo profilo con le autorizzazioni di utente esperto. Questo gli consentirà di effettuare tutta l’attività di data entry, compresa la possibilità di Archiviare ed Esportare. La logica delle autorizzazioni sarà quella di inclusione, cioè ciascun livello superiore ha tutte le autorizzazioni del livello sottostante più altre sue specifiche.

Il supervisore, riconosciuto con tali autorizzazioni dal sistema, potrà effettuare tutte le operazioni del data entry, come l’inseritore esperto, inoltre avrà la possibilità di visualizzare una serie di dati aggregati che riguardano le informazioni del data entry effettuato. Questi aspetti saranno approfonditi ed integrati nel modulo di Tracciatura.

 

L’amministratore, oltre ad avere le autorizzazioni per operare come supervisore, avrà la possibilità di definire per ciascun utente il gruppo di appartenenza. In questo modo, un utente che per la prima volta opera nel data entry, potrebbe essere inquadrato come inseritore semplice, successivamente, analizzandone l’operato, l’amministratore potrebbe passarlo al gruppo di utente esperto, senza necessità di modificare l’account di accesso. Nel caso lo ritenesse idoneo anche al gruppo supervisore.


Personalizzazione dinamica layout

Si vuole dare la possibilità al progettista del Data Entry di poterlo personalizzare maggiormente e poterne definire più caratteristiche. In particolare sono state ritenute interessanti le seguenti possibilità:

  • Personalizzazione del Data Entry dal punto di vista grafico con l’inserimento di un logo aziendale;
  • Scegliere il colore di sfondo, e diversificare il colore dello sfondo o dei campi a seconda della parte del Data entry;
  • Specificare in modo esatto le Label per ciascun campo e di poterlo modificare direttamente dalla visualizzazione;
  • Creare nuovi campi attraverso la duplicazione, anche multipla, di campi esistenti;
  • Integrare maggiori informazioni all’interno delle interfacce;
  • Definire una guida al Data Entry specifico, con una spiegazione del significato dei campi.

 

Inserimento logo aziendale, per una maggiore personalizzazione della grafica del Data Entry. Pur comprendendo la volontà dell’utilizzatore del Data Entry, resta da tenere presente che una delle priorità delle schermate di Data Entry è quella di avere il maggior spazio possibile a disposizione. Di conseguenza si consiglia vivamente al progettista di valutare attentamente questa eventualità. Si potrebbe mettere a disposizione del progettista la possibilità di inserire il logo aziendale, visualizzandolo sicuramente nella schermata di login, ed eventualmente anche all’interno delle schermate di data entry stesse.

 

Scelta del colore di sfondo, anche in questo caso, si vuole dare la possibilità al progettista di personalizzare maggiormente l’aspetto visivo del Data Entry. Questo può essere utile anche nell’eventualità che i dati da leggere siano in un documento di un colore diverso dal solito e quindi il progettista potrà in questo modo scegliere il colore di sfondo più idoneo per metterli in evidenza. Si vuole integrare inoltre anche la funzionalità di poter diversificare il colore stesso dei campi di testo, o almeno del loro sfondo. Questo perché prevedendo che si possa assegnare ad un diverso operatore una parte specifica del Data Entry, potrebbe essere utile distinguerli in modo semplice e visivo per agevolare il compito del supervisore. Questa eventualità non influirà sull’operato degli inseritori semplici in quanto ad essi potrebbe essere mostrata soltanto la parte di campi di loro competenza.

 

Specificazione Label e modifica in modo semplice. Non sempre è possibile al momento della specificazione dei campi individuare in modo esatto quella che è l’etichetta più congrua da far visualizzare. Inoltre nell’applicativo così com’è allo stato attuale, per i campi multipli, quali le scelte multiple, ossia check box, o la scelta singola, ossia i radio button, è possibile specificare un solo nome, che viene in automatico esteso con un progressivo per gli altri. Questa scelta per quanto molto efficace, è risultata di difficile comprensione per chi non ha competenze informatiche, inoltre non è possibile modificare la singola Label, per esempio in caso di una scelta multipla che deve avere etichette diverse. Se fosse per esempio una indicazione della tipologia di documento, indicare come etichetta Tipologia_1, Tipologia_2 ecc.. sarebbe senz’altro meno esplicativo di poter utilizzare Label diverse per indicare per esempio Fax, Fattura, ecc.. pur essendo dello stesso blocco.

Sembra inoltre alquanto laboriosa la procedura per cambiare i nomi dei campi, per le Label sarebbe preferibile dare la possibilità al progettista di cambiarla direttamente nella tabella dei campi, o in una delle schermate di visualizzazione del Data Entry, per controllarlo prima della generazione.

 

Modalità di creazione dei campi in modo più semplice, evitando di dover editare di nuovo tutte le caratteristiche, ma consentendo di poterlo fare a cominciare da un campo esistente, quindi per duplicazione. Eventualmente anche multipla. Cioè dovendo fare più campi simili, si può indicare di volerne altri uguali ad uno già specificato.

 

Integrazione di maggiori informazioni. Anche in questo caso, si tratta di una modifica che vuole agevolare l’operato dell’inseritore. La possibilità di farlo potrebbe consentire all’operatore di fare una fase di controllo dei dati a priori. In realtà questa funzionalità potrebbe risultare superflua in alcune lavorazioni, quelle con un’immagine da cui leggere i valori, perché l’inseritore deve solo copiare quanto scritto sulla carta, invece potrebbe essere molto più utile quando si tratta di interfacce per un inserimento dati diretto. Quale ad esempio una form di feedback per un sito web, per un servizio, oppure una form di partecipazione ad un evento, quale ad esempio quella implementata da noi per la presentazione del progetto ad HANDImatica 2008. Bisogna sempre tenere presente che è di fondamentale importanza per il Data Entry il compromesso fra le maggiori informazioni da poter esplicitare e la chiarezza e la pulizia delle interfacce stesse.

 

Definizione di una Guida al Data Entry. Una soluzione possibile a parte dei problemi precedentemente descritti potrebbe essere quella di far scrivere al progettista del Data Entry una Guida vera e propria al lavoro specifico, in cui è possibile integrare le informazioni che lo riguardano, specificandone per esempio i valori attesi e il significato, nel caso in cui all’operatore sia in qualche modo richiesto anche il compito di “correggere” eventuali imprecisioni di chi ha compilato il corrispettivo cartaceo. Questa guida in pratica conterrà quelle informazioni che vengono poi utilizzate anche per specificarne i controlli automatici. Ma potrebbe integrare anche delle informazioni non formalizzabili con gli strumenti automatici.

 


Gestione Controlli

La gestione dei controlli integra nel sistema la possibilità da parte del progettista del Data Entry di definire per ciascun campo se deve essere soggetto ad un controllo. La tipologia dei controlli dipende dal tipo di campo. Questa funzionalità può sembrare superflua nel momento in cui i dati vengono letti da una documentazione cartacea che è già compilata. Per chiarire meglio, se c’è un campo, es. matricola che è stato definito come un numerico che va da 0 a 15000, e nella scansione si vede che il compilatore ha scritto COPER, l’operatore di Data Entry dovrebbe semplicemente scrivere quello che legge. Quindi COPER. Ma se viene elaborato in questo modo, i dati esportati in un file di testo, al momento del caricamento in un gestionale o in un possibile applicativo a valle, causeranno un errore più o meno grave a seconda della complessità della procedura e del sistema. Per ovviare a ciò si intende integrare l’applicativo con una serie di controlli che segnalino all’operatore del Data Entry che quel tipo di dato non è accettabile. Questo comporterà una “correzione” da parte dell’operatore, che eliminerà il valore non consentito. Oppure si potrebbe sostituire il valore non consentito con un valore predefinito deciso dal progettista e indicato nella Guida al Data Entry. Un valore che per gli applicativi a valle ha correttezza ma sta ad indicare un’anomalia del dato in questione, un codice di errore, o qualcosa di simile. I controlli da integrare e quindi automatizzare possono essere catalogati in diversi livelli:

· Tipologia del dato;

· Valore consentito;

· Controlli incrociati.

 

Tipologia del dato indica il tipo di dati che possono essere indicati per quel determinato campo. Per esempio per un campo come la matricola, potrebbe essere utile indicare un controllo che verifichi se i valori immessi sono di tipo numerico. Oppure per un campo di tipo Cognome controllare che siano tutti caratteri letterali, senza numeri.

 

Valore consentito sta ad indicare il possibile valore del campo stesso. Per esempio per un campo matricola potrebbero essere consentiti solo valori compresi fra 0 e 15000. In questo caso quindi, oltre al precedente controllo sul tipo dei dati, sarebbe opportuno poterne indicare uno ulteriore sui valori. Questo controllo potrebbe essere definito come un range di valori possibili. Oppure una lista dei valori possibili, nel caso in cui non sia formalizzabile come range. Nel caso di campi di una data, può essere utile controllare la validità della data stessa. Ed eventualmente anche in quel caso le date possibili. Se il lavoro riguarda un dato anno, non avrebbe senso accettare come buone date che siano di un anno diverso. Anche se indicato nei dati scritti. La lista dei valori possibili può essere utilizzata anche per campi di tipo non numerico, ad esempio se c’è da indicare la provincia, in un modulo che riguarda l’Emilia Romagna, si può prevedere che la lista delle province possibili sia predefinito e quindi è possibile controllare tale valore. Sarà compito del progettista implementare tali controlli nel modo che ritiene opportuno.

 

I Controlli Incrociati vanno ad interessare non un singolo campo, ma almeno due. Si vuole mettere a disposizione una funzionalità che consenta al progettista di definire un controllo di valore, ma condizionato al valore di un altro campo. Per esempio se il numero di persone che lavorano è 10, il numero di ore totali non può essere maggiore di 80. In questo caso, il campo del numero delle ore, avrà un controllo in cui viene indicato il valore del numero di persone moltiplicato per 8 come massimo consentito. Oppure semplicemente se è indicato un flag in un campo allora il valore in un altro campo deve essere maggiore di 0.

 

Per tutti questi casi potrebbe essere utile definire se è il caso di sostituire il valore errato con un valore di default definito. Oppure se lasciare che sia l’operatore a effettuare tale sostituzione dopo averlo segnalato in qualche modo.


Tracciatura del lavoro

La Tracciatura del Lavoro serve per poter meglio distribuire il lavoro stesso. Cioè sapere qual è il lavoro effettuato da un operatore piuttosto che da un altro consente di meglio bilanciare il carico del lavoro rispetto all’operatore. Questa informazione serve anche per poter definire la classificazione degli operatori all’interno dei profili definiti. Le informazioni dei tracciati non devono essere visualizzabili da tutti gli operatori, ma solo dai supervisori, e dall’amministratore. Dovrebbe esserci anche la possibilità da parte del supervisore, di specificare una valutazione qualitativa sull’operato dell’inseritore.


Analisi Tecnica

Assodate quelle che sono le tecnologie da utilizzare, e cioè tutta la filiera dell’architettura LAMP andiamo ad approfondire tecnicamente le integrazioni in oggetto.

 

Profilatura utenti

Per implementare quelle che sono le logiche funzionali che riguardano: controllo degli accessi, gestione dati personalizzata, poteri diversificati e livello di competenza si è deciso in fase di analisi funzionale di spostare tale gestione all’interno del Data Entry, consentendo all’amministratore definito in fase progettuale di definire i gruppi e gli utenti.

Questa logica implica che al momento dell’accesso al Data Entry, non solo vengano controllate le credenziali e concesso o meno l’accesso, ma l’utente verrà assegnato al suo gruppo di appartenenza e ne erediterà le credenziali operative all’interno del Data Entry.

Questo implica che all’amministratore, al momento dell’accesso al Data Entry verrà presentata un’interfaccia diversa da quella degli operatori, nella quale potrà scegliere se accedere alla parte di inserimento dati vera e propria o ad una sorta di interfaccia di gestione dove può definire nuovi utenti, scegliere a quale gruppo associarli, spostare un utente da un gruppo ad un altro.

Per fare ciò è necessario integrare la tabella degli utenti con maggiori informazioni. Inoltre bisogna aggiungere una tabella ulteriore con i gruppi. In alternativa si potrebbe inserire un campo per ciascun utente che indica se quello è un utente o un gruppo. Si consiglia di utilizzare due tabelle distinte, per una maggiore pulizia e perché il numero dei gruppi è limitato, mentre quello degli utenti potrebbe essere molto elevato e quindi non avrebbe molto senso ripetere un’informazione in tutte le tuple. Resta comunque da indicare qual è il gruppo di appartenenza. Si potrebbe quindi pensare di fare le due cose contemporaneamente, indicando in quel campo: 0 se non è associato ad alcun gruppo, l’id del gruppo nel caso fosse associato, e per i gruppi il proprio stesso id.

L’utente amministratore potrebbe avere un gruppo a se stante.

 

Per implementare le funzionalità dei diversi gruppi rispetto al Data Entry, si inibiscono i pulsanti Archivia ed Esporta, per l’inseritore semplice. Per una maggiore chiarezza, si potrebbe anche evitare di visualizzarli, invece di inibirli solamente.

L’inseritore esperto avrà le funzionalità già esistenti, comprese Archivia ed Esporta. Il supervisore avrà invece delle funzionalità ulteriori di controllo e visione di dati aggregati. Per accedere a queste interfacce si può aggiungere un pulsante all’interno delle schermate del Data Entry, oppure presentare un’interfaccia di scelta iniziale se accedere all’inserimento dati o alla sezione di informazioni.

 

Personalizzazione dinamica layout

Tutte le funzionalità individuate in tal senso sono da implementare nel processo di progettazione del Data Entry.

Per il logo aziendale sarà opportuno definirne prima alcune caratteristiche perché potrebbero essere vincolanti per non intralciare graficamente il lavoro di inserimento dati. In particolare il logo sarà presente nell’interfaccia di log-in e nelle interfacce di scelta fra le diverse sezioni del Data Entry, inserimento dati , informazioni sui dati o profilatura utenti. È poi compito del progettista decidere se inserire il logo anche all’interno delle schermate stesse del Data Entry. Il logo dovrebbe avere dimensioni ridotte e svilupparsi in orizzontale. Sarà posizionato in alto nella pagina, dovrà essere un’immagine nei formati standard: jpg, gif, png.

Si consiglia di non andare oltre i 50pixel di altezza e la larghezza a piacere, tenendo presente una dimensione che corrisponda al massimo a quella del monitor utilizzato, gli standard sono circa 1024pixel, si consiglia 800pixel, per una visualizzazione corretta anche nei monitor con una risoluzione inferiore.

Per il colore di sfondo sarà messa a disposizione del progettista la possibilità di scegliere il colore e modificarlo, in fase progettuale.

Inoltre, nel caso vengano definite dal progettista delle sezioni diverse da assegnare all’inseritore esperto, il progettista potrà scegliere un eventuale colore di sfondo di questi. In modo che il supervisore abbia un’indicazione visiva immediata di quella che è la sezione per esperti rispetto a quella normale. La possibilità è di indicare il colore di sfondo del campo di testo, oppure il colore di sfondo del contorno.

Per la Label sarà specificato un ulteriore campo per ciascun dato, che riporta la Label da visualizzare, che potrà quindi essere differente dal nome. Nella schermata di visualizzazione del Data Entry, prima della generazione, sarà possibile modificarle Label, se possibile in modo diretto nell’interfaccia.

Allo stesso modo sarà integrata la struttura con un ulteriore campo che rappresenti una descrizione di quello che dovrebbe essere il contenuto del campo, per dare maggiori informazioni all’operatore.

Per la creazione dei campi a partire da quelli esistenti verrà aggiunto un pulsante per la duplicazione di ciascun campo. È da individuare la logica che riguarda la posizione dei campi per evitare di sovrascriverne altri. In particolare bisogna decidere se vengono messi tutti alla fine dei campi già specificati, oppure in successione a quello duplicato, facendo slittare gli altri o semplicemente controllando che nella sua posizione non ce ne fosse già un altro al momento del salvataggio.

La Guida al Data Entry sarà invece un documento in pdf o in un altro qualsiasi formato testuale, che sarà caricato dal progettista del Data Entry e verrà collegato tramite un pulsante da ogni schermata del Data Entry, in modo che l’operatore vi possa accedere alla bisogna.


Gestione Controlli

Per i controlli una volta specificati bisogna decidere se implementarli in javascript, per dare una risposta più immediata, oppure in PHP e presentare una schermata con l’esito dei controlli nella fase successiva all’inserimento. Per problemi di accessibilità dell’interfaccia rispetto alla Legge Stanca e alle normative W3C sarebbe meglio la seconda ipotesi. Ma per velocizzare l’elaborazione è meglio la prima.

Si potrebbe approfondire poi integrando la possibilità di definire se un controllo debba essere bloccante o meno rispetto alla prosecuzione del lavoro. Ma dalla nostra esperienza troviamo questa strada troppo vincolante, quindi si preferisce lasciare un livello di malleabilità maggiore e delegare il controllo umano del supervisore a questo compito.


Tracciatura del lavoro

Per realizzare la Tracciatura del Lavoro è necessario integrare un campo nella tabella dei dati del Data Entry, dove inserire il nominativo dell’utente ad ogni inserimento. Questo dato non dovrà essere sovrascritto nel caso di modifica e quindi inserimento successivo. Inoltre nel momento dell’esportazione dei dati saranno salvati i dati aggregati per una visualizzazione successiva di supervisore e amministratore. Avendo dato la possibilità al progettista di dividere ciascuna pagina del Data Entry fra l’inseritore semplice e l’inseritore esperto, sarebbe il caso di non avere un solo campo con chi ha inserito i dati ma bensì tre, in modo da salvare in ciascuno l’inseritore semplice, l’inseritore esperto e l’eventuale supervisore che operano sul Data Entry.

Sviluppo

In questa sezione viene indicato quanto effettivamente sviluppato a partire dalla documentazione di analisi. Le spiegazioni di quelle che sono le motivazioni che hanno portato a delle scelte differenti rispetto a quanto previsto e quindi una specie di guida dell’applicativo per meglio orientarsi all’interno del codice, essendo un progetto open source.

 

Profilatura utenti

Come emerso dall’analisi si sono implementati 3 profili utenti, oltre all’amministratore. L’amministratore è l’unico che va definito in fase di progettazione del Data entry. Sarà poi egli ad avere la possibilità in qualsiasi momento di definire nuovi utenti, modificarne i dati, ed assegnarli al profilo opportuno.

Infatti una volta terminata la progettazione del Data Entry, ed indicato quindi l’amministratore, accedendo al deployment viene presentata una interfaccia di login standard. Effettuato il login, si accede ad una Home personalizzata che presenta un menù differente a seconda del profilo utente riconosciuto. Nel caso amministratore avrà

Homepage: per tornare alla pagina iniziale;

Date Entry: per andare alle interfacce di inserimento dati vere e proprie;

Amministrazione: per accedere alla parte dell’applicativo che consente all’amministratore di gestire utenti e gruppi;

Controllo: per visualizzare le informazioni inerenti il lavoro di inserimento dati in corso;

Interrogazioni: per visualizzare le informazioni statistiche dei lavori svolti in precedenza.

 

Nel caso supervisore non avrà Amministrazione, l’inseritore esperto non avrà neppure Interrogazioni e l’inseritore semplice non avrà neppure Controllo.

 

 

Possibilità di personalizzazione dinamica dei layout

 

Si è aggiunta la possibilità di integrare nelle interfacce del sistema di data entry un proprio logo aziendale, tramite il semplice caricamento (upload), di un file immagine locale, da selezionare tramite una procedura standard che consente di sfogliare le cartelle nel proprio computer. Si consiglia di utilizzare immagini non molto alte, per evitare di rubare spazio all’applicativo. Per lo stesso motivo è possibile per il progettista definire se l’immagine personalizzata debba essere visibile solo nella home page, in tutto il data entry oppure nasconderla.

 

Per quanto riguarda la possibilità di indicare dei campi specifici per utenti esperti, è stata implementata la possibilità di indicare i campi e il colore per evidenziarli. Riguardo alla possibilità di nasconderli agli inseritori semplici si è preferito semplicemente inibirli. Perché nell’impostazione grafica delle schermate è fondamentale la posizione e la sequenza dei campi. Deve quindi seguire il più possibile quella che è la grafica dell’eventuale cartaceo da cui reperire i dati. Nascondere quindi alcuni campi potrebbe confondere l’inseritore, inoltre può essere formativo per l’inseritore semplice vedere come l’esperto riempie i suddetti campi.

La possibilità di indicare i campi quali riservati ad utenti esperti non è stata considerata per i campi di tipo scelta multipla, ossia check box, e scelta singola, ossia radio button, in quanto, per loro stessa natura queste tipologie di campi sono i più semplici ed intuitivi da utilizzare, di conseguenza non rientrano nell’ipotesi di campo riservato solo per esperti.

La possibilità di indicare per ciascun campo del testo ulteriore è stata implementata cercando di evitare un caotico riempimento delle schermate. Si è previsto un campo nelle opzioni avanzate in cui si può specificare un testo esplicativo, questo testo viene visualizzato nel momento in cui ci si posizione con il mouse sul campo interessato dell’interfaccia. In questo modo la schermata resta pulita e l’informazione è disponibile nel caso sia richiesta. Con questa modalità il testo viene anche catturato dai programmi di lettura per non vedenti.

Nelle opzioni avanzate, nel caso di campi a scelta multipla, è possibile definire per ciascuna voce, una etichetta distinta.

 

Per facilitare e velocizzare la creazione di campi “simili” a quelli già definiti, si è implementata una funzionalità che consente di “duplicare” un campo. In pratica una volta definito un campo Nome, per esempio, ed averne definito le caratteristiche, lunghezza, tipo ecc, è possibile definire un campo Cognome, semplicemente cliccando sul pulsante Duplica, a quel punto è sufficiente indicare quelle che sono le caratteristiche che vanno ovviamente modificate che sono appunto il nome del campo e la posizione.

 

Per supporto all’utilizzo del sistema di data entry si è implementata la possibilità di definire una guida. L’amministratore, può quindi caricare un file, in formato pdf, dove spiega come va svolto l’inserimento dati, poiché è stato ritenuto che tale guida potrebbe essere modificabile in momenti successivi, tale operazione è stata implementata nella parte di applicativo da utilizzare successivamente alla progettazione. Quindi in qualsiasi momento l’amministratore potrà cambiare il file della guida di riferimento, anche durante il lavoro degli operatori.

 

 

 

Gestioni controlli

Per i controlli sono state implementate le politiche definite in fase di analisi. Si è ritenuto opportuno lasciare separata la parte di gestione semplice con quella avanzata dei controlli. Questo per consentire un facile utilizzo del sistema a chi ha necessità più semplici, lasciando l’approfondimento della parte avanzata solo a coloro che lo riterranno necessario. Inoltre i controlli sono stati poi implementati sotto due forme:

· In javascript: per un immediato riscontro appena si esce dal campo controllato, in questo modo compare una finestra di avviso con il relativo errore.

· In PHP: per consentire il controllo anche nel caso in cui l’utente avesse disabilitato i javascript. Questa modalità inoltre è a disposizione degli utenti supervisori, i quali tramite il pulsante controlla, ottengono un elenco di tutti gli errori riportati, errori che sono non bloccanti, e con un link diretto per andare alla scheda interessata.

 

È possibile indicare per un campo se il suo contenuto deve essere numerico, o letterale. Inoltre si possono indicare valori minimo e massimo, per effettuare controlli del valore immesso dall’operatore in modo che rispetti tale range.

 

 

Tracciatura del lavoro

Sono state implementate due modalità, la prima che consente di tenere sotto controllo lo stato di elaborazione del blocco in opera, la seconda che consente di rivedere tutto quanto precedentemente elaborato su uno stesso server.

È possibile in questo modo, vedere in modo semplice lo stato dell’elaborazione in corso, in modo da poter visionare l’andamento del lavoro, controllare le eventuali carenze, sapendo quanto è stato fatto da un utente semplice, e quanto da quello esperto e prevenire i tempi di conclusione del lavoro.

Con la seconda modalità si possono stabilire delle stime sui tempi di lavorazione completa dei blocchi e programmare con maggiore precisione la suddivisione dei compiti e dei lavori, essere a corrente dell’evoluzione delle capacità degli utenti ed eventualmente modificarne i compiti.

 

 

Trascrizioni audio

La nostra esperienza diretta nell’utilizzo di produzione dell’applicativo e nell’incontro con l’utenza in eventi come HANDImatica2008 ha evidenziato come, nonostante la completa accessibilità dell’applicativo, esso fosse carente dal punto di vista delle possibilità di utilizzo e lavoro per le persone non vedenti.

Questo ci ha stimolati nell’ideare, progettare e realizzare un componente aggiuntivo che possa portare questa possibilità. Le caratteristiche dell’idea sono appunto: accessibilità, telelavoro, facilità di utilizzo e possibilità reale di applicazione da parte dei non vedenti.

A tal proposito abbiamo riscontrato che una delle possibilità di impiego potrebbe essere quella di sfruttare gli altri sensi, che sono molto ben sviluppati e funzionanti, in particolare l’udito e la capacità di interpretazione e utilizzo della tastiera in modo quasi automatico.

Si tratta di un componente che consente di trascrivere dei file audio in forma testuale. Attraverso l’applicativo è possibile caricare dei file audio in formato mp3, largamente il formato più comune, questi possono essere per esempio delle registrazioni di una conferenza, o di una riunione o di una lezione. A quel punto selezionato l’audio su cui si vuole lavorare, si può ascoltarlo, con la velocità scelta, attraverso il player e nel campo sottostante si può trascrivere quanto ascoltato. Successivamente è possibile riguardare tutti gli elaborati già svolti per un eventuale integrazione.

Come tutto l’applicativo, la sua accessibilità e la sua tecnologia consentono uno sdoppiamento temporale e geografico delle parti in causa, realizzando il telelavoro.


Test

Il sistema è stato installato e testato sui nostri server web. Abbiamo implementato sull’applicativo alcuni data entry di nostre lavorazioni. Si è inoltre richiesto a persone esterne di valutarne la comprensione e la facilità di utilizzo.