coastdigitalgroup/coastai-skills

Store Locator System

Zweck

Das Store Locator System stellt eine Methodik zur Gestaltung von Schnittstellen zur physischen Standortsuche bereit (z. B. Filialfinder, Händlersuche, Händlernetzwerke oder Klinikverzeichnisse). Dieses System definiert die räumliche Zusammensetzung, responsive Anpassung, Interaktionssynchronisation und Barrierefreiheit, die erforderlich sind, um digitale Suchen mit physischen Zielen zu verknüpfen. Es stellt sicher, dass Benutzer Standorte in ihrer Nähe finden, die Details der Filialen auswerten und dorthin navigieren können – ohne kognitive Überlastung, Layout-Instabilität oder Barrieren.

Anwendungsfälle

• Einzelhandel & Händlernetzwerke: Kunden zu physischen Geschäften, Partnerhändlern oder autorisierten Service-Centern führen.
• Gesundheitswesen & Kliniken: Patienten bei der Suche nach nahegelegenen Notfallpraxen, Krankenhäusern oder spezialisierten Arztpraxen helfen.
• Finanzinstitute: Anzeige von Geldautomaten-Netzwerken und Filialstandorten mit spezifischen Service-Merkmalen (z. B. Drive-thru, Notar).
• Restaurants & Fast-Food-Ketten: Kunden bei der Suche nach nahegelegenen Gaststätten unterstützen, Echtzeit-Betriebsstatus prüfen und Bestellungen für Abholung/Lieferung starten.

Wann NICHT zu verwenden

• Unternehmen mit nur einem Standort: Wenn ein Unternehmen nur eine oder zwei Niederlassungen hat, ist ein vollständiger Locator überdimensioniert. Eine einfache Kontaktseite mit einer eingebetteten statischen Karte reicht aus (siehe site-navigation-system oder Richtlinien für Kontaktseiten).
• Reine Digital-/E-Commerce-Marken: Unternehmen ohne physische Präsenz oder Abholmöglichkeiten.
• Dynamische Logistik und Routenplanung: Fortschrittliche Mitfahr- oder Echtzeit-Lieferverfolgungsanwendungen erfordern kontinuierliches GPS-Tracking und dynamische Routenführung – diese fallen unter spezialisierte GIS-/Echtzeit-Transitsysteme.

Eingaben

1. Standort-Metadaten-Inventar: Koordinatenpaare (Breitengrad/Längengrad), physische Adresse, Kontaktdaten (Telefon, E-Mail), Öffnungszeiten und spezifische Standortmerkmale oder -dienste (Facetten).
2. Benutzer-Standortsignal: Verfügbarkeit der Geolokalisierungs-API, vom Benutzer eingegebene Postleitzahl oder Stadt-/Staatseingaben.
3. Fähigkeiten der Kartenplattform: Einschränkungen und benutzerdefinierte Styling-Parameter des zugrunde liegenden Kartenanbieters (z. B. Google Maps API, Mapbox GL JS, Leaflet).
4. Primäre Benutzerziele: Möchten Benutzer hauptsächlich sofort besuchen (benötigen Wegbeschreibung und Öffnungszeiten), Kontakt aufnehmen (benötigen Telefon) oder Bestand prüfen (benötigen Verknüpfung mit dem Lagerbestand)?

Ausgaben

1. Räumlicher Layout-Plan: Spezifikationen für responsive räumliche Layouts (Desktop Split-Pane-Proportionen vs. Mobile gestapelte Registerkarten).
2. Anatomie-Spezifikation: Detailliertes Design der Standortkarte, der Such-/Filterleiste und der Kartenmarkierungen.
3. Interaktions- und Zustandsbeschreibung: Definiertes Verhalten für Klick-Synchronisation von Markern, Hover-Zustände, Ladeindikatoren der Liste und Korrelation von Karte und Marker.
4. Barrierefreiheits- und Tastaturnavigationsplan: Definierte Fokus-Fallenmechanismen für Detailansichten, Screenreader-aria-live-Ansagen und nicht-visuelle Kartennavigationspfade.

Arbeitsablauf

1. Räumliche Zusammensetzung festlegen

Gestalten Sie die räumliche Beziehung zwischen der Karte und der Standortliste:

• Desktop-Layout (Split-Pane): Verwenden Sie ein geteiltes Bildschirmdesign.
  • Seitenleiste (35 % bis 40 % Breite): Platzieren Sie sie links (für LTR-Sprachen), um sie als Startpunkt der Lesereihenfolge zu etablieren. Sie muss unabhängig von der Hauptseite scrollbar sein, sodass das Suchfeld und die Standortliste stets erreichbar bleiben.
  • Kartenbereich (60 % bis 65 % Breite): Als festes, persistentes Element rechts positionieren.
• Mobiles Layout (umschaltbare Registerkarten): Da Karte und Liste auf schmalen Bildschirmen nicht nebeneinander passen, implementieren Sie eine Umschaltleiste oben oder unten auf dem Bildschirm:
  • Registerkarte „Listenansicht“: Zeigt das Suchfeld und die vertikale Kartenliste. Empfohlen als Standard-Registerkarte.
  • Registerkarte „Kartenansicht“: Zeigt die vollflächige Karte.
  • Aktionsebene: Stellen Sie sicher, dass schwebende Steuerelemente (z. B. Schaltfläche „Diesen Bereich durchsuchen“ oder Geolokalisierungs-Pin) bequem über der Karte liegen, ohne die Navigation zu verdecken.

2. Anatomie der Standortkarte definieren

Die Standortkarte ist die primäre Informationseinheit. Ordnen Sie ihre Elemente nach kognitiver Priorität:

+-------------------------------------------------------------+
|  [Kategorie-Tag]                           [Entfernung: 1.3 km] |
|  **Standorttitel / Filialname**                           |
|  [Sternebewertung / Bewertungen (optional)]               |
|                                                             |
|  Musterstraße 123, 10115 Berlin                             |
|  Statusanzeige: [Geöffnet / Geschlossen] (Schließt um 20:00)|
|                                                             |
|  [Button: Route]     [Button: Anrufen]    [Link: Details]   |
+-------------------------------------------------------------+

• Primäre Ebene: Standortname und Entfernung zum gesuchten Zentrum. Die Entfernung muss dynamisch berechnet und gut sichtbar sein (oben rechts).
• Sekundäre Ebene: Straßenadresse und Echtzeit-Öffnungs-/Schließ-Status (Farbcodierung in Verbindung mit Text, z. B. Grün für geöffnet, Rot für geschlossen).
• Tertiäre Ebene: Primäre Aktionen als gut berührbare CTA-Buttons (z. B. „Route“, „Anrufen“, „Details anzeigen“).

3. Suche und Facettenfilterung gestalten

Bereitstellung intuitiver Abfrage- und Filterwerkzeuge im Kopfbereich der Seitenleiste:

• Eingabefeld: Ein kombiniertes Feld für Postleitzahlen, Städtenamen und Straßenadressen, ergänzt um ein Autovervollständigungsmenü.
• Trigger „Mein Standort“: Ein markanter, barrierefreier Geolokalisierungsbutton, dargestellt durch ein standardmäßiges „Fadenkreuz“-Symbol, das für Screenreader entsprechend beschriftet ist (aria-label="Standorte in der Nähe meines aktuellen Standorts finden").
• Radius-Filter: Ein Dropdown, das Benutzern erlaubt, den Suchradius zu verfeinern (z. B. 5, 10, 25, 50 km).
• Facetten-Dropdowns: Schnellfilter für filialspezifische Merkmale (z. B. „Drive-thru“, „Rollstuhlgerecht“, „24 Stunden“). Verwenden Sie Badges an den Filter-Buttons, um die Anzahl der ausgewählten Filter anzuzeigen.

4. Bidirektionale Interaktionssynchronisation implementieren

Kartenmarkierungen und Listeneinträge müssen als einheitliches System funktionieren. Legen Sie klare interaktive Beziehungen fest:

• Listenkarte Hover/Fokus -> Kartenmarker: Das Hovering oder Fokussieren einer Listenkarte muss einen visuellen Zustandswechsel des zugehörigen Kartenmarkers auslösen (z. B. Vergrößerung, Farbwechsel oder Anheben in den Vordergrund per z-index).
• Kartenmarker Klick -> Listenkarte: Ein Klick auf einen Kartenmarker muss:
  • Die Seitenleistenliste automatisch so scrollen, dass die zugehörige Karte sichtbar wird.
  • Die Karte mit einer kurzen Übergangsanimation hervorheben (z. B. subtiler Hintergrund-Puls).
  • Ein Karten-„Info-Fenster“ (Popup) über dem Marker öffnen, das den Filialnamen, die Entfernung und einen „Route“-Link enthält.
• Diesen Bereich durchsuchen (Kartenverschiebung): Eine schwebende Schaltfläche „Diesen Bereich durchsuchen“ einblenden, die nur dann oben in der Mitte des Kartenbereichs erscheint, wenn der Benutzer die Karte vom ursprünglichen Suchzentrum wegschiebt oder zoomt.

5. Mobile Berührung und Kartenanpassung einrichten

Interaktionen auf mobilen Geräten so verwalten, dass Frustration vermieden wird:

• Scroll-Übernahme vermeiden: Deaktivieren Sie standardmäßig gestenbasierte Zooms auf mobilen Karten (erfordern Sie Zwei-Finger-Ziehen zum Verschieben oder Zoomen). Dies verhindert, dass Benutzer in der Karte „stecken bleiben“, während sie auf der Seite nach unten scrollen möchten.
• Schwebende Steuerelemente: Platzieren Sie schwebende Zoom- (+ / -) und Geolokalisierungs-Buttons in der unteren rechten Ecke der Karte, versehen mit einem kontrastreichen Schatten und einer Mindestberührungsfläche von 44x44 Pixeln.
• Kartenkarussell-Overlay: Stellen Sie auf der mobilen Kartenansicht ein horizontales, wischbares Kartenkarussell am unteren Bildschirmrand bereit, das den einzelnen aktiven oder nächstgelegenen Standort anzeigt. So bleiben Kartenerkundung und Detailinformationen vereint.

Entscheidungsregeln

• Die „Standardsuche“-Regel: Wenn die Locator-Seite ohne Suchabfrage oder Geolokalisierungsberechtigung lädt:
  • Zeigen Sie keine leere Karte an.
  • Zeigen Sie standardmäßig die nächstgelegenen Standorte basierend auf IP-Geolokalisierung an, oder listen Sie alle Standorte alphabetisch/nach Priorität sortiert auf.
• Die „Keine Ergebnisse“-Wiederherstellungsregel: Wenn ein Benutzer in einem Bereich ohne Standorte sucht:
  • Zoomen Sie die Karte heraus, um die nächstgelegenen verfügbaren Standorte anzuzeigen.
  • Zeigen Sie eine hilfreiche Nachricht in der Seitenleiste an (z. B. „Keine Standorte im Umkreis von 25 km von [Abfrage] gefunden. Hier sind die nächstgelegenen Standorte:“).
  • Fügen Sie einen Link „Alle Standorte anzeigen“ hinzu.
• Popup vs. Detailbereich-Regel:
  • Wenn der Standort nur wenige Metadaten hat (nur Adresse und Öffnungszeiten), zeigen Sie alle Informationen im Info-Fenster-Popup des Kartenmarkers an.
  • Wenn der Standort umfangreiche Metadaten hat (Lagerbestand, Teamliste, Fotos), muss ein Klick auf „Details anzeigen“ einen vollflächigen Detailbereich in der Seitenleiste ausklappen, den Tastaturfokus dort einfangen und eine klare Schaltfläche „Zurück zur Liste“ anbieten.

Einschränkungen

• Barrierefreiheit (Tastaturnavigation):
  • Tastaturnutzer müssen in der Lage sein, den gesamten Suchablauf und die Standortliste zu durchlaufen, ohne die Karte direkt zu verwenden.
  • Kartenmarkierungen müssen mit der Tastatur fokussierbar sein (tabindex="0") oder durch eine zugängliche Listenalternative repräsentiert werden.
  • Wenn Suchergebnisse aktualisiert werden, geben Sie die Änderung für Screenreader mithilfe eines aria-live="polite"-Elements bekannt (z. B. „3 Standorte in der Nähe von Berlin gefunden“).
• Berührungszielgröße: Alle Buttons, Kartenmarker und Filtersteuerelemente müssen WCAG 2.2 SC 2.5.8 erfüllen (mindestens 24x24 Pixel mit ausreichendem Abstand), wobei primäre Aktionsauslöser auf Karten und schwebende Steuerelemente für Daumenkomfort 44x44 Pixel groß sein sollten.
• Visueller Kontrast: Hochkontrast-Karten werden bevorzugt. Standardmarkierungen und aktive Marker-Beschriftungen müssen ein Kontrastverhältnis von mindestens 3:1 zum Kartenhintergrund aufweisen. Text in Karten und Popups muss WCAG AA (4,5:1) erfüllen.
• Layout-Verschiebung verhindern: Reservieren Sie vertikalen/horizontalen Raum für Ladezustände, indem Sie während aktiver Suchen Skelettkarten in der Seitenleiste verwenden, um kumulative Layout-Verschiebungen (CLS) zu vermeiden.

Häufige Fehlermuster

• Die Mobile-Scroll-Falle: Benutzer bleiben auf der Seite stecken, weil Scrollen auf dem mobilen Bildschirm nur die Karte verschiebt/zoomt und sie daran hindert, am Kartenkomponent vorbeizuscrollen.
• Unterbrochene bidirektionale Synchronisation: Ein Klick auf einen Kartenmarker öffnet ein Popup, scrollt aber nicht zur passenden Karte in der Seitenleiste oder hebt sie nicht hervor – Benutzer müssen Namen manuell abgleichen.
• Die „Blinde Karte“ (Ausgeschlossene Tastatur): Kartenmarkierungen werden als unfokussierbare SVG-Formen oder Canvas-Elemente implementiert, wodurch physische Standorte für Screenreader- und reine Tastaturnutzer völlig unerreichbar sind.
• Keine-Abfrage-Leerlauf-Sackgasse: Beim ersten Laden der Seite wird ein völlig leerer Bildschirm und eine stille Karte angezeigt, sodass der Benutzer raten muss, dass er zuerst suchen muss.
• Träges Kartenverschieben: Versuch, Hunderte von Markern in Echtzeit bei jeder kleinen Kartenverschiebung zu laden und darzustellen, was zu einem Einfrieren der Benutzeroberfläche führt. Implementieren Sie eine Entprellung (250–400 ms) bei Änderungen des Kartenausschnitts und gruppieren Sie nahe Marker.

Validierungskriterien

• Räumliches Layout ist für Desktop (geteilte Bildschirm-Seitenleiste) und Mobil (umschaltbare Listen-/Karten-Registerkarten) definiert.
• Bidirektionale Synchronisation ist spezifiziert (Klicken eines Markers hebt Karte hervor/scrollt zu ihr; Hover/Fokus auf Karte hebt Marker hervor).
• Gestenbasiertes Zoomen ist auf Mobilgeräten standardmäßig deaktiviert (Zwei-Finger-Scrollen erforderlich), um Mobile-Scroll-Übernahme zu vermeiden.
• Ladezustände (Skelette) sind so gestaltet, dass sie Layout-Verschiebungen (CLS) bei Aktualisierung von Suchabfragen vermeiden.
• Barrierefreie Alternative ist definiert: Tastaturnutzer können alle Standorte durchsuchen, deren Details lesen und Routen abrufen, ohne die Maus zum Hover über Karten-Canvas-Elemente zu benötigen.
• Screenreader erhalten eine beschreibende, höfliche aria-live-Ansage, wenn Suchergebnisse aktualisiert werden.
• Berührungsziele für alle interaktiven Kartenelemente, Marker und Zoom-Buttons erfüllen mindestens das WCAG 2.2 Minimum von 24x24 Pixeln (44x44 Pixel bevorzugt für primäre CTAs).
• Textkontrast in Standortkarten und Karten-Popups erfüllt WCAG AA (4,5:1).
• Klare Fallback-Abläufe sind für Suchen ohne Ergebnisse und verweigerte Standortberechtigung entworfen.