200 lines
10 KiB
Markdown
200 lines
10 KiB
Markdown
# 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` | `closed` | Bestimmt Farbe und Grundtext des Status-Banners. |
|
||
| `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
|