10 KiB
CABINET Info-Tablet – Entwicklungskonzept
Status: Entwicklungsvorlage | Februar 2026
1. Projektübersicht
1.1 Zweck
Ein kleines Tablet im Schaufenster neben dem Eingang des CABINET Stores in Bielefeld zeigt Passanten und Kunden auf einen Blick die wichtigsten Store-Informationen: aktueller Öffnungsstatus, Öffnungszeiten, Sonderhinweise und den nächsten freien Beratungstermin.
1.2 Technischer Ansatz
Die Anzeige wird als responsive Webapp unter einer Subdomain (cabinet.b2in.eu/info <- live / [https://b2in.test/_cabinet](https://b2in.test/_cabinet)/info ← testserver) bereitgestellt. Das Tablet greift im Vollbild-Kioskmodus über den Browser darauf zu. Die Inhalte werden über das bestehende B2in-Backend (CMS) gepflegt.
Ordner /info
1.3 Branding
Ausschließlich CABINET-Branding. Kein B2in-Logo, kein Hinweis auf andere Marken. Das Tablet ist ein reines Store-Informationstool.
2. Content-Struktur & Layout
Das Display ist in fünf feste Bereiche unterteilt, von oben nach unten:
| # | Bereich | Inhalt | Verhalten |
|---|---|---|---|
| 1 | Header | CABINET Logo (links) + aktuelles Datum mit Wochentag (rechts). | Datum aktualisiert sich automatisch um Mitternacht. |
| 2 | Status-Banner | Drei Zustände: Geöffnet (grün): „Wir sind geöffnet" + „Heute bis [Uhrzeit] für Sie da." · Hinweis (gelb): Frei definierbare Headline + Subtext. Z. B. „Heute erst ab 11:00 Uhr" · Geschlossen (rot): Frei definierbare Headline + Subtext. Z. B. „Betriebsurlaub bis 03.03." | Farbe, Icon und Text wechseln je nach Status. CMS-gesteuert. |
| 3 | Öffnungszeiten | Wochenansicht Mo–So. Heutiger Tag visuell hervorgehoben (fetter Text, leichter Hintergrund). Wenn Sonderöffnung aktiv: heutige Zeit wird in Orange angezeigt. | Heutiger Tag wird automatisch erkannt. Sonderöffnung überschreibt Standard-Zeit für heute. |
| 4 | Termin-Karte | Dunkle Karte mit Kalender-Icon. Zeigt: „Nächster freier Termin" + Datum/Uhrzeit + „Beratung – ca. 45 Min." | CMS-gesteuert. Optional: Kann später an Kalendersystem angebunden werden. |
| 5 | Footer | Telefonnummer (links) + E-Mail (links) + QR-Code (rechts). QR-Code führt zur Website oder Terminbuchung. | Statisch. QR-Code wird einmalig generiert und als Asset hinterlegt. |
3. CMS-Felder (B2in-Backend)
Folgende Felder werden im B2in-Backend als eigener Bereich „CABINET Info-Tablet" angelegt. Alle Felder sind einfache Eingabefelder ohne komplexe Logik.
| Feldname | Typ | Validierung | Beschreibung |
|---|---|---|---|
store_status |
Dropdown | open |
notice |
notice_headline |
Text | Max. 40 Zeichen | Headline im Status-Banner bei Status „notice" oder „closed". Wird bei „open" ignoriert. |
notice_subtext |
Text | Max. 80 Zeichen | Erklärender Subtext unter der Headline. Optional. |
override_open_today |
Zeit (HH:MM) | Optional, Format HH:MM | Sonder-Öffnungszeit für heute. Überschreibt die Standard-Öffnungszeit in der Wochenansicht. |
override_close_today |
Zeit (HH:MM) | Optional, Format HH:MM | Sonder-Schlusszeit für heute. |
next_appointment_date |
Datum | TT.MM.JJJJ | Datum des nächsten freien Beratungstermins. |
next_appointment_time |
Zeit (HH:MM) | Format HH:MM | Uhrzeit des nächsten freien Termins. |
hours_monday – hours_sunday |
Text | z. B. „10:00–18:00" oder „Geschlossen" | Standard-Öffnungszeiten pro Wochentag. 7 Felder. |
contact_phone |
Text | Freitext | Telefonnummer im Footer. |
contact_email |
Text | E-Mail-Format | E-Mail-Adresse im Footer. |
Wichtig: Die Felder override_open_today und override_close_today sollten sich automatisch um Mitternacht zurücksetzen (auf leer), damit die Sonderöffnung nicht versehentlich am nächsten Tag weiterläuft.
4. API-Endpoint
Das Backend stellt einen einfachen JSON-Endpoint bereit, den die Webapp abfragt.
4.1 Endpoint-Struktur
GET /api/cabinet-tablet/status
Response (JSON):
json
{ "store_status": "notice", "notice_headline": "Heute erst ab 11:00 Uhr", "notice_subtext": "Wegen eines Kundentermins öffnen wir heute später.", "override_open_today": "11:00", "override_close_today": null, "next_appointment": { "date": "2026-02-27", "time": "14:00" }, "hours": { "monday": "10:00 – 18:00", "tuesday": "10:00 – 18:00", "wednesday": "10:00 – 18:00", "thursday": "10:00 – 18:00", "friday": "10:00 – 18:00", "saturday": "10:00 – 14:00", "sunday": "Geschlossen" }, "contact": { "phone": "0521 – 123 456 0", "email": "info@cabinet-bielefeld.de" }, "updated_at": "2026-02-26T09:15:00Z" }
4.2 Update-Mechanismus (Polling)
Die Webapp fragt den Endpoint in zwei Stufen ab:
1. Lightweight Check (alle 30 Sekunden):
Die Webapp ruft einen minimalen Endpoint ab, der nur den updated_at Timestamp zurückgibt.
GET /api/cabinet-tablet/check
json
{ "updated_at": "2026-02-26T09:15:00Z" }
2. Full Fetch (nur bei Änderung): Wenn der Timestamp sich vom lokal gespeicherten unterscheidet, wird der komplette Status-Endpoint abgerufen und die Anzeige aktualisiert – kein Page-Reload, nur DOM-Update per JavaScript.
Warum Polling statt WebSockets? Für ein einzelnes Tablet, das auf ein CMS reagiert, das vielleicht 1–2x am Tag geändert wird, ist Polling robuster und einfacher zu warten. WebSockets wären Overkill und eine zusätzliche Fehlerquelle.
5. Technische Stabilität & Kiosk-Betrieb
5.1 Kiosk-App (Android)
Empfehlung: Fully Kiosk Browser (ca. 7 € einmalig pro Gerät, Industriestandard für Digital Signage).
Funktionen, die wir nutzen:
- Vollbild-/Kioskmodus: Kein Zugriff auf Android-UI, Statusbar ausgeblendet
- Auto-Restart bei Browser-Absturz: App startet sich automatisch neu und lädt die URL
- Zeitsteuerung: Tablet geht nachts (z. B. 22:00) in Standby, wacht morgens (z. B. 07:00) auf
- Remote-Management: Über Fully Cloud kann die URL und Einstellungen remote geändert werden
- Bildschirm-Timeout: Screen bleibt dauerhaft an während der definierten Betriebszeit
- Motion Detection (optional): Bildschirm wird heller wenn jemand davor steht
5.2 Webapp-seitige Stabilität
Zusätzlich zur Kiosk-App bauen wir folgende Sicherheiten direkt in die Webapp ein:
| Maßnahme | Beschreibung |
|---|---|
| Auto-Reload | Kompletter Page-Reload alle 6 Stunden (z. B. um 03:00, 09:00, 15:00, 21:00). Räumt Speicher auf und verhindert Memory Leaks durch langlebige Browser-Sessions. |
| Offline-Fallback | Wenn die API nicht erreichbar ist, zeigt die Webapp den letzten bekannten Stand an + dezenten Hinweis „Stand: [Zeitpunkt]". Kein Fehlerbildschirm, der Passanten verwirrt. |
| Connection-Recovery | Wenn das Polling 3x hintereinander fehlschlägt, wartet die Webapp 5 Minuten, dann versucht sie es erneut. Nach 30 Minuten ohne Verbindung: automatischer Page-Reload. |
| Lokaler Cache | Die letzte API-Response wird im localStorage gespeichert. Bei Neustart (z. B. nach Browser-Crash) wird sofort der Cache angezeigt, während im Hintergrund frische Daten geladen werden. |
| Keine Interaktion | Die Webapp hat keine klickbaren Elemente (außer dem QR-Code, der ohnehin nur visuell ist). Kein Scrollen, kein Touch-Event. Verhindert versehentliche Bedienung. |
| Automatische Datumsaktualisierung | Um Mitternacht: Neuen Wochentag setzen, heutigen Tag in der Öffnungszeiten-Liste aktualisieren, Sonderöffnungszeiten zurücksetzen. |
6. Frontend-Spezifikation
6.1 Technologie
- Einfache statische HTML/CSS/JS-Seite (kein Framework notwendig)
- Responsive für Tablet-Größen hochkannt (ca. 1.600 x 2.456** Pixel , 256 PPI)
- Keine externen Abhängigkeiten außer einer Google-Fonts-Einbindung (Fallback auf System-Fonts)
- JavaScript Vanilla – kein React, Vue o. Ä. nötig
6.3 Animations & Transitions
Wenn sich der Status ändert (z. B. von „open" zu „notice"), soll der Übergang sanft per CSS-Transition (300ms ease) erfolgen – kein harter Wechsel. Gleiches gilt für Änderungen an Öffnungszeiten oder Termin.
7. Hardware-Empfehlung
| Komponente | Empfehlung |
|---|---|
| Tablet | Android-Tablet, 8–10 Zoll, min. 2 GB RAM. Muss nicht high-end sein – es zeigt nur eine Webseite. HUAWEI MatePad T |
| Kiosk-App | Fully Kiosk Browser (ca. 7 € Lizenz). |
| Halterung | Wandhalterung oder Standfuß mit Diebstahlschutz. Hochkant montiert. |
| Stromversorgung | Dauerhaft am Strom (Ladekabel mit Kabelkanal). Akku-Ladung auf 80 % begrenzen (Fully Kiosk unterstützt das), um Akku-Verschleiß zu minimieren. |
| WLAN | Stabiles Store-WLAN. Empfehlung: Festes WLAN-Profil im Tablet hinterlegen, Auto-Reconnect aktivieren. |
8. Umsetzungs-Checkliste
| # | Aufgabe | Verantwortlich | Status |
|---|---|---|---|
| 1 | CMS-Felder im B2in-Backend anlegen (Abschnitt 3) | Backend-Entwicklung | Offen |
| 2 | API-Endpoint implementieren (Abschnitt 4) | Backend-Entwicklung | Offen |
| 3 | Frontend-Webapp bauen (Abschnitt 2 + 6) | Frontend-Entwicklung | Offen |
| 4 | Polling-Mechanismus + Stabilität implementieren (Abschnitt 4.2 + 5.2) | Frontend-Entwicklung | Offen |
| 5 | Subdomain einrichten + Deployment | DevOps | Offen |
| 6 | Tablet beschaffen + Fully Kiosk einrichten (Abschnitt 7) | Marcel / Hardware | Offen |
| 7 | QR-Code generieren + als Asset hinterlegen | Design | Offen |
| 8 | End-to-End-Test: CMS-Änderung → Tablet zeigt Update | QA | Offen |
| 9 | Installation im Store + Feintuning Helligkeit/Position | Marcel + Technik | Offen |
Anhang: Zusammenfassung der Auto-Logiken
Folgende Dinge passieren automatisch, ohne dass Marcel etwas pflegen muss:
- Datum und Wochentag im Header aktualisieren sich um Mitternacht
- Heutiger Tag in der Öffnungszeitenliste wird automatisch hervorgehoben
- Sonderöffnungszeiten (override-Felder) setzen sich um Mitternacht zurück
- Bei Status „open": Banner-Text generiert sich automatisch aus der heutigen Schlusszeit
- Polling läuft im Hintergrund (alle 30 Sek.), DOM-Updates ohne Flackern
- Auto-Reload alle 6 Stunden für Speicher-Hygiene
- Offline-Fallback: Letzter Stand wird angezeigt, kein leerer Bildschirm
- Fully Kiosk: Auto-Restart bei Crash, Standby-Zeiten, Bildschirm-Management