CodicePlastico si occupa, ormai da più di 10 anni, di progettazione e sviluppo software, coniugando competenze tecnologiche e realizzazione di applicativi, tipicamente mediante l’utilizzo del codice. Codice che diventa un materiale modellabile, in grado di adattarsi per dare forma alle esigenze delle aziende.
Questo approccio ha portato a soluzioni altamente personalizzate, ma spesso richiede tempo, risorse e conoscenze tecniche approfondite e, in un mondo in cui la rapidità di sviluppo e la flessibilità sono sempre più importanti, è fondamentale guardarsi attorno, conoscere ed essere in grado di trarre beneficio dalle nuove tecnologie e dagli strumenti che nascono ogni giorno.
A questo proposito, nel periodo da Settembre a Dicembre 2023, abbiamo lavorato in piccoli team a progetti di formazione specifici. Si tratta di un esperimento che ha l’obiettivo di rendere più efficace e formalizzato il tempo che dedichiamo ad imparare cose nuove e a conoscere nuove tecnologie e strumenti che si stanno rivelando interessanti.
Ognuno ha avuto la possibilità di proporre un tema, un corso, una certificazione o un progetto reale sul quale formarsi, in solitaria o insieme ai colleghi che volessero unirsi.
Io e Mariachiara abbiamo deciso di proporre la realizzazione di un progetto No-code mediante l’utilizzo di Bubble.io.
Cos’è Bubble.io?
Bubble.io è una piattaforma di programmazione visiva senza codice. È progettata per aiutare a creare software e applicazioni utilizzando grafica e immagini per esprimere la logica informatica, anziché fare affidamento esclusivamente sulla rappresentazione basata su testo.
La piattaforma è full-stack per progettazione, sviluppo e hosting senza codice ed è completamente personalizzabile: supporta un design completamente responsive e consente di definire ogni passaggio del flusso di lavoro, parametro di ricerca e campo del database.
Bubble dispone di un ecosistema di plugin e di un API connector che semplificano la connessione a servizi esterni. E’ basato su AWS e monitora e migliora costantemente la sua piattaforma.
Perché usarlo?
In CodicePlastico, per il processo di design utilizziamo Figma. In questa fase è fondamentale comunicare con clienti e stakeholders per capire le esigenze e ottenere feedback, utilizzando prototipi interattivi che permettano di navigare i flussi realizzati e testare l’esperienza. Strumenti di progettazione come Figma sono, però, limitati e non consentono di andare oltre la fase di design. Per questo motivo abbiamo iniziato a valutare strumenti No-code che consentissero di sviluppare senza codice e, dopo un po’ di ricerca, la scelta è ricaduta su Bubble.io, da utilizzare nel nostro caso in particolare, per:
- Lavorare a piccoli progetti: Una delle principali motivazioni per l’uso di Bubble.io è stata l’intenzione di esplorare uno strumento che potesse essere facilmente adottato in progetti di dimensioni contenute. Questo ci ha permesso di valutare come questa piattaforma potrebbe essere utilizzata in situazioni in cui la complessità e la portata del progetto sono limitate.
- Creare prototipi interattivi: La capacità di creare prototipi interattivi è fondamentale per la fase di design e sviluppo di qualsiasi applicazione. Bubble.io ci ha fornito un ambiente visuale per rapidamente tradurre le nostre idee in prototipi funzionali, migliorando la comunicazione interna e con le parti interessate.
- Lanciare progetti in poco tempo e iterare velocemente: Bubble.io offre la possibilità di sviluppare applicazioni web in tempi rapidi, permettendo di testare e affinare le soluzioni più velocemente rispetto a un tradizionale sviluppo basato su codice. Questa agilità è diventata una delle principali motivazioni per la nostra sperimentazione.
Obiettivi
Durante il progetto di sperimentazione, abbiamo definito alcuni obiettivi chiave che intendevamo raggiungere:
- Creare un’applicazione completa: L’obiettivo principale era quello di essere in grado di creare un’applicazione web completa con tre componenti principali: l’interfaccia utente, l’architettura dati e i workflow. Questo ci ha permesso di valutare la completezza e la flessibilità della piattaforma.
- Integrare un sistema di autenticazione: L’integrazione di un sistema di autenticazione è fondamentale per molte applicazioni. L’obiettivo era testare l’abilità di Bubble.io nell’implementare questa funzionalità in modo efficace.
- Verificare le funzionalità responsive: in un’era in cui gli utenti accedono alle applicazioni da dispositivi diversi, è cruciale che un’applicazione sia responsive. Abbiamo voluto verificare la capacità di Bubble.io di gestire l’adattamento dell’interfaccia utente a diverse dimensioni di schermo.
- Verificare le integrazioni con sistemi esterni mediante API e/o plugin: Le integrazioni esterne sono spesso essenziali per le applicazioni. Volevamo valutare quanto fosse semplice integrare sistemi esterni utilizzando API o plugin.
Creare una app per la prenotazione dei posti in ufficio: tutorial
Dati gli obiettivi sopra elencati, durante il periodo di formazione abbiamo deciso di realizzare una piccola applicazione ad uso interno per dipendenti e collaboratori di CodicePlastico: un’app per la prenotazione delle postazioni in ufficio, integrata con Google Calendar. Ecco come l’abbiamo realizzata.
Struttura dell’applicazione
Pagine
Partiamo dalla struttura. Una volta creata l’applicazione su Bubble, abbiamo aggiunto tre pagine principali:
- Login: pagina per effettuare il login o il signup con Google.
- Index: corrisponde alla sezione principale dell’app, dalla quale l’utente può prenotare una postazione per un giorno specifico.
- Booking: da qui l’utente potrà visualizzare le prenotazioni effettuate, future e passate.
In aggiunta a queste, ci sono le pagine Reset_pw, per resettare la password, e 404, pagina di reindirizzamento in caso di errore.
In questo tutorial ci focalizzeremo sull’implementazione delle funzionalità principali dell’app, non approfondendo le feature secondarie o la personalizzazione dell’interfaccia.
Database
Iniziamo a strutturare il nostro database. Questo si può fare dal tab Data types, creando i Data types necessari. Una volta creata la struttura, il database sarà visibile nel tab App data:
Torniamo in Data types e cominciamo!
Guardando alla struttura dati, abbiamo creato i Data types:
- Image, con i seguenti Fields
- image di tipo image
- name di tipo text
- Postazione, con i seguenti Fields
- image di tipo Postazione (option set)
- name di tipo text
- Prenotazione, con i seguenti Fields
- data prenotazione di tipo date
- id di tipo text
- postazione di tipo Postazione (data type)
- user di tipo User (data type)
- User, con i seguenti Fields
- name di tipo text
- surname di tipo text
Inoltre, tutti i Data type hanno alcuni fields forniti di default da Bubble, tra cui:
- creator di tipo User
- modified date di tipo date
- created date di tipo date
- slug di tipo text
- email di tipo text
Option sets
In aggiunta, abbiamo creato un option set per le postazioni:
Questo option set ha Image (di tipo image) e Name (di tipo Postazione, data type) come attributi e le opzioni corrispondono alle nostre quattro postazioni.
Perché usare gli option sets?
Di default, l’applicazione è composta da due ambienti separati con due database indipendenti: Development e Live. Esistono in parallelo in modo che si possa continuare a sviluppare l’applicazione senza che l’app live cambi. Una volta completate le modifiche nell’ambiente di sviluppo, possono essere inserite in Live tramite il Deploy.
Contrariamente al Database, che su Bubble deve essere ricreato in Live (ciò che è stato inserito in Development non va automaticamente Live), gli Option sets vengono caricati automaticamente. Per questo motivo, essendo le nostre postazioni (e relative immagini) statiche, metterle come opzioni ci consente di non doverle reinserire successivamente quando manderemo Live.
Plugin utilizzati
Portiamoci avanti installando i plugin che ci servono.
In questo caso, abbiamo utilizzato il plugin gratuito Calendar for Google di Zeroqode.
Questo plugin, tra le varie funzionalità, consente di gestire il login/signup con Google e creare e cancellare eventi direttamente su Google calendar.
Una volta installato il plugin dalla sezione Plugins di Bubble, è necessario inserire le keys richieste per connettere l’app ad un account Google:
Trovate la documentazione completa nella guida di Zeroqode.
Una volta installato il plugin per integrare Google nella nostra app, possiamo procedere con la progettazione.
Introduzione al flusso di lavoro
E’ il momento di allestire le pagine. Bubble.io ragiona in due step: uno visuale (modalità Design) dove, con un editor drag&drop, è possibile inserire e customizzare gli elementi della pagina e uno funzionale (Workflows), dove è possibile indicare logiche e interazioni dei diversi elementi.
In modalità Design ogni elemento è configurabile a livello di Appeareance (colori, font e visual generale), Layout e Conditional, dove indicare i comportamenti specifici degli elementi come la gestione degli errori o le interazioni sugli eventi:
Il Workflow è l’anima funzionale dell’applicazione. Definisce cosa deve accadere quando l’utente interagisce con un elemento:
Pagina Login
Trattandosi di un’applicazione ad uso interno, abbiamo implementato solamente l’autenticazione con Google Calendar, per login e signup. Di seguito i passaggi dei workflow implementati.
Signup
Quando il bottone Signup viene cliccato:
la prima azione è il signup con Google Calendar. Successivamente andiamo a modificare il Current user assegnandogli come Name il valore inserito nell’input del campo “Nome”:
Lo stesso viene fatto per il Surname:
e infine l’azione
Go to page Indexper mandare l’utente alla sezione in cui prenotare la postazione.
Login
Nel caso in cui l’utente abbia già creato l’account, cliccherà direttamente sul Login. L’azione da implementare è sempre la stessa, ma questa volta non andiamo a modificare alcun campo del Current User:
Infine, per concludere i workflow della pagina Login, quando la pagina viene caricata e l’utente è già loggato, aggiungiamo un:
Go to page Index
Pagina Index
La pagina Index è composta da:
- Header, dal quale è possibile raggiungere la pagina delle prenotazioni ed effettuare il Log out.
- Group Page, all’interno del quale abbiamo:
- l’indicazione delle postazioni libere per il giorno selezionato
- il campo per la selezione della data
- il Repeating Group che mostra tutte le postazioni con lo stato Libera/Occupata e il relativo bottone per prenotare o cancellare una postazione. Inoltre, nel caso la postazione fosse occupata, viene visualizzato il nome dell’utente che l’ha prenotata.
Ma partiamo con ordine.
Header
Per realizzare l’header, trasciniamo un Floating group all’interno della pagina e fissiamolo in alto, in modo che, scorrendo la pagina, l’header resti fisso nella parte superiore:
Per quanto riguarda il layout, il container è di tipo Row e l’allineamento Space between:
Nell’header, aggiungiamo i bottoni Le mie prenotazioni e Log out, inserendoli all’interno di un gruppo di tipo Row allineato a destra.
Group Page
All’interno del Group page, aggiungiamo un gruppo di tipo Column:
Successivamente, inseriamo il testo Prenota una postazione e formattiamo come titolo.
Aggiungiamo quindi un testo statico Postazioni libere e un testo dinamico che mostri le postazioni libere sul totale, oltre a un Date/Time Picker per selezionare la data.
Per quanto riguarda il testo dinamico, sottraiamo, al conteggio delle postazioni (Search for Postaziones:count), il conteggio delle prenotazioni (Search for Prenotaziones:count) in cui la data di prenotazione corrisponde al valore selezionato nel Date/Time Picker, arrotondato al giorno (data.prenotazione= Date/TimePicker A’s value:rounded down to day). Successivamente, dividiamo questo risultato per il conteggio delle postazioni (Search for Postaziones:count):
Considerando ora il Date/Time Picker, questo deve essere di tipo Date e deve avere come contenuto iniziale la data corrente arrotondata al giorno. Assegniamogli, inoltre, una data minima corrispondente, come sopra, alla data corrente arrotondata al giorno. In questo modo i giorni precedenti al giorno corrente non saranno selezionabili:
Passiamo ora alla lista che mostrerà le postazioni e la relativa disponibilità.
Aggiungiamo un Repeating group di tipo Column al di sotto del campo data e selezioniamo il data type Postazione come Type of content.
Inoltre, implementiamo un Search for come di seguito:
Stiamo effettuando una ricerca di tutte delle postazioni, ordinandole per nome.
All’interno del repeating group, inseriamo un gruppo di tipo Row con Type of content Postazione e Data source
Current cell's Postazione
A questo punto, dopo aver aggiunto le immagini delle postazioni nell’Option set Postazione, assegniamo un valore dinamico all’immagine:
In questo modo visualizzeremo la lista di postazioni con le relative immagini.
Aggiungiamo ora, a destra dell’immagine, un gruppo Column di tipo Postazione:
al cui interno inseriamo tre gruppi.
1. Group head
Il primo gruppo contiene Group postazione nome (nome della postazione) e Group stato (stato della postazione, Libera o Occupata), che, come Group head, sono di tipo Postazione e con source Parent group’s Postazione:
All’interno di Group postazione nome, inseriamo un testo dinamico:
per visualizzare il nome della postazione, allineandolo a sinistra. Mentre, allineato a destra, abbiamo Group stato, che contiene un testo dinamico e l’icona del pallino.
In particolare, per quanto riguarda il testo dinamico, assegniamogli di default il testo “Libera” e il colore verde e, nella sezione Conditional, inseriamo la seguente condizione:
Ossia, quando la prenotazione con postazione uguale alla postazione di riferimento e data di prenotazione corrispondente al valore del Date/Time Picker è vuota, allora il testo passa da “Libera” a “Occupata” e il colore diventa rosso.
In questo modo, le postazioni che hanno una prenotazione nel giorno selezionato, verranno visualizzate come occupate.
Allo stesso modo, l’icona del pallino, che di default sarà verde, diventerà rossa quando la postazione è già prenotata:
2. Group user
Consideriamo ora il Group user, come i gruppi precedenti, di tipo Postazione e data source Parent group’s Postazione, che ha al suo interno l’icona della persona e un testo dinamico:
L’icona è di default Non visibile e ha applicata la seguente condizione, simile a quelle viste in precedenza:
Ossia l’icona è visibile quando la postazione ha una prenotazione nel giorno indicato (quando la ricerca della prenotazione non è vuota).
La stessa condizione viene applicata al testo dinamico che, di default, è vuoto e, quando la condizione è vera, mostra il nome e il cognome dell’utente che ha creato la prenotazione:
In particolare, il nome e il cognome dell’utente vengono ottenuti con una ricerca uguale a quella che definisce la condizione:
3. Group buttons
Questo gruppo contiene i bottoni Prenota e Cancella prenotazione, oltre agli alert che vengono visualizzati quando l’utente clicca uno dei due bottoni.
Inseriamo un gruppo (Group Prenotazione) all’interno di Group buttons e impostiamo il type of content e la data source, come in precedenza, per entrambi:
All’interno di Group Prenotazione, inseriamo due bottoni: Button Prenota e Button Cancella prenotazione.
Button Prenota
Il bottone per prenotare la postazione ha un testo ibrido: “Prenota” + Parent group’s Postazione’s name:
In questo modo visualizziamo il testo “Prenota [nome postazione]”.
Il bottone non è visibile on page load e collassa quando è nascosto:
Assegniamo ora alcune condizioni. Per iniziare, effettuiamo la solita ricerca per ottenere la prenotazione di una specifica postazione nella data selezionata. Quando la prenotazione è vuota, il bottone è visibile, ossia la postazione è prenotabile.
A questo punto, contiamo tutte le prenotazioni presenti nella data selezionata, in cui l’utente è il Current user. Se il conteggio è maggiore di 0, allora il bottone non è visibile:
Se la condizione è vera, significa che l’utente ha già effettuato una prenotazione nel giorno selezionato, quindi non potrà effettuarne di nuove.
Button Cancella prenotazione
Questo bottone ha il testo statico “Cancella prenotazione” e, come il bottone precedente, non è visibile on page load e collassa quando è nascosto.
Inoltre, quando la postazione ha una prenotazione effettuata dal Current user nel giorno selezionato, il bottone è visibile, quindi la prenotazione è cancellabile:
Ora che abbiamo inserito i bottoni, possiamo aggiungere le seguenti condizioni su Group Card, il gruppo principale all’interno del repeating group:
- Quando il conteggio delle prenotazioni con data corrispondente a quella selezionata e utente uguale a Current User è maggiore di 0 e il bottone Cancella prenotazione non è visibile, allora il colore di sfondo del gruppo diventa grigio con opacità 65%. Questo è il caso in cui l’utente abbia già prenotato una postazione in un dato giorno, quindi le altre postazioni risultano disabilitate:
- Quando il conteggio delle prenotazioni con data corrispondente a quella selezionata è maggiore di 0 e sia il bottone Cancella prenotazione sia il bottone Prenota non sono visibili, allora il colore di sfondo del gruppo diventa grigio con opacità 65%. Questo è il caso in cui c’è già una prenotazione nel giorno selezionato e non essendo i bottoni visibili significa che un altro utente ha già prenotato una determinata postazione (per le condizioni inserite in precedenza), quindi il gruppo appare disabilitato:
Inseriamo ora gli alert che si attiveranno in base alle condizioni che definiremo nel seguente paragrafo:
- Alert di Prenotazione effettuata, appare quando l’utente effettua la prenotazione
- Alert di Cancellazione effettuata, appare quando l’utente cancella la prenotazione
Per Entrambi gli alert spuntiamo Position the alert at the top in modo che si posizionino in alto:
Index Workflows
Una volta aggiunti tutti gli elementi necessari possiamo procedere alla creazione dei workflows per l’implementazione del flusso:
Riassumendo:
- L’utente sceglie una postazione tra quelle disponibili
- L’utente clicca il bottone Prenota, la postazione di riferimento diventa Occupata e le altre vengono disabilitate
- L’utente clicca il bottone Cancella, la postazione di riferimento diventa Libera e le altre vengono riattivate
Per cominciare, andiamo nella sezione Workflow di Bubble e aggiungiamo un nuovo evento:
Quando la pagina viene caricata e il Current user non è loggato, viene implementata l’azione Go to page login, in modo che l’utente effettui il login (o il signup):
Header workflows
Partiamo ora dall’alto e consideriamo l’header. Abbiamo tre workflow da implementare:
- Quando l’utente clicca il logo, viene rimandato alla pagina principale (Index). In questo caso ci troviamo già nella pagina Index, ma questa azione sarà utile quando realizzeremo la pagina Booking e riutilizzeremo l’header.
- Quando l’utente clicca il bottone Le mie Prenotazioni, viene rimandato alla pagina Booking, dove potrà visualizzare le prenotazioni effettuate.
- Quando l’utente clicca il bottone Logout, effettua il logout e viene mandato alla pagina login.
Iniziamo!
Dalla sezione Design di Bubble, clicchiamo con il tasto destro sul Logo e selezioniamo Start/Edit Workflow. In questo modo viene creato il workflow When Image Logo is clicked:
Aggiungiamo quindi l’azione Go to page Index, per mandare l’utente alla pagina Index quando clicca il logo:
Passiamo ora al bottone Le mie Prenotazioni, e iniziamo il workflow When Button Le mie Prenotazioni is clicked con l’azione Go to page Booking:
Ossia, quando il bottone viene cliccato, l’utente va alla pagina Booking. In particolare, aggiungiamo il check su Send more parameters to the page e definiamo un parametro p assegnandogli il testo “future”. In questo modo, stiamo passando un parametro nell’URL della pagina che ci sarà utile per visualizzare le prenotazioni future effettuate dall’utente.
Per concludere, aggiungiamo un workflow sul bottone Logout con la prima azione Log the user out e successivamente Go to page login:
In questo modo, quando l’utente clicca il bottone Logout, effettua il logout e poi viene rimandato alla pagina Login.
Workflow Bottone Prenota
Consideriamo ora il bottone Prenota e iniziamo un nuovo workflow. Quando il bottone viene cliccato, viene creata una nuova prenotazione nel database (azione di Bubble Create a new thing):
A questa prenotazione assegniamo dei valori specifici ad alcuni campi:
- data prenotazione prende il valore della data selezionata dall’utente, arrotondata al giorno
- user corrisponde al Current user
- postazione corrisponde a Parent’s group Postazione
Lo step 2 consiste nel mostrare l’alert che comunica all’utente che la prenotazione è stata effettuata:
Ora che abbiamo creato la prenotazione sul database, possiamo creare la prenotazione anche su Google Calendar. Per farlo, utilizziamo l’azione Google Calendar – Create a Calendar Event data dal plugin installato:
Compiliamo ora i campi per implementare l’azione:
- calendar_id corrisponde all’ID del calendario sul quale vogliamo creare gli eventi. E’ possibile recuperare questa informazione direttamente dalle impostazioni del calendario di Google
- start_time corrisponde alla data e ora di inizio dell’evento. Nel nostro caso l’evento non ha un orario specifico, ma dura un giorno intero. Utilizziamo la data di prenotazione (arrotondata al giorno) che proviene dal risultato dello step 1, formattandola come Simplified extended ISO, formato riconosciuto da Google Calendar:
- end_time fa riferimento alla data e ora di fine dell’evento. Utilizziamo sempre la data di prenotazione (arrotondata al giorno) che proviene dal risultato dello step 1, aggiungendo in questo caso 24 ore ( + hours: 24) e formattandola come Simplified extended ISO:
- summary costituisce il nome dell’evento che si vuole riportare su Google Calendar. Nel nostro caso, abbiamo inserito il nome e il cognome dell’utente ottenuto dallo step 1, seguiti dal nome della postazione (sempre ottenuta dallo step 1) intervallata da un trattino (ad esempio: Isabella Bonora – Postazione 1):
L’ultimo step del workflow è l’azione Make changes to a thing per la modifica dell’id della prenotazione nel database. L’elemento da modificare è l’ID risultante dallo step 1, al quale assegniamo l’ID ottenuto dallo step 3 (cioè dalla prenotazione su Google Calendar):
Recuperare questo ID ci permetterà di implementare l’azione di cancellazione della prenotazione, come vediamo di seguito.
Workflow Bottone Cancella prenotazione
Iniziamo il workflow sul bottone Cancella prenotazione.
La prima azione è Google Calendar – Delete Calendar Event:
Per quanto riguarda i campi da compilare:
- calendar_id corrisponde all’ID del calendario dal quale vogliamo eliminare gli eventi. Nel nostro caso è lo stesso ID utilizzato per il workflow del bottone Prenota
- event_id corrisponde all’ID della prenotazione. Assegniamogli l’ID della prenotazione che ha:
- data prenotazione corrispondente al valore del Date/Time Picker (arrotondata al giorno)
- postazione uguale a Parent group’s Postazione
- user uguale a Current User
In questo modo andiamo a cancellare tale prenotazione da Google Calendar.
Il secondo step ci permette di cancellare la prenotazione anche dal database di Bubble, andando a cercarla come in precedenza:
Per concludere, mostriamo il messaggio di Alert che comunica all’utente la cancellazione della prenotazione:
Con questa azione chiudiamo il flusso relativo alla pagina Index. Il prossimo step è la progettazione della pagina Booking per la visualizzazione delle prenotazioni effettuate.
Pagina Booking
La pagina Booking è composta da:
- Header, dal quale è possibile raggiungere la pagina Index ed effettuare il Log out.
- Group Page, che contiene:
- i tab per la selezione delle prenotazioni future o passate
- gli alert che avvisano l’utente nel caso non ci siano prenotazioni
- il Repeating Group che mostra le prenotazioni future o passate (in base al filtro applicato), con l’indicazione della data e della postazione e il relativo bottone per cancellare la prenotazione.
Header
Per quanto riguarda l’header, possiamo copiare e incollare nella pagina l’elemento usato in precedenza. L’unica differenza consiste nel bottone Prenota! che si sostituisce al bottone Le mie Prenotazioni e, al click, manda l’utente alla pagina Index:
Il bottone Log out avrà lo stesso comportamento implementato in precedenza, che consente all’utente di effettuare il logout e andare alla pagina Login.
Group Page
Tab Future e Passate
All’interno di Group Page inseriamo un gruppo di tipo Column con Row gap 20px, al cui interno aggiungiamo il titolo Le mie Prenotazioni.
Aggiungiamo ora un gruppo di tipo Row, al cui interno inseriamo due testi l’uno accanto all’altro: Future e Passate, per la selezione delle prenotazioni future o passate:
Entrambi i testi avranno il padding come indicato nell’immagine sottostante:
Vediamo ora le condizioni da inserire.
Considerando il tab Future, quando la chiave p all’interno dell’URL è future, l’elemento risulterà selezionato e avrà il font di weight 600 e di colore blu e il bordo solid di colore blu:
Questo stile compare anche quando il text è hovered e la chiave p NON è future.
Come ricorderete, in precedenza abbiamo aggiunto la chiave
p=future nell’URL quando l’utente dalla pagina Index clicca il bottone Le mie Prenotazioni. In questo modo, grazie alla condizione aggiunta, il tab Future risulta selezionato di default quando si atterra sulla pagina.
Facciamo lo stesso per il tab Passate, questa volta utilizzando il valore past della chiave p:
Ma in quali casi la chiave assume valore past?
Per rispondere dobbiamo iniziare un workflow sul testo Passate:
Quando tale testo viene cliccato, l’utente viene rimandato sulla pagina Booking e viene assegnato il valore past al parametro p.
Facciamo lo stesso per il testo Future:
Per riassumere:
- atterrando sulla pagina Booking, il parametro ha valore future e verranno visualizzate di default le prenotazioni future
- cliccando il tab Passate (se questo non è già selezionato) verranno visualizzate le prenotazioni passate
- cliccando il tab Future (se questo non è già selezionato) verranno visualizzate le prenotazioni future.
Alert assenza prenotazioni
Prima di passare al repeating group, aggiungiamo i messaggi che verranno visualizzati nel caso in cui non siano presenti prenotazioni.
Quando non ci sono prenotazioni future, il messaggio che verrà visualizzato è il seguente:
Tale messaggio non è visibile di default ed è visibile quando
- la ricerca delle prenotazioni con utente=Current user e data di prenotazione corrispondente alla data corrente (arrotondata al giorno) è vuota e
- il parametro p ha valore future
Implementiamo la stessa condizione per il secondo messaggio, relativo alle prenotazioni passate, anch’esso non visibile di default, questa volta utilizzando il valore past:
RepeatingGroup Prenotazioni
Concludiamo inserendo il repeating group che ci permette di visualizzare le prenotazioni effettuate. Questo è di tipo Prenotazione e ha le seguenti condizioni:
- Quando il parametro p è future, visualizziamo le prenotazioni con utente=Current User e data prenotazione maggiore o uguale alla data corrente arrotondata al giorno
- Quando il parametro p è past, visualizziamo le prenotazioni con utente=Current User e data prenotazione minore della data corrente arrotondata al giorno
All’interno del repeating group, aggiungiamo un gruppo di tipo Row di tipo Prenotazione e Data source Current Cell’s Prenotazione:
Inseriamo quindi un’immagine dinamica che corrisponde all’immagine della postazione della prenotazione individuata:
Accanto all’immagine inseriamo un gruppo Row di tipo Prenotazione e Data source Parent group’s Prenotazione:
All’interno di questo gruppo abbiamo:
- un gruppo di tipo Column con al suo interno le indicazioni della data e della postazione
- l’icona del cestino per cancellare la prenotazione.
Iniziamo dal gruppo. Questo ha, come prima, tipologia Prenotazione e Data source Parent group’s Prenotazione:
Al suo interno, inseriamo due testi:
- Data prenotazione dinamica, che corrisponde alla data della prenotazione formattata come nell’immagine sottostante
- Postazione, che corrisponde alla postazione prenotata
In conclusione, accanto a questo gruppo, inseriamo l’icona del cestino, che di default è visibile e, quando il parametro p è past, non è visibile:
In questo modo, solamente le prenotazioni future sono cancellabili.
Implementiamo ora il workflow per la cancellazione delle prenotazioni. Quando l’icona viene cliccata, viene implementata l’azione del plugin per la cancellazione di un evento. In particolare, nel campo calendar_id inseriamo l’ID del calendario cui facciamo riferimento, come in precedenza. Per il valore del campo event_id, invece, effettuiamo una ricerca dell’ID della prenotazione di riferimento e utente corrispondente al Current user. In questo modo andiamo a cancellare la prenotazione da Google Calendar:
Con la seconda azione cancelliamo la prenotazione dal database di Bubble, effettuando una ricerca della prenotazione come nell’azione precedente:
Infine, dopo aver inserito un alert per la comunicazione dell’avvenuta cancellazione (come abbiamo fatto nella pagina Index) mostriamo l’alert che ci comunica che l’azione è avvenuta con successo:
Infine aggiungiamo un ultimo workflow che rimanda l’utente non loggato alla pagina Login:
Conclusioni
Abbiamo finalmente concluso la creazione della nostra applicazione per la prenotazione delle postazioni in ufficio!
Pro e contro dell’utilizzo di Bubble.io
Questo progetto di sperimentazione con Bubble.io è stato un’opportunità per esplorare lo strumento e valutarne il potenziale in un contesto aziendale. Questo ci ha permesso di migliorare la nostra comprensione delle capacità della piattaforma e di valutarne l’adeguatezza per i nostri futuri progetti, contribuendo a espandere il nostro toolkit di sviluppo e design.
In particolare, è emerso un panorama di pro e contro che vale la pena esaminare.
Pro
- Sviluppo rapido: Il principale punto di forza di Bubble.io risiede nella sua capacità di consentire lo sviluppo rapido di applicazioni. La costruzione visuale degli elementi dell’interfaccia e dei workflow semplifica notevolmente il processo, consentendo di tradurre idee in prototipi funzionanti in tempi brevi.
- Effetto WOW: Bubble.io offre un effetto WOW immediato e permette di tradurre rapidamente idee in prototipi funzionanti. Questo aspetto genera un impatto positivo immediato e cattura l’attenzione dei clienti che possono vedere e provare le soluzioni in azione.
- Validazione veloce: Bubble.io semplifica il processo di validazione di concetti e soluzioni, permettendo di raccogliere feedback tempestivi. Questo è particolarmente cruciale nelle prime fasi di sviluppo, aiutando a confermare la direzione del progetto e ad apportare modifiche in modo tempestivo.
Contro
- Esportazione applicazione: Le app Bubble possono essere eseguite solo sulla piattaforma Bubble; non è possibile esportare l’applicazione come codice. Nel caso in cui non si volesse più utilizzare Bubble, si dovrà ricostruire la logica dell’applicazione da zero. Tuttavia, nel caso in cui Bubble dovesse chiudere, il codice sorgente di Bubble sarà reso disponibile con una licenza open source, garantendo di poter mantenere l’app su un server Bubble self-hosted.
- Curva di apprendimento elevata: La curva di apprendimento può essere alta per chi si avventura per la prima volta nella piattaforma, in quanto la comprensione approfondita delle funzionalità può richiedere tempo e sforzo.
In conclusione, l’uso di Bubble.io offre vantaggi notevoli in termini di rapidità e possibilità di prototipazione. La scelta di utilizzare Bubble.io e integrarlo tra gli strumenti di lavoro dovrebbe essere guidata dalla natura specifica del progetto e dalle esigenze a lungo termine, bilanciando i benefici immediati con le considerazioni a lungo raggio sulla gestione del prodotto.
