The Factory
Un coworking. Un sistema connesso.
Planimetrie originali. Arredi e attività illustrativi; nessun dato reale dei membri.
Una prenotazione si collega a uno spazio reale.
Sono le planimetrie reali dell’applicazione di amministrazione, ricostruite in tre dimensioni. Il percorso evidenziato illustra come un’area prenotabile si collega alla piattaforma.
- Planimetrie originali
- Regole di prenotazione
- Amministrazione condivisa
The Factory ha due sedi, a Bergamo e a Seriate. Il sito pubblico permette di entrarvi, ma il software gestisce anche il rapporto quotidiano con i membri. Sulture ha sviluppato la piattaforma che collega una prenotazione, un account e i servizi disponibili dopo l’arrivo. ATIO Studio ha curato il design del sito.
Le planimetrie, i componenti per i membri, l’amministrazione e l’interfaccia di stampa in sede mostrati qui provengono dall’applicazione reale. I dati e le attività sono fittizi. Gli spazi tridimensionali ricostruiscono la geometria delle planimetrie dell’applicazione di amministrazione; arredi e percorso simulato illustrano come il sistema collega software e spazio.
Lo spazio entra nel software.
Le stanze di ogni sede diventano aree della piattaforma, con capienza, orari e regole di prenotazione. Le planimetrie originali entrano anche nell’applicazione di amministrazione, collegando gli spazi riconoscibili alle informazioni necessarie per gestirli. Una sala è un luogo fisico e, nello stesso tempo, una risorsa che il sistema sa descrivere.
Il modello spaziale qui sopra è costruito dai tracciati di quelle planimetrie. Cambiare sede modifica la stessa geometria che il personale vede nell’applicazione. Arredi e attività sono illustrativi; stanze e pareti provengono dal materiale di The Factory.
La disponibilità diventa una prenotazione.
Una prenotazione dipende da più di una casella libera. La piattaforma verifica orari, chiusure, prenotazioni esistenti e capienza dell’area. Per le prenotazioni orarie controlla le sovrapposizioni; negli altri casi considera anche gli abbonamenti attivi. Il flusso di acquisto porta lo spazio scelto e le sue condizioni in un checkout integrato con Stripe.
La regola qui sotto è una piccola parte dell’implementazione reale. Mostra perché la disponibilità deve essere decisa rispetto alla capienza dello spazio, non dedotta dall’aspetto vuoto di una casella nel calendario.
if (overlappingBookings >= area.seats) {
return {
available: false,
error: 'overbooking'
}
}Un account contiene risorse da usare.
L’abbonamento ha una traduzione operativa. Il membro vede la prenotazione del giorno, può prenotare il successivo e consulta le risorse disponibili. Al rinnovo, il processo dedicato disattiva l’assegnazione precedente e crea quella successiva, con una propria scadenza.
L’account descrive quindi ciò che il membro può utilizzare ora, oltre a ciò che ha acquistato. La vista qui sotto accosta i componenti originali di prenotazione e risorse con un abbonamento e saldi fittizi. Lascia fuori fatturazione e profilo per mostrare il rapporto tra una prenotazione e i servizi a cui dà accesso.
Due sedi, una vista operativa.
La stessa piattaforma diventa il centro di amministrazione. Chi gestisce gli spazi può cambiare sede e data, leggere le prenotazioni sulle planimetrie originali e aprire le informazioni dell’area. La vista si aggiorna ogni minuto, mantenendo il disegno collegato ai dati operativi.
L’applicazione di amministrazione qui sotto usa i controlli e le planimetrie SVG originali. Passa da Bergamo a Seriate per osservare come la stessa vista segue spazi diversi. Indicatori e prenotazioni sono fittizi; disegni e interfaccia sono reali.
La stessa identità raggiunge accessi e rete.
In sede, il relay verifica i permessi in base all’identità del membro e al contesto corrente. Accessi e Wi-Fi utilizzano la stessa funzione di autorizzazione, con tipi di accesso distinti. Il captive portal registra i dispositivi, applica il limite previsto per l’account e autorizza la connessione tramite UniFi.
Le due chiamate mostrano questa decisione condivisa. L’hardware delle porte varia da sede a sede; la decisione no. Le verifiche di accesso riuscite vengono registrate come attività; quelle negate generano segnalazioni.
const response = await authorizeUser(locationId, identifier, 'door')
const userAuth = await authorizeUser(locationId, pin, 'wifi')Una richiesta diventa un risultato fisico.
La stampa è un servizio di sede. L’area personale cerca prima il servizio locale: fuori dalla sua rete, l’interfaccia di stampa non è disponibile. In sede, mostra lo stato della stampante e le copie a colori e in bianco e nero rimaste al membro. L’interfaccia originale qui sotto usa una stampante e disponibilità fittizie. Non può inviare file né azionare dispositivi.
Per un lavoro reale, il relay verifica le copie disponibili prima di inviare il PDF tramite IPP. Gestisce le compatibilità della stampante e registra l’utilizzo solo se la richiesta riesce. Il lavoro di Sulture collega l’account del membro, il servizio attivo in quella sede e la stampante fisica, invece di ridurre la stampa a un pulsante di caricamento remoto.
