Prenotazione di posti in ambienti ad accesso contingentato (nuovo esperimento) #4
Closed
opened 3 years ago by benjoamin
·
15 comments
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
All'esito dell'incontro informale del 5 ottobre 2020, organizzato tramite la chat unificata e tenutosi in Caserta alla Via Sandro Botticelli;
vista la delibera n. 4 dell'Assemblea dei Soci n. 1 del 10 aprile 2020, nella parte in cui è indicato che il presente laboratorio «avrà l’obiettivo di creare o adattare, senza fini di lucro, strumenti informatici liberi (FLOSS) di pubblica utilità, sopperendo a servizi carenti o inesistenti ovvero migliorando quelli già disponibili»;
vista la delibera n. 5 dell'Assemblea dei Soci n. 2 del 28 aprile 2020, a mente della cui lettera c) «il LUGCE potrà organizzare attività di supporto informatico al fine di sostenere la gestione dell’emergenza sanitaria in corso»;
rilevato che dal 5 ottobre 2020, per ragioni di contenimento dell'epidemia da SARS-CoV-2, è stato possibile accedere alla Biblioteca Comunale di Caserta "Alfonso Ruggiero" soltanto previa prenotazione a mezzo e-mail
(si segnala che, al momento, la Biblioteca non è comunque accessibile)[1];considerato che il suddetto sistema appare oltremodo macchinoso e pericoloso sotto il profilo della tutela dei dati personali degli utenti;
considerato che la creazione o l'adattamento di uno strumento informatico (FLOSS) di prenotazione di posti in ambienti ad accesso contingentato potrebbe sopperire alla supposta carenza dell'attuale servizio di prenotazione messo a punto dal Comune di Caserta;
ravvisata, nell'ottica di un contingentamento finalizzato al contenimento dell'epidemia suddetta , la pubblica utilità di uno strumento informatico di regolazione degli accessi;
rilevato che l'esigenza di mettere a punto uno strumento informatico di regolazione degli accessi è stata manifestata, sia pure per altri fini, anche in una proposta apparsa sul forum (attualmente non operativo);
rilevato che il regolamento di questo laboratorio non è stato ancora adottato, come da issue #2;
propongo la creazione o l'adattamento di uno strumento informatico (FLOSS) di prenotazione di posti in ambienti ad accesso contingentato, con lo scopo di predisporre una soluzione operativa in grado di migliorare - in questo periodo difficile - l'esperienza degli utenti
delle biblioteche pubbliche e, in particolare (ravvisatane la specifica esigenza), di quella di Caserta[2].per me è un progetto fattibile. vanno delineate meglio le esigenze e lo scopo del software. qualche dettaglio in più ?
La immagino come una PWA.
L'utente deve registrarsi indicando il proprio nome e cognome, comune di residenza, e-mail e password.
Una volta effettuato l'accesso come utente è possibile visualizzare un menù del seguente tipo:
Nella sezione prenota è possibile prenotare un posto in una stanza specifica per un tempo determinato. Assegnato il posto, con ogni prenotazione è rilasciato un 'codice prenotazione' di massimo 5 caratteri alfanumerici (senza distinzione tra maiuscolo e minuscolo).
Una volta effettuato l'accesso come controllore è possibile visualizzare un menù del seguente tipo:
L'amministratore può impostare i vari parametri della piattaforma.
L'utente, prenotato il posto e ricevuto il 'codice prenotazione', si deve presentare in biblioteca all'orario indicato nella prenotazione ed effettuare il check-in. Il check-in consiste nell'inserimento da parte del controllore del 'codice prenotazione' nell'apposita casella. Una volta inserito il codice, il nominativo e il comune di residenza dell'utente sono inseriti nell''elenco accessi'. La prenotazione scade automaticamente se non è effettuato il check-in entro 30 minuti dall'orario indicato per l'accesso e il posto viene liberato.
È consentito effettuare una prenotazione per volta (per l'intera giornata o anche per una porzione della giornata). Una volta effettuato il check-in è possibile prenotare un'accesso. Se ci sono posti in biblioteca è possibile, senza effettuare una nuova prenotazione, prolungare la propria permanenza.
Questo è quello che mi è venuto in mente, per ora!
io sono favorevole alla creazione di questo progetto.
Dobbiamo solo decidere metodo, tecnologie da usare e finire di sviscerare il progetto.
vediamo gli altri che dicono
Ho provato a ricostruire mentalmente il progetto in questo modo. L'indicazione della 'Biblioteca' è fatto solo per semplicità, in modo da rendere l'idea più concreta. Il software, in effetti, potrà senz'altro essere impiegato pure in altri ambiti.
Utenti
Tre livelli di accesso:
Utilizzatore
L'utilizzatore è il soggetto che intende prenotarsi per fruire di uno spazio presso la Biblioteca per consultare volumi o studiare.
Per frurie del servizio è necessario registrasi, indicando i seguenti dati:
Menù
Una volta effettuato l'accesso, l'utilizzatore è rinviato alla propria area riservata, così strutturata:
Profilo
In questa sezione l'utilizzatore può visualizzare e rettificare i propri dati, inseriti in fase di registrazione, nonché cancellare l'account.
Cronologia
In questa sezione l'utilizzatore può visualizzare l'elenco delle prenotazioni effettuate, divise in 'attive' e 'scadute' (cioè già utilizzate o comunque non in uso). Le prenotazioni 'attive' sono contrassegnate con un simbolo quando è stato effettuato il check-in (di cui in seguito).
Cliccando su una prenotazione 'attiva' è visualizzato un QR contenente il 'codice prenotazione' (sequenza alfanumerica di 5 caratteri, indifferente se maiuscoli o minuscoli), il quale è visualizzato in chiaro sotto il QR.
In tale sezione l'utilizzatore può cancellare la propria prenotazione. Una volta cancellata la prenotazione, questa si considera 'scaduta' e sarà possibile possibile prenotare nuovamente.
Prenota
In questa sezione l'utilizzatore visualizza un elenco delle aule presenti in Biblioteca, ognuna contraddistinta da un identificativo e recante il numero totale dei posti, di quelli 'occupati' e di quelli 'liberi'.
L'utilizzatore, per prenotarsi, dovrà selezionare l'aula desiderata, quindi scegliere il giorno e una 'fascia oraria' per l'ingresso e una per l'uscita. Le fasce orarie sono di mezz'ora ciascuna.
È consentita una sola prenotazione per volta. Il sistema di prenotazione si 'sblocca' appena l'utilizzatore effettua il check-in, ma eventuali prenotazioni effettuate subito dopo il check-in sono automaticamente cancellate se l'utilizzatore non effettua il check-out (di cui in seguito).
Verifica
In questa sezione sono visualizzate le informazioni relative all'ultima prenotazione di cui è stato effettuato il check-in, in particolare:
Controllore
Il controllore è un 'utilizzatore' con peculiari privilegi e responsabilità, esegue i check-in e i check-out e si assicura che gli utenti che abbiano effettuato il check-out si siano effettivamente allontanati definitivamente dalla struttura.
Menù
In controllore ha il medesimo menù di un qualsiasi utilizzatore, con l'aggiunta delle seguenti sezioni:
Check-in
Nella sezione 'check-in' sono presenti un campo per la digitazione manuale del 'codice prenotazione' e un pulsante per attivare la lettura automatica del QR tramite telecamera/webcam (tale ultima funzione potrà essere implementata anche in seguito, in quanto non essenziale).
Una volta inserito il 'codice prenotazione' (mediante digitazione manuale o lettura automatica), il software risponde con un segnale acustico e restituisce una delle seguenti informazioni:
Il 'codice prenotazione' scade automaticamente 15 minuti dopo il termine della 'fascia oraria' indicata per l'ingresso.
Check-out
Nella sezione 'check-out' sono presenti un campo per la digitazione manuale del 'codice prenotazione' e un pulsante per attivare la lettura automatica del QR tramite telecamera/webcam (tale ultima funzione potrà essere implementata anche in seguito, in quanto non essenziale).
Una volta inserito il 'codice prenotazione' (mediante digitazione manuale o lettura automatica), il software risponde con un doppio segnale acustico e restituisce una delle seguenti informazioni:
Il check-out è eseguito automaticamente a tutti coloro i quali non l'abbiano già effettuato 10 minuti dopo lo scoccare dell'ora in cui la Biblioteca chiude al pubblico. Se il check-out non è eseguito prima di tale termine, le nuove prenotazioni eventualmente effettuate sono cancellate e sono considerate 'scadute'.
Amministratore
L'amministratore non è un 'utilizzatore'. Solo l'amministratore può visualizzare l'elenco - aggiornato in tempo reale - delle persone che hanno effettuato il check-in. Le persone la cui prenotazione è 'in scadenza' sono evidenziate in arancione. Le persone che hanno già effettuato il check-out sono evidenziate in rosso.
A fini statistici, l'amministratore ha altresì accesso a un database contenente le seguenti informazioni sugli accessi giornalieri:
Menù
L'amministratore ha accesso alle seguenti sezioni:
Pannello di controllo
Nel pannello di controllo è possibile modificare alcune variabili necessarie al funzionamento del software, quali - ad esempio:
Situazione in tempo reale
In questa sezione è visualizzato un elenco delle aule presenti in Biblioteca, ognuna contraddistinta da un identificativo (o denominazione) e recante il numero totale dei posti, di quelli 'occupati' e di quelli 'liberi'.
Cliccando su una specifica aula è possibile visualizzare l'elenco - aggiornato in tempo reale - delle persone che hanno effettuato il check-in in quella giornata. Le persone la cui prenotazione è 'in scadenza' sono evidenziate in arancione. Le persone che hanno già effettuato il check-out sono evidenziate in rosso.
Elenco accessi
In questa sezione è presente il database contenente le informazioni sugli accessi giornalieri. È presente una specifica opzione per esportare selettivamente le informazioni in esso contenute (in base al giorno o i giorni selezionati).
perfetto. ora dobbiamo capire gli altri come vogliono procedere (linguaggio da utilizzare) e se procedere (se approvano questo progetto). come gia detto..io sono favorevole
Mi piace l'idea e anche il design di Benjamin.
Ho esperienza solo con i game engine, ma non mi dispiacerebbe dare una mano in un progetto del genere, per cui al momento mi limito a dichiararmi favorevole, per le scelta delle tecnologie da utilizzare lascio parlare gli altri, al limite si fa un dev meeting per affrontare proprio questo argomento.
Ciao,
L'idea in generale mi piace molto per cui sono favorevole.
Per quanto riguarda il livello "utilizzatore" dovrebbe essere previsto se non erro per il GDPR una sezione in cui oltre a cancellare l'account l'utente può scaricare i suoi dati personali e le informazioni scambiate con il sito in un formato accessibile. Basta un semplice CSV o TXT, o JSON se fa comodo generarlo in quel formato.
Nel caso specifico del software in questione potrebbe trattarsi del numero di volte che si è fatto login alla piattaforma, dell'indirizzo IP se registrato (anche solo nei log) e la storia delle prenotazioni fatte.
Come già in molti sanno, con un discreto quanto prevedibile e scontato 😂 tempismo elettorale, segnalo che la Biblioteca Ruggiero è stata appena riaperta.
Tuttavia, come già espresso, anche se l'idea del progetto nasce in relazione alla specifica contingenza locale, si tratta di una soluzione applicabile ai più disparati contesti, configurata in qualità di piattaforma generica e dinamica per le prenotazioni.
Potremmo limitare i dati a quelli essenziali ai fini della registrazione (email e password) e prevedere la possibilità di rendere ulteriori dati mandatori o addizionabili (ad esempio il numero di telefono).
Allo stesso modo, tutti i vincoli possono essere parametrici (impostabili dall'amministratore).
Senza entrare troppo nel tecnico in questa fase, mi limito a riportare uno dei problemi più significativi da risolvere in fase di analisi, tra quelli emersi dal confronto avuto con @benjoamin nel corso dell'ultimo Tarallucci&Linux, ovvero la difficoltà nel riuscire a gestire il controllo effettivo dei check-out in assenza di tornelli fisici.
Se l'obiettivo di un sistema di prenotazioni è quello di evitare che il numero di persone effettivamente presenti in una struttura sia limitato al suo massimo, occorre che le persone non autorizzate non permangano all'interno oltre il tempo a loro concesso, pena il sovraffollamento.
Essendone co-promotore non posso che essere d'accordo e procederei subito alla creazione di un repository di laboratorio dedicato, in cui poter, tra le altre cose, definire dettagli tecnici, progettuali ed implementativi.
L'unico tassello mancante è la scelta di un nome o anche un codename da assegnare al progetto.
Ne suggerisco qualcuno attiggendo dal latino:
Ovviamente possono anche essere declinati come meglio possano suonare, come ad esempio addixit, oppure seponit.
Altrimenti qualcosa di più semplice come riservo, decisamente più immediato.
Se per voi va bene quest'ultimo procedo con la creazione del repository, altrimenti resto in attesa di suggerimenti.
Sotto il profilo legale dovrebbe bastare dare la possibilità all'utente di chiedere i dati che lo riguardano, ma senz'altro una soluzione automatizzata può essere utile e di certo più immediata!
Sì, senz'altro. Come detto in premessa, per rendere il progetto più 'facilmente immaginabile', l'ho pensato già implementato in Biblioteca.
Dopo la nostra discussione ho pensato che la soluzione più immediata e di facile implementazione (senz'altro migliorabile in futuro) non può che basarsi sull'intervento umano, per tali ragioni:
Perfetto, manca solo il consenso del terzo responsabile, che può anche manifestarsi con una reazione positiva al primo post.
Ci stavo pensando anche io! Non so se 'riservo' possa ingenerare antipatie a causa della presenza della parola 'servo'. Io avevo pensato a roulette o vertigo ('rotazione' in latino).
In ogni caso, se non dovesse raggiungersi un accordo sul nome prima della registrazione del terzo assenso, andrà bene utilizzare 'riservo'.
Di sicuro avremo modo di ragionarci meglio su in fase di progettazione.
Già, avevo pensato anche io ad una possibile deriva politically correct, ma in questo caso non penso proprio abbia a che fare con la parola “servo”, ma suppongo derivi da “servare”, dunque “conservare”.
Anche quest'ultimo mi piace, soprattutto per il riferimento cinematografico :)
Sarebbe in ogni caso meglio verificare che non esistano già in circolazione software commerciali omonimi.
Procedo ad un sollecito.
Sono favorevole all'iniziativa. Ritengo utile ed interessante avere una soluzione - applicativo - che permetta la gestione/prenotazione di posti in luoghi ad accesso contingentato. E credo che la questione COVID sia per l'appunto solo un argomento accessorio che ne sottolinea la necessità, anche in situazioni ordinarie.
Il design lo trovo sufficientemente chiaro e generale per offrire svariate soluzioni all'utilizzatore.
Non saprei cosa suggerire per quanto concerne il tema del linguaggio di programmazione, o comunque del framework da utilizzare... ma riservatemi una simpatica reference:
PHP7Hai ragione. andiamo di PHP8
Salve a tutti ragazzi,
sicuramente mi piace l'idea e stranamente c'é anche carenza di uno strumento FOSS degno di esser chiamato tale che gestisca questo tipo di problematica.
Siamo appunto in una fase pre-embrionale dove è necessario pensare, proporre, discutere per avvicinarci poi alla fase esecutiva una volta reso "shaped" ovvero definito in tutte le sue parti e carichi di lavoro distribuiti su ognuno di noi che vuole contribuire; infatti, nonostante @benjoamin abbia fatto un ottimo lavoro redazionale di Overview, non abbiamo di fatto nessun documento tecnico che descriva l'architettura software, e iniziare a lavorarci senza aver delineato ogni minimo dettaglio sarebbe un grosso errore secondo me.
Vorrei che fosse ben chiaro già da subito il punto di arrivo e di partenza dell'idea (non esiste sviluppare un qualcosa di dichiaratamente aperto a future integrazioni, mi spiego meglio, ok che in futuro si potranno integrare funzionalità e/o moduli per la natura del buon codice che scriveremo, ma in partenza deve essere messo su carta nella sua interezza, cioè alla partenza deve essere tutto chiuso e delineato e si sviluppa finché non si é raggiunto il punto di arrivo con gli standard qualitativi definiti in partenza; alias il punto di arrivo non può migrare o spostarsi in corso d'opera, altrimenti personalmente impazzisco perché vuol dire che non abbiamo fatto un buon lavoro di Progettazione), senza lasciare nulla al caso o allo spirito di iniziativa individuale, ci terrei molto (come già anticipato nella call di Tarallucci e Linux di giovedì scorso) a non fare l'ennesima App/Servizio che venga utilizzata da pochi eletti e che rimanga poi nell'oblio delle App che nessuno usa; vorrei che si delineasse un'idea concreta, innovativa e tecnlogicamente avanzata, ma soprattutto scalabile; al day one dobbiamo esser già pronti per una scala nazionale per come la vedo io e non creare un prototipo mezzo funzionante o magari applicabile ad una sola realtà locale ma un Servizio di altissimo livello qualitativo che possa risonare a livello Nazionale per la sua funzionalità, efficacia e perché no indispensabilità.
Per farlo abbiamo bisogno sicuramente di tempo, fantasia, idee innovative e tanta organizzazione, ma soprattutto dobbiamo puntare ai linguaggi più innovativi possibile, tecnologicamente avanzati, recenti, buttando via tutto ciò che conosciamo di canonico (come Php e Mysql, viaaa! ovviamente ne parleremo e valuteremo in base alle proposte ed esigenze... ma l'idea di base deve essere l'innovazione); per me se si deve fare questo, come altri progetti futuri, si deve pensare nel modo più generico ed accessibile possibile, si deve creare un App di altissimo livello, altrimenti meglio non fare niente.
Ciò detto vorrei riassumere alcuni punti che per me andrebbero posti alla base dei presupposti per la realizzazione di tale progetto, scusate se alcuni possono risultare scontati per molti di voi, meglio chiarirli comunque:
tutto verrà delineato nei minimi dettagli, analizzando ed individuando per ognuno dei partecipanti compiti specifici da portare a termine con tempi sostenibili e ragionevolmente legati al best effort di ognuno
nessuna commit di scrittura notturna individuale, per quanto valida, verrà accettata; sono contro i furiosi assoli non richiesti (e magari anche con in un linguaggio non concordato)
Il progetto deve essere libero da qualsiasi implicazione politica locale o nazionale; non potrà dunque essere vittima di alcuna pubblicità né orale né scritta su qualsiasi mezzo informativo (giornali, social etc) da parte di altre associazioni, enti, partiti politici, politicanti, aziende..etc; nessuno dovrà farsi pubblicità su di noi poiché noi lavoriamo per il bene comune e i nostri sforzi professionali sono sempre apartitici, apolitici e disinteressati alla ad interessi di notorietà e/o pubblicità propagandistica. Mi dispiace dover chiarire questo punto ma dato che esistono dei precedenti, dato che la nostra Associazione si trova spesso impigliata in questioni di politica locale, rischiando un forte conflitto di interessi ogni volta, preferisco metterlo nero su bianco fin da subito.
Per quanto mi riguarda questo Issue è già troppo incentrato su di essa, e sono già troppi i riferimenti quindi la nominerò spero per l'ultima volta ma solo per chiarire: ben venga in un futuro anteriore che la Biblioteca usufruisca del Servizio creando la propria stanza e gestendo le proprie code, bene anche che l'idea sia nata da un'esigenza concreta nella nostra realtà locale, ma ora per favore dimentichiamocela tutti perchè né Noi né il Progetto abbiamo nulla che ci lega ad essa, dobbiamo dimenticarcene tutti subito.
Ovviamente aprire un Repo è il primo indispensabile passo per aprire il dialogo, quindi se per tutti vanno bene le mie premesse salgo a bordo anche io dichiarandomi eventualmente favorevole alla creazione di questo progetto!
Tali incombenze potranno senz'altro essere disbrigate nel repository che sarà creato ad hoc. Obiettivo di quest'issue è la mera approvazione del 'progetto' inteso come 'idea astratta da realizzare'.
Tutto ciò potrà essere implementato nel regolamento del laboratorio (di cui all'issue #2). Al riguardo è già presente il check 'modalità di lavoro'. Ovviamente, nelle more dell'approvazione, i responsabili dovranno farsi carico del coordinamento del lavoro, senza porre però in secondo piano e tenendo in debito conto le esigenze e le proposte dei volontari che intendano partecipare al progetto.
Ovviamente non possiamo impedire comportamenti che sfuggono al nostro domino, ma senz'altro la posizione di LUGCE sul punto è netta, pertanto ogni 'uscita fuori luogo' sarà senz'altro segnalata e corretta con vigore.
Si tratta di un progetto indipendente e, come tale, svincolato da qualsiasi logica partitica o di collaborazione con altri gruppi organizzati. Come ripetuto più volte nell'ambito di questa discussione, il rifermento alla Biblioteca Comunale è stato esclusivamente spunto e motivo di riflessione. Per rendere ancora più marcata tale condizione, ne sarà espunto ogni riferimento (che non compaia nella premessa) dalla proposta in testa a questo issue.
Quanto alla 'politicità' del progetto, dal tenore del tuo commento comprendo benissimo ciò a cui ti riferisci e sono senz'altro d'accordo. Mi preme tuttavia precisare (pur sapendo che tale circostanza non è messa in discussione dal tuo intervento) che tutti i progetti di LUGCE sono 'politici', in quanto LUGCE è una associazione che nasce con l'obiettivo di affermare una certa visione del mondo, radicata nella filosofia del software libero e dei relativi corollari. Per tale ragione ogni progetto di LUGCE è politico nel senso che è volto all'affermazione della filosofia del software libero, mendiante la sua promozione e diffusione.
Assolutamente! Una volta creato il repository il presente issue verrà chiuso e ogni ulterire discussione in merito potrà proseguire esclusivamente in quella sede.
Essendo stato raggiunto il consenso richiesto (unanimità dei responsabilità del laboratorio), il progetto è approvato!
Quanto al codename, per il momento 'Vertigo' è quello che ha riscosso maggiore successo, pertanto il repository potrà essere aperto con tale nome. Ciò non esclude che il progetto potrà cambiare denominazione nel tempo qualora emergano giuste ragioni.
Iniziamo!