# ServiceTitan Anvil Designsystem ## ServiceTitan Anvil Designsystem – Interface-Vorschau Zwischen heller und dunkler Darstellung wechseln, verfügbares Personal auswählen und einen synchronisierten lokalen Plan prüfen. ## ServiceTitan Anvil Designsystem – Designreferenz Kern-Theme-Exporte aus @servicetitan/hammer-token 3.5.0 sowie die Dokumentation zur Theming-Bibliothek Anvil2. ### Semantische Paare für helle und dunkle Darstellung | Name / Regel | Wert / Konfiguration | Verwendung | | --- | --- | --- | | BackgroundColorDefault | light #ffffff / dark #1a1a1a | Hauptoberfläche der Anwendung. | | BackgroundColorDefaultHover | light #f9f9f9 / dark #292929 | Hover-Oberfläche. | | BackgroundColorPrimary | light #0265dc / dark #70b1ff | Flächenfüllung der primären Aktion. | | BackgroundColorPrimaryHover | light #1d4ca3 / dark #9ecaff | Native Rolle für den Hover-Zustand des Primärelements. | | BackgroundColorPrimaryFaint | light #fafcff / dark #000b19 | Zurückhaltende ausgewählte Oberfläche. | | ForegroundColorSubdued | light #707070 / dark #c4c4c4 | Unterstützender Text. | | ForegroundColorOnPrimary | light #ffffff / dark #1a1a1a | Text in Kombination mit einer primären Füllfarbe. | | ForegroundColorPrimary | light #0265dc / dark #70b1ff | Interaktiver Vordergrund. | | BorderColorSubdued | light #e6e6e6 / dark #404040 | Dezente Begrenzungen. | | BorderColorPrimary | light #0265dc / dark #9ecaff | Interaktive Begrenzung. | | StatusColorInfo | light #0265dc / dark #70b1ff | Informationsstatus. | | StatusColorDanger | light #d62100 / dark #ff5b3d | Sofortiger Handlungsbedarf. | | StatusColorSuccess | light #077e50 / dark #0bd085 | Lokale Prüfung abgeschlossen. | | StatusColorWarning | light #ffbe00 / dark #ffe278 | Unkritischer Hinweis. | ### Primitive Geometrie- und Responsive-Werte | Name / Regel | Wert / Konfiguration | Verwendung | | --- | --- | --- | | BreakpointSm | 640px | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | BreakpointMd | 768px | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | BreakpointLg | 1024px | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | BreakpointXl | 1280px | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | BreakpointXxl | 1536px | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | DurationDefault | 200ms | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | DurationInstant | 0ms | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | DurationFast | 100ms | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | DurationSlow | 300ms | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius0 | 0rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius1 | 0.1875rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius2 | 0.375rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius3 | 0.5625rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius4 | 0.75rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius5 | 0.9375rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius6 | 1.125rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius7 | 1.3125rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | | Radius8 | 1.5rem | Veröffentlichtes Primitiv; semantische und komponentenspezifische Aliase bestimmen die tatsächlichen Anwendungsrollen. | ### Vertrag für ThemeProvider-Überschreibungen | Name / Regel | Wert / Konfiguration | Verwendung | | --- | --- | --- | | theme.semantic | semantic token overrides | Eine Rolle wie BackgroundColorPrimary ändern. | | theme.component | component token overrides | Eine Änderung auf eine Komponentenrolle wie ButtonPrimaryBackgroundColor eingrenzen. | | value | default/light token value | Den Wert für die helle Darstellung angeben. | | extensions.appearance.dark.value | dark appearance value | Die passende dunkle Darstellung festlegen. | | CSS output | --a2- | ThemeProvider serialisiert den Token-Schlüssel in eine CSS-Variable. | | Primitive cascade | resolved at build time | Wird ein Primitiv zur Laufzeit überschrieben, werden semantische Aliase nicht neu berechnet. | ## ServiceTitan Anvil Designsystem – vollständiger Leitfaden Ein praktischer Leitfaden zur Auswahl, Anwendung und Überprüfung dieses Systems für ein echtes Interface. Umfassende Anleitung, Einstieg in die Implementierung und Links zu den Quellen. ## 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 Unterhalb von 768px folgt der vorgeschlagene Einsatz auf den Auftrag und die Technikerliste. Die Steuerelemente bleiben ausreichend groß, und Beschriftungen werden bei Bedarf umgebrochen. Die Vorschau verwendet keine Ansichtsfensterbereiche mit fester Höhe und erzeugt daher keinen großen Leerraum unter kurzen Inhalten. Die einspaltige Anordnung folgt derselben Entscheidungsabfolge wie das breitere Layout. ## 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. 1. Das vollständige HTML-Beispiel ausführen. 2. Den zweiten Techniker auswählen und prüfen, ob sich die Optionen für die Startzeit ändern. 3. Plan prüfen, dann die Uhrzeit ändern und sicherstellen, dass die Rückmeldung gelöscht wird. 4. 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. ``` Dispatch assignment study
SERVICE OPERATIONS / LOCAL PLANNING STUDY

Assign a service visit

Match a sample job with an available technician.

Job and technician

Sample job #204 · Heating inspection90 minutes · North district · Routine priority
``` Code-Referenz - Als index.html speichern; moderne Browser unterstützen light-dark(). Dies ist nicht die native Anvil2-Laufzeitumgebung. ### Referenz zur ThemeProvider-Integration Dokumentierte Form semantischer Überschreibungen in einem vollständigen React-Eintrag. Mit der installierten Anvil2-Version abgleichen. ``` import React from 'react'; import { createRoot } from 'react-dom/client'; import { ThemeProvider } from '@servicetitan/anvil2'; const theme = { semantic: { BackgroundColorPrimary: { value: '#7c3aed', extensions: { appearance: { dark: { value: '#a78bfa' } } }, }, }, }; function App() { return (

Theme integration check

Primary role with the provider’s matching foreground role
); } createRoot(document.getElementById('root')).render(); ``` Code-Referenz - Diese Provider-Referenz wurde anhand der offiziellen Dokumentation geprüft; das oben ausgeführte Beispiel ist davon unabhängig und verwendet HTML. ## 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. ``` # Save the complete HTML example as index.html python3 -m http.server 8080 # Open http://localhost:8080 ``` ### Ein Prompt für dein Projekt ``` 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. ``` ## 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. - Theming Tokenebenen, Überschreibungen und Darstellungswerte. - Farben Statusrollen und Hinweise zu Interaktionsfarben. - Abstände Abstandsskala und Integration von Hilfsklassen. - Größen Grundlagen der Größen. - Bibliotheksarchitektur Anvil2-Paket- und Bibliotheksgrenzen. ## Verwandte Ressourcen zum ServiceTitan Anvil-Designsystem ### Siemens iX Untersuchen Sie Industrieereignisse mithilfe einer klar definierten Schweregrad-Terminologie, theme-gerechter Farbrollen und der iX Event List API. Dieser Leitfaden erstellt ein lokales Geräteprotokoll, ohne einen geprüften Eintrag mit einem behobenen Maschinenalarm zu verwechseln. ### Sprout Social Seeds Prüfen Sie Seeds’ tatsächliche öffentliche Farb-, Abstands-, Produkttypografie- und Rahmen-Design-Tokens anhand einer vollständigen redaktionellen Prüfwarteschlange mit gemischter Auswahl, gefilterten leeren Zuständen und Rückgängig-Funktion. ### SumUp Circuit Ein Circuit-Leitfaden mit exakten semantischen Tokens, nativen Validierungs-Props, einem vollständigen Editor für Händlerartikel und einer illustrierten Vorschau aus Kundensicht. - [Implementierungsreferenz](https://anvil.servicetitan.com/docs/web/foundations/theming) - [Quelle](https://anvil.servicetitan.com/docs/web/foundations/theming) - [Quelle](https://anvil.servicetitan.com/docs/web/foundations/sizing) - [Code-Referenz](https://anvil.servicetitan.com/docs/web/foundations/theming) - [Theming Tokenebenen, Überschreibungen und Darstellungswerte.](https://anvil.servicetitan.com/docs/web/foundations/theming) - [Farben Statusrollen und Hinweise zu Interaktionsfarben.](https://anvil.servicetitan.com/docs/web/foundations/colors) - [Abstände Abstandsskala und Integration von Hilfsklassen.](https://anvil.servicetitan.com/docs/web/foundations/spacing) - [Größen Grundlagen der Größen.](https://anvil.servicetitan.com/docs/web/foundations/sizing) - [Bibliotheksarchitektur Anvil2-Paket- und Bibliotheksgrenzen.](https://anvil.servicetitan.com/docs/library-architecture)