Entwickler-Briefing

Was die Klick-Prototypen zeigen – und was für das echte Produkt gebaut werden muss.

1 · Worum es geht

Restaurants tragen ihre täglichen Mittagsmenüs ein. Gäste finden per Umkreissuche (Standort oder Ortseingabe) sofort die Lokale in der Nähe – inklusive Entfernung und dem kompletten Tagesmenü direkt in der Trefferliste, ohne sich durchklicken zu müssen. Modern, simpel, „mobile first".

2 · Drei Rollen, ein System

Eine gemeinsame Datenbank und ein gemeinsames Design, aber drei getrennte Bereiche mit unterschiedlichen Zugriffsrechten:

3 · Funktionen im Detail

Gäste-Ansicht (Datei 01, Tab „Essen finden")

• Umkreissuche per aktuellem Standort oder Ortseingabe (Adresse/Bezirk), mit einstellbarem Radius (0,5–25 km; feine 0,5-km-Schritte bis 5 km, darüber gröber – Stadt vs. ländlicher Raum).
• Entfernung zu jedem Lokal wird angezeigt; sortierbar nach Entfernung oder Preis. Die Karte skaliert mit dem gewählten Umkreis (zoomt heraus).
• Menü auf einen Blick: Suppe, Menüs, Dessert samt Preisen stehen direkt auf der Trefferkarte.
• Tageswahl: Standard ist „heute"; Gäste können die nächsten 7 Tage wählen (Vorplanung).
• Filter arbeiten menügenau, nicht nur pro Restaurant: Bei „Vegan" verschwinden Lokale ohne veganes Gericht ganz; bei Lokalen mit veganem Angebot werden die nicht-veganen Menüs ausgeblendet. Gleiches gilt für Vegetarisch, „Mit Suppe", „Unter 12 €", „Jetzt offen". (Das ist ein zentrales Detail – bitte genau so umsetzen.)
• Kein Login für Gäste.

Restaurant-Portal (Datei 01, Tab „Restaurant-Login")

• Registrierung in Schritten: Lokal-Daten → Zugangsdaten → Telefon-Verifizierung → Freigabe.
• Telefon-Verifizierung: Das System ruft die öffentliche Nummer des Lokals an und nennt einen Code; nur wer den Code eingibt, kommt weiter. (Anfangsphase: manuell durch den Betreiber möglich; später automatisiert, z. B. via Telefon-API.)
• Manuelle Endfreigabe durch den Betreiber, bevor ein Lokal live geht.
• Menü-Editor: pro Tag maximal 1 Suppe + 3 Menüs + 1 Dessert. Je Menü optional Kennzeichnung „vegetarisch/vegan" und Preis. Eintragbar bis zu 2 Wochen im Voraus.
• Live-Vorschau der eigenen Karte, so wie Gäste sie sehen.
• Stammdaten (vom Lokal pflegbar): Name, Straße, PLZ, Ort, Telefon, E-Mail, Webseite sowie Öffnungszeiten des Mittagstischs je Wochentag (Von–Bis oder „geschlossen“) und Betriebsurlaub von–bis. Diese Daten steuern mehr als die Anzeige: An geschlossenen Tagen erscheint das Lokal nicht in der Suche und bekommt keine Erinnerung; während des Betriebsurlaubs ebenso. Öffnungszeiten für die Anzeige zusammenfassen (gleiche aufeinanderfolgende Tage bündeln: „Mo–Do 11:30–14:00 · Fr 11:30–14:30 · Sa–So geschlossen“). Plausibilität prüfen: Urlaubsende nicht vor Urlaubsbeginn, Bis-Zeit nicht vor Von-Zeit. Schreibschutz: Die Felder sind gesperrt und müssen über „Stammdaten ändern“ bewusst freigegeben werden; „Abbrechen“ verwirft die Änderungen, nach dem Speichern wird wieder gesperrt. Verhindert, dass ein versehentlicher Klick den Aushang und die Suchsichtbarkeit verändert.
• Logo: Upload durch das Lokal (PNG, JPG, SVG, WebP; max. 2 MB; quadratisch empfohlen, ≥ 400 × 400 px). Serverseitig auf einheitliche Größe bringen und als WebP ausliefern; Original behalten. Anzeige nur auf der Detailseite und auf den Aushang-PDFs – bewusst NICHT in der Suchliste, damit die Ergebnisliste ruhig bleibt und kein Lokal allein durch ein auffälliges Logo bevorzugt wirkt. Datei-Inhalt prüfen (nicht nur die Endung); bei SVG Skripte entfernen (Sanitizing), sonst ist das ein Einfallstor für Schadcode.
• Aushang-PDF (Tag & Woche): Direkt aus der Menüplanung erzeugbar, A4, druckfertig. Eigenständiges Plakat-Layout, keine Kopie der Bildschirmansicht. Wochenblatt: Tage als Zeilen, „Menü 1…n“ als Spalten (Spaltenzahl richtet sich nach dem Tag mit den meisten Hauptgerichten), Kalenderwoche in der Kopfecke, Tagessuppe oben in der Zelle mit Trennzeichen, Preis groß darunter. Tagesblatt: großformatig nach Gängen gegliedert. Kopf: Logo links (groß), daneben Name und Anschrift des Lokals, rechts Titel und Datumsbereich. Fußzeile mittig: Logo, Lokalname, zusammengefasste Öffnungszeiten, Adresse und Telefon, deutlich vom Menüteil abgesetzt. Ganz am unteren Blattrand steht klein Erstellt durch menüradar.at – kein Druckdatum, keine Seitenzahl. Über @page{margin:0} und innenliegenden Rand werden die vom Browser erzeugten Kopf- und Fußzeilen (Datum, Seitenzahl, URL) unterdrückt. Schriftgrößen so wählen, dass auch fünf Menüs pro Tag auf eine Seite passen. Gang-Angebote hervorgehoben mit durchgestrichenem Einzelpreis. Die Wochenkarte beginnt immer am Montag (nicht am heutigen Tag) – Menüs hängen deshalb an Datumsangaben, nicht am Abstand zu heute. Ein leeres Wochenende wird weggelassen. Es gibt je einen Knopf für diese und die nächste Woche sowie für heute und morgen, damit Lokale vorbereiten können. Dessert und Gang-Angebote stehen in getrennten Zeilen. Ungültige Angebote (Rabatt größer als Gesamtsumme, fehlender Preis) werden nicht gedruckt. Umsetzung serverseitig als echtes PDF (z. B. Headless-Browser) oder clientseitig über die Druckfunktion; Schriftgrößen so wählen, dass die Wochenkarte auf eine Seite passt.
• Autovervollständigung (lernend, je Lokal): Aus der Menü-Historie des Lokals entsteht ein eigenes Wörterbuch. Gespeichert wird pro Gericht: Bezeichnung, zuletzt verwendeter Preis, Kennzeichnung (vegetarisch/vegan) und Verwendungshäufigkeit. Beim Tippen werden Gerichte vorgeschlagen – alphabetisch sortiert (mit korrekter deutscher Umlaut-Sortierung: Ö bei O, Ü bei U, nicht am Listenende); bei Übernahme werden Preis und Kennzeichnung automatisch mitgesetzt und optisch kurz hervorgehoben. Sobald der Wirt den Preis selbst ändert, darf er nicht mehr automatisch überschrieben werden. Wörterbücher sind strikt pro Lokal getrennt (keine Preise anderer Betriebe sichtbar).
• Dauerangebote: Zusätzlich zu tagesbezogenen Angeboten kann ein Lokal Angebote hinterlegen, die an jedem Tag automatisch gelten (typisch: „3-Gang immer 2,50 € günstiger“). Regeln: Ein für einen Tag eingetragenes eigenes Angebot hat Vorrang vor dem Dauerangebot. Ein Dauerangebot wird an einem Tag nur ausgespielt, wenn alle nötigen Gänge mit Preis vorhanden sind – sonst würde etwa ein 3-Gang-Angebot an einem Tag ohne Dessert erscheinen.
• Gang-Angebote: je Angebot Art (3-Gang, 2-Gang Suppe+Haupt, 2-Gang Haupt+Dessert) und Modus Fixpreis oder Ersparnis (Rabatt auf die Einzelsumme, sinnvoll bei unterschiedlich teuren Hauptgerichten). Vergleichsbasis ist immer das günstigste Gericht je Gang. Plausibilitätsprüfung: Fixpreis über der Einzelsumme oder Rabatt über der Gesamtsumme wird als Fehler gemeldet und nicht an Gäste ausgespielt.
• Stammdaten pflegbar: Adresse, Öffnungszeiten, Telefon, E-Mail, Homepage und das Freitextfeld „Sonstiges" (siehe Detailseite).
• Nur verifizierte Lokale können Menüs veröffentlichen.

Später: Erinnerung an das Restaurant (Menüplan fehlt)

Am Sonntag prüfen, ob für die kommende Woche Menüs eingetragen sind, und das Lokal sonst erinnern.

• Rechtlich unkritisch, weil keine Werbung, sondern eine Service-Nachricht im laufenden Vertragsverhältnis. Wichtig: Die Mail darf keinerlei Werbeinhalt enthalten (kein „Upgrade“, kein Angebot) – sonst wird sie zur Werbe-E-Mail und benötigt eine Einwilligung.
• Zeitgesteuerter Job (Cron), Zeitzone Europe/Vienna, Sommer-/Winterzeit beachten. Vorschlag: Sonntag 17:00 erste Erinnerung, Montag 06:30 zweite, danach Ruhe.
• Prüflogik: „fertig“ heißt, für Mo–Fr der kommenden Woche ist an jedem Öffnungstag mindestens ein Hauptgericht eingetragen. Öffnungstage aus den Stammdaten lesen – kein Lokal wegen Ruhetag anschreiben.
• Betriebsurlaub / Ruhezeiten: Feld im Portal („geschlossen von–bis“). In diesem Zeitraum keine Erinnerung, und das Lokal erscheint auch nicht in der Suche.
• Kanal Push-Nachricht (Web Push): Voraussetzungen sind HTTPS, ein Web-App-Manifest, ein Service Worker und VAPID-Schlüssel. Je Lokal und Gerät wird eine Push-Anmeldung gespeichert (ein Wirt kann mehrere Geräte haben). Wichtig: Auf dem iPhone funktioniert Web Push nur, wenn die Seite zuvor zum Home-Bildschirm hinzugefügt wurde (installierte Web-App) – sonst kommt keine Nachricht an. Push-Anmeldungen laufen ab oder werden ungültig; abgelaufene Anmeldungen (HTTP 404/410) sofort löschen. E-Mail bleibt immer die Rückfallebene, Push allein ist nicht verlässlich genug für etwas so Wichtiges wie den Menüplan.
• Berechtigung richtig abfragen: nie beim Seitenaufruf, sondern erst, wenn der Wirt „Push“ auswählt. Wird sie einmal abgelehnt, kann man sie nicht erneut abfragen – dann muss ein Hinweis auf die Browser-Einstellungen erscheinen und automatisch auf E-Mail zurückgefallen werden.
• Einstellbar je Lokal: Erinnerung an/aus, Kanal (E-Mail, Push, beides), Uhrzeit. Versand protokollieren (erinnerung_log) und idempotent gestalten: pro Lokal und Woche höchstens einmal, auch wenn der Job zweimal läuft.
• Zustellbarkeit: eigener Absender auf der Domain, SPF, DKIM und DMARC einrichten, Transaktions-Versanddienst mit Sitz in der EU. Bounces auswerten, sonst merkt niemand, dass die Erinnerungen im Nichts landen.

Zurückgestellt: Newsletter für Gäste (rechtlich der heikelste Teil)

Vorerst nicht geplant. Die folgenden Punkte gelten, falls das Thema später aufgegriffen wird.

Gäste sollen Lieblingslokale abonnieren und deren Menüs per E-Mail bekommen.

• Das ist Direktwerbung. In Österreich gilt § 174 TKG 2021: E-Mail-Werbung nur nach vorheriger Einwilligung. Die Ausnahme für Bestandskunden greift nicht, weil Gäste nichts kaufen. Ohne Einwilligung drohen Verwaltungsstrafe (bis 50.000 €), Unterlassungsklage nach UWG und DSB-Beschwerde.
• Double-Opt-In umsetzen: Adresse eintragen → neutrale Bestätigungsmail mit Link → erst nach Klick in den Verteiler. Die Bestätigungsmail muss werbefrei sein (nur Bestätigungstext, Link, Impressum) – eine werblich gestaltete Bestätigung kann selbst schon unzulässige Werbung sein.
• Beweislast liegt beim Versender. Zu jeder Einwilligung speichern: Zeitpunkt, IP (gehasht), Wortlaut und Version des Einwilligungstextes, Bestätigungszeitpunkt. Ohne diesen Nachweis ist die Einwilligung im Streitfall wertlos.
• Abmeldelink in jeder Mail, ein Klick, kostenlos. Nach Abmeldung Adresse aus dem Verteiler entfernen (Sperrliste, damit sie nicht erneut importiert wird). Vor jedem Versand die ECG-Liste der RTR abgleichen.
• E-Mail-Impressum nach § 6 ECG und Mediengesetz in jeder Aussendung.
• Datensparsamkeit: nur E-Mail-Adresse, abonnierte Lokale, Frequenz, Bestätigungs- und Abmelde-Token. Kein Konto nötig. Gemerkte Lieblingslokale ohne Newsletter bleiben rein lokal im Browser.
• Adressen gehören Menüradar, nicht den Lokalen. Eine Weitergabe an Restaurants wäre eine eigene Verarbeitung und bräuchte eine gesonderte Einwilligung. Im Zweifel gar nicht anbieten.
• Öffnungs- und Klick-Messung (Zählpixel) nur mit gesonderter Einwilligung – standardmäßig aus.
• Vor dem Start anwaltlich prüfen lassen. Diese Zusammenfassung ersetzt keine Rechtsberatung.

Später: Matomo (selbst gehostet) für die Statistik

• Gute Wahl. Selbst gehostet auf einem EU-Server gibt es keine Übermittlung in Drittstaaten – genau der Punkt, an dem Google Analytics in Österreich gescheitert ist. Der Hoster bleibt Auftragsverarbeiter, also AV-Vertrag abschließen.
• Ohne Cookies und mit IP-Anonymisierung betreiben, „Do Not Track“ respektieren, Aufbewahrungsfrist begrenzen und Rohdaten automatisch löschen. Dann ist ein Einwilligungsbanner in der Regel entbehrlich – die Bewertung im Einzelfall gehört zur Rechtsprüfung. Opt-out-Möglichkeit in der Datenschutzerklärung anbieten.
• Klare Trennung der Zuständigkeiten: Matomo misst Verhalten (Besuche, Geräte, Herkunft, Verweildauer). Es ist nicht die Quelle für Geschäftszahlen. Menüpreise, veröffentlichte Menüs, Restaurant-Bindung, Suchen ohne Treffer und der Jahresrückblick kommen aus der eigenen Datenbank. Im Admin-Board speist Matomo den Bereich „Besuche & Browser“, alles andere die eigene Datenbank.
• Server-seitiges Tracking über die Matomo-HTTP-API erwägen: unabhängig von Werbeblockern, kein zusätzliches JavaScript, schnellere Seiten.
• Eigene Subdomain (z. B. statistik.menüradar.at), getrennte Site-IDs für Gästeseite, Restaurant-Portal und Admin. Archivierung per Cron statt beim Seitenaufruf, sonst wird Matomo langsam.
• Keine personenbezogenen Daten in URLs oder Suchbegriffen. Standort-Suchen nur gerundet erfassen (z. B. auf Bezirksebene), nie exakte Koordinaten.

Später: bezahlte Vorreihung (jetzt schon vorbereiten)

Geplant ist, dass Lokale gegen Aufpreis innerhalb des Suchradius weiter oben erscheinen. Das ist noch nicht zu bauen, aber die folgenden Punkte müssen von Anfang an stimmen, sonst wird es später teuer:

• Sortierung serverseitig und als eigenes Feld. Die Reihenfolge darf nicht implizit aus der Datenbankreihenfolge entstehen. Jedes Ergebnis bekommt einen sort_score; ein späterer Boost ist dann nur ein zusätzlicher Summand. Bei Gleichstand deterministisch weitersortieren (z. B. Entfernung, dann ID), sonst springt die Liste beim Neuladen.
• Datenmodell: je Lokal boost_faktor, boost_von, boost_bis, boost_gebiet (Bezirk/Radius). Historie der Buchungen getrennt speichern – nötig für Rechnungen und Nachweise.
• Kennzeichnungspflicht. Bezahlte Platzierung muss in Österreich klar als Werbung erkennbar sein (UWG, ECG). Also von Anfang an ein Feld/Label „Anzeige“ bzw. „Gesponsert“ im Ergebnismodell vorsehen und in der Liste sichtbar ausgeben.
• Sortierwahl des Gastes hat Vorrang. Wählt der Gast ausdrücklich „nach Entfernung“ oder „nach Preis“, darf kein Boost eingreifen. Der Boost wirkt nur in der Standard-Sortierung („Empfohlen“).
• Abrechnungsdaten ab dem ersten Tag mitschreiben: Impressionen (Lokal war in der Ergebnisliste sichtbar) und Klicks auf die Detailseite, pro Tag und Lokal. Ohne diese Zahlen kann später weder ein Preis begründet noch eine Rechnung belegt werden. Aggregiert, ohne Personenbezug.
• Obergrenze und Ruhe bewahren: höchstens 1–2 hervorgehobene Treffer pro Ergebnisseite. Wird die Liste zur Anzeigenfläche, verlieren die Gäste das Vertrauen – und ohne Gäste ist die Vorreihung nichts wert.

Detailseite (Datei „gasthaus-wolke.html")

• URL als Slug: jedes Lokal bekommt eine sprechende Adresse aus seinem Namen, z. B. /gasthaus-wolke. Slug beim Anlegen automatisch erzeugen (klein, Umlaute auflösen: ä→ae, ö→oe, ü→ue, ß→ss, Leerzeichen→Bindestrich, Sonderzeichen entfernen), Eindeutigkeit sicherstellen (bei Dopplung Suffix -2), danach unveränderlich halten (Links dürfen nicht brechen).
• Pflichtangaben: Name, Adresse/Ort, Öffnungszeiten, Telefon, E-Mail, Homepage.
• Tagesmenü mit Datum: neben „Heute" zusätzlich Wochentag + Datum ausgeben (Absicherung gegen veraltete Pläne).
• Öffnungszeiten mit Wochentag und Datum der laufenden Woche; heutiger Tag hervorgehoben.
• Sonstiges: mehrzeiliges Freitextfeld, das das Lokal selbst pflegt (z. B. Gastgarten, Take-away, Zahlung, Gruppen). Nur Text, keine Formatierung/HTML zulassen. Änderungsdatum mitspeichern.
• Dazu: Wochenvorschau, Karte, „Route öffnen", „Anrufen", „E-Mail schreiben".

Admin-Board (Datei 02)

• Freigabe-Queue: neue Lokale nach der Verifizierung annehmen/ablehnen.
• Statistiken: Besucher & Suchen im Zeitverlauf (7/30/90 Tage), Suchen nach Uhrzeit, Top-Restaurants, beliebteste Filter, Geräte, Registrierungs-Trichter, Reichweite nach Bezirk, durchschnittlicher Suchradius.
• Restaurant-Verwaltung: Status (aktiv/pausiert/veraltet), Menüs pro Woche, Aufrufe, Trend, letzte Aktualisierung.

4 · Geschäftsregeln

• Gäste zahlen nie – dauerhaft kostenlos, ohne Konto.
• Restaurants sind zum Start ebenfalls gratis. Später zahlen sie einen festen Monatsbeitrag – klassisch per Rechnung, kein Bezahlsystem in der App. Es muss aber später möglich sein, Teilnahme/Abrechnungsstatus je Lokal zu verwalten.
• Der Teilnahme-/Preisstatus wird Restaurants nicht angezeigt – nur der Hinweis, dass die Nutzung derzeit kostenfrei ist.
• Werbeflächen sind optional für später vorzusehen.

5 · Technische Hinweise

• Echte Umkreissuche nötig (Geocoding + Entfernung): z. B. Google Maps Platform oder OpenStreetMap/Nominatim.
• Rollen & Rechte sauber trennen (Gast / Restaurant / Admin).
• DSGVO: Impressum und Datenschutzerklärung sind Pflicht (österreichisches Recht). Für Statistik cookieloses Tool bevorzugt (z. B. Plausible oder selbstgehostetes Matomo).
• Web-App-Grundgerüst: manifest.json und Icons liegen bereits im Paket. Manifest, Service Worker und HTTPS sind zugleich die Voraussetzung für „Zum Home-Bildschirm hinzufügen“ und für Push-Nachrichten – beides also gemeinsam einrichten.
• Statistik von Anfang an einplanen, sonst gibt es später keine Daten fürs Admin-Board.
• Historie dauerhaft speichern (wichtig, später nicht nachholbar): Jedes veröffentlichte Menü wird als eigener Datensatz archiviert – mit Lokal, Datum, Gang (Suppe/Hauptgericht/Dessert), Bezeichnung, Preis und Kennzeichnung (vegetarisch/vegan). Nicht nur den aktuellen Stand überschreiben. Nur so sind Preisentwicklung, häufigste Gerichte und der Jahresrückblick je Lokal möglich. Ebenso zu protokollieren: Suchanfragen (Zeit, Bezirk, Radius, gesetzte Filter, Trefferanzahl) – besonders Suchen ohne Treffer, da sie zeigen, wo Lokale fehlen. Alles ohne Personenbezug, rein aggregiert (DSGVO).
• Start als Web-App (funktioniert im Handy-Browser). Native Apps für App Store / Play Store erst später – nicht für die erste Version nötig.
• Empfehlung Reihenfolge: erst ein Bezirk/Testgebiet, dann ausrollen.

6 · Was ist Mock, was muss echt werden

7 · Design-Vorgaben

Das Aussehen der Prototypen ist das verbindliche Zielbild. Verwendete Schriften: Bricolage Grotesque (Überschriften), Inter (Text), Space Mono (Zahlen/Preise). Warme, ruhige Farbwelt mit einem Grün als Leitfarbe und Bernstein/Honig als Akzent. Karten mit Menü im Vordergrund. Mobil zuerst, großzügige Abstände, wenig Deko.