Anvil2 konkretisieren – mit seinem Token-Modell aus drei Ebenen, verifizierten Rollenwerten für hell und dunkel sowie einer vollständigen Interaktion zur Servicezuweisung mit synchronisierten Techniker-, Zeit- und Prüfstatusangaben.
ServiceTitan Anvil Designsystem – Tokenarchitektur mit drei Ebenen
Primitive unterhalb semantischer Rollen halten
Anvil2 trennt rohe Primitive, semantische Rollen und komponentenspezifische Aliase. Ein Produkt sollte in der Regel die Rolle wählen, die die Bedeutung im Interface beschreibt, statt ein primitives Blau für jedes Steuerelement zu übernehmen. Die Referenztabelle enthält die exakten exportierten Werte und ihre Entsprechungen für den dunklen Modus. So lässt sich eine Theme-Änderung als Wertepaar prüfen.
Keine Neuberechnung von Aliasen zur Laufzeit erwarten
Laut offizieller Anleitung zum Theming werden Verweise auf Primitive während des Builds aufgelöst. Wird ein Primitiv über einen Provider zur Laufzeit geändert, wird die semantische Ebene nicht automatisch neu generiert. Um die Farben der Anwendung anzupassen, überschreiben Sie die betreffende semantische Rolle; für eine einzelne Komponente verwenden Sie die Komponentenebene. So verhindern Sie ein teilweise geändertes Theme, bei dem zusammengehörige Steuerelemente uneinheitlich bleiben.
ServiceTitan Anvil Designsystem – helle und dunkle Darstellung
Änderungen an Vorder- und Hintergrundfarbe aufeinander abstimmen
Die primäre Aktion verwendet BackgroundColorPrimary mit ForegroundColorOnPrimary. In der hellen Darstellung ist sie blau mit weißem Text, in der dunklen Darstellung hellblau mit dunkler Beschriftung. Würde nur die Füllfarbe wechseln, wäre das Wertepaar nicht stimmig. Die vollständige HTML-Studie verwendet light-dark() mit einem Wechsel des Farbschemas, um diese Werte zu veranschaulichen, ohne vorzugeben, ThemeProvider zu verwenden.
Statusfarben mit klarer Bedeutung verwenden
Anvil2 ordnet den Farbfamilien Statusbedeutungen zu. Bei der lokalen Prüfung wird eine Erfolgsrolle verwendet, zugleich wird genau beschrieben, was passiert ist. Ein nicht verfügbarer Techniker wird textlich gekennzeichnet und hat eine deaktivierte Radio-Schaltfläche. Ein grüner Farbton erweckt nicht den Eindruck, ein Serviceeinsatz sei disponiert worden; das Beispiel ist nicht mit einem Dispositions-Backend verbunden.
ServiceTitan Anvil Designsystem – Servicezuweisung und Status
Verfügbarkeit muss die nächste Auswahl bestimmen
Bei der Auswahl eines Technikers werden die Optionen für die Startzeit durch die fiktive Verfügbarkeit dieser Person ersetzt. Die nicht verfügbare Person bleibt sichtbar, kann aber nicht ausgewählt werden. Da die beiden Steuerelemente voneinander abhängen, muss eine Änderung des ersten das zweite auf einen gültigen Wert zurücksetzen. Eine Zeitangabe, die einer anderen Person zugeordnet ist, darf nicht bestehen bleiben.
Planung und Ausführung voneinander trennen
Die Prüfung der Zuweisung speichert einen lokalen Plan und weist ausdrücklich darauf hin, dass kein Serviceeinsatz disponiert wurde. Für einen produktiven Ablauf wären vor dem Speichern Berechtigungsprüfungen, eine aktuelle Terminplanantwort und eine Behandlung von Konflikten erforderlich. Das Beispiel macht diese Grenze sichtbar und bietet zugleich eine vollständige Interaktion, die sich ausprobieren und anpassen lässt.
ServiceTitan Anvil Designsystem – operative Dichte und Lesbarkeit
Den Auftragskontext direkt bei der Auswahl anzeigen
Eine kompakte Auftragsübersicht enthält Aufgabe, Dauer, Bereich und Priorität. Die Technikeroptionen bilden eine gut lesbare vertikale Liste; der vorgeschlagene Einsatz wird in einem separaten Bereich dargestellt. Neutrale Abgrenzungen und eine zurückhaltende Akzentfarbe sorgen dafür, dass die Auswahl und die Hauptaktion leicht erkennbar bleiben. Die Zeitplanbalken sind als beispielhafte Darstellung gekennzeichnet; maßgeblich ist das tatsächliche Zeitauswahlfeld.
Die Lesereihenfolge auf Mobilgeräten beibehalten
ServiceTitan Anvil Designsystem – native Integration und vollständige Alternative zu HTML
Die dokumentierte Provider-Struktur verwenden
Anvil2s ThemeProvider akzeptiert Überschreibungen für semantische und komponentenspezifische Tokens, einschließlich value- und dark-Erweiterungen. Der Leitfaden enthält weiter unten ein vollständiges Provider-Beispiel aus der öffentlichen Dokumentation. Es dient als Referenz für eine native Integration und unterscheidet sich vom unabhängigen HTML-Beispiel, das lokal ausgeführt wurde.
Keine ungeprüfte Laufzeit des Pakets behaupten
Diese Seite bietet eine funktionierende HTML-Implementierung und verifizierte Token-Daten. Das native Provider-Beispiel ist eine separate Integrationsreferenz und entspricht nicht der Laufzeitumgebung der Vorschau. Wenn Sie React-Komponenten einsetzen, installieren Sie eine kompatible Anvil2-Version, binden Sie die erforderlichen Styles ein und prüfen Sie die Komponenten-APIs, bevor Sie die nativen HTML-Steuerelemente ersetzen.
ServiceTitan Anvil Designsystem – Barrierefreiheit und Statusprüfung
Native Formularsemantik verwenden
Techniker werden durch native Radio-Schaltflächen mit Beschriftung dargestellt, die Startzeit durch ein beschriftetes Auswahlfeld und die Darstellungseinstellung durch aria-pressed. Die Prüfmeldung ist eine Statusregion. Für die Radio-Auswahl wird das native Tastaturverhalten des Browsers genutzt; die sichtbare Fokusgestaltung bleibt unabhängig von Auswahl- und Hover-Stilen.
Änderungen nach der Bestätigung prüfen
Wird der Techniker oder die Zeit geändert, werden alte Prüfmeldungen gelöscht. Ein Wechsel der Darstellung behält den ausgewählten Techniker und die Zeit bei, denn eine visuelle Theme-Änderung sollte einen Plan nicht verwerfen. Tests sollten beide Übergänge, eine deaktivierte Auswahl und das Verhalten bei schmalen Bildschirmen abdecken, statt nur zu prüfen, ob sich eine Schaltfläche anklicken lässt.
ServiceTitan Anvil Designsystem – Übergabe an den AI-Agenten und Implementierung
Mit dem vollständigen Zustandsmodell beginnen
Speichern und starten Sie das vollständige HTML-Beispiel, um das Verhalten zu prüfen. Die aus Tokens abgeleiteten Paare für den hellen und dunklen Modus sind oben im CSS sichtbar; die festgelegten Verfügbarkeitsdaten finden Sie im Skript. Eine native React-Implementierung kann dieselben Zustandsübergänge beibehalten und dabei geprüfte Anvil2-Steuerelemente verwenden.
Das vollständige HTML-Beispiel ausführen.
Den zweiten Techniker auswählen und prüfen, ob sich die Optionen für die Startzeit ändern.
Plan prüfen, dann die Uhrzeit ändern und sicherstellen, dass die Rückmeldung gelöscht wird.
Darstellung wechseln und prüfen, ob die aktuelle Auswahl erhalten bleibt.
Angeben, wofür echte Daten erforderlich sind
Den Agenten anweisen, die abhängige Zeitliste, das deaktivierte Teammitglied, die Ungültigkeit der Prüfung und das Verhalten der Darstellung beizubehalten. Den fiktiven Auftrag und das Teammitglied erst ersetzen, wenn ein echter Datenvertrag verfügbar ist. Die lokale Prüfung nicht allein durch eine Änderung der Schaltflächenbeschriftung als Erfolg ausgeben.
Verfügbarkeit vor einer echten Disposition prüfen.
Semantische und komponentenspezifische Überschreibungen getrennt halten.
Vorder- und Hintergrundkombinationen für helle und dunkle Darstellung testen.
ServiceTitan Anvil-Komponentenbeispiele des Designsystems
Vollständiges Beispiel für eine lokale Zuweisung
Originales HTML/CSS/JavaScript mit tokenbasierten Darstellungen und abhängigem Formularstatus.
Diese Provider-Referenz wurde anhand der offiziellen Dokumentation geprüft; das oben ausgeführte Beispiel ist davon unabhängig und verwendet HTML.
04
Einrichtung des ServiceTitan Anvil-Designsystem-Agenten
Ausgangspunkt für die Implementierung
Für das ausgeführte Beispiel ist kein Anvil2-Paket erforderlich. Das separate ThemeProvider-Beispiel setzt eine kompatible native Installation voraus.
sh
# Save the complete HTML example as index.html
python3 -m http.server 8080
# Open http://localhost:8080
Ein Prompt für dein Projekt
Agenten-Prompt
Eine Oberfläche zur Zuweisung von Serviceaufträgen mit semantischen Rollen von Anvil2 erstellen. Die Vordergrundkombinationen für helle und dunkle Darstellung, die vom Techniker abhängigen Zeitauswahlen, nicht verfügbare und daher deaktivierte Teammitglieder sowie die Ungültigkeit der Prüfung aus dem vollständigen Beispiel beibehalten. Explizit zwischen dem originalen HTML und einer verifizierten React-Installation von Anvil2 wählen. Eine Disposition niemals ohne Antwort vom Backend als erfolgt ausgeben.
05
Quellen und Geltungsbereich des ServiceTitan Anvil-Designsystems
Ein OpenDesign-Leitfaden zu ServiceTitan Anvil2. Tokenwerte wurden aus den öffentlichen Hammer-Tokens 3.5.0 extrahiert. Das ausgeführte Beispiel verwendet originales HTML, keine React-Laufzeitumgebung von Anvil2; alle Techniker und Verfügbarkeiten sind fiktiv.
