Webrechner und Konfigurator planen: Regeln vor Oberfläche

Ein Materialrechner, ein Tarifvergleich und ein Produktkonfigurator können ähnlich aussehen und trotzdem sehr unterschiedliche Aufgaben haben. Der erste schätzt eine Menge. Der zweite vergleicht Angebote nach festgelegten Voraussetzungen. Der dritte erzeugt eine zulässige Zusammenstellung. Schreiben Sie zunächst einen Satz: „Nach der Nutzung soll die Person wissen, ob …“. Daraus ergeben sich die nötigen Angaben und der passende nächste Schritt.

Unterscheiden Sie zwischen einer Orientierung, einer vollständig geprüften Auswahl und einem Ergebnis, das in einen weiteren Geschäftsprozess eingeht. Ein grober Richtwert darf nicht durch eine genaue Nachkommastelle wie eine verbindliche Zusage wirken. Wenn ein Ergebnis ein Angebot, eine Bestellung oder eine fachliche Entscheidung auslösen soll, muss der betreffende Prozess gesondert geklärt werden. Der Rechner allein legt diesen Charakter nicht fest.

Stellen Sie außerdem fest, welche Fälle die Funktion bewusst nicht behandelt. Ein Standardprodukt kann gut berechenbar sein, eine Sonderanfertigung braucht vielleicht eine persönliche Prüfung. Für diesen Fall ist „Bitte klären Sie die Sondermaße mit uns“ eine hilfreiche Ausgabe. Eine erfundene Zahl aus unpassenden Standardwerten wäre schlechter. Eine kleine, sauber begrenzte Funktion ist oft leichter zu verstehen und zu pflegen als ein Rechner, der jede denkbare Ausnahme scheinbar abdeckt.

Eine Zahl wie „12“ ist ohne Einheit und Bezug unklar. Beschreiben Sie jedes Feld: Was wird eingegeben, in welcher Einheit, mit welcher Genauigkeit und in welchem zulässigen Bereich? Im Beispiel bedeutet Höhe eine Länge in Metern. Arbeitsgänge sind eine festgelegte Auswahl, keine frei verwendbare Dezimalzahl. Für Breite und Höhe muss die fachliche Verantwortung die unterstützten Mindest- und Höchstwerte bestimmen.

Eine leere Angabe und die Zahl null sind unterschiedliche Zustände. Ebenso sollte geklärt sein, wie Dezimalkomma, Dezimalpunkt oder ein eingefügter Einheitenzusatz behandelt werden. Ein Feld mit „2,5 m“ darf nicht versehentlich als zweieinhalb Millimeter oder als zwei interpretiert werden. Die Oberfläche kann Eingaben verständlich begrenzen und erklären; die eigentliche Berechnung muss auf eindeutig geprüften Werten arbeiten.

Der OWASP-Leitfaden zur Eingabeprüfung behandelt erlaubte Eingaben und ihre Prüfung. Für unseren eigenen Regelentwurf folgt daraus eine praktische Trennung: Passt das Format, und ist der Wert in diesem konkreten Modell sinnvoll? Ein numerischer Wert kann technisch lesbar sein und fachlich trotzdem außerhalb des zulässigen Bereichs liegen. Vorbelegte Werte sind als Annahmen zu kennzeichnen, damit sie nicht unbemerkt für einen realen Messwert gehalten werden.

Die Ergebnisfläche sollte benennen, was berechnet wurde und wofür es verwendet werden kann. Im fiktiven Beispiel wäre „Voraussichtliche Menge nach den gewählten Annahmen: 8,25 Liter; entspricht drei Gebinden zu je drei Litern“ verständlicher als „Sie benötigen 9“. Eine ergänzende Zusammenfassung von Fläche, Arbeitsgängen und Reserve macht die Zahl nachprüfbar. Nicht berücksichtigte Sonderbedingungen gehören nah an die Ausgabe.

Zeigen Sie nur so viel Genauigkeit, wie Eingaben und Modell tragen. Eine geschätzte Ausgangsgröße rechtfertigt keine scheinbar wissenschaftliche Ergebnispräzision. Wenn Werte fehlen oder außerhalb der unterstützten Grenzen liegen, sollte kein altes Ergebnis als aktuell gültig stehen bleiben. Sie können es bis zur Korrektur ausblenden oder sichtbar als veraltet kennzeichnen. Entscheidend ist, dass niemand eine Zahl für die aktuelle Auswahl hält, die zu einer früheren Auswahl gehört.

Planen Sie den Übergang zu einer Anfrage bewusst. Die Person sollte entscheiden können, ob sie die Auswahl weitergeben möchte. Benötigt die reine Berechnung keine Kontaktdaten, ist eine E-Mail-Adresse dafür kein rechnerischer Eingangswert. Bei einer Übernahme in den nächsten Schritt müssen die verwendeten Eingaben und die Regelfassung erhalten bleiben. So kann die zuständige Person nachvollziehen, wie das Ergebnis zustande kam, statt nur eine losgelöste Endzahl zu sehen.

Eine Auswahl mit Schieberegler braucht auch einen verständlichen Weg zu einem genauen Wert. Angaben müssen ihre Beschriftungen, Einheiten und aktuellen Werte behalten. Testen Sie, ob alle Arbeitsschritte mit Tastatur erreichbar sind und ob sich die Reihenfolge auf einem kleinen Bildschirm weiterhin nachvollziehen lässt. Die ausführlichere Einordnung zur mobilen Website-Bedienung hilft bei den dafür relevanten Oberflächenfragen.

Das HTML-Element output ist laut MDN für Ergebnisse einer Berechnung oder Nutzerhandlung vorgesehen. Es kann eine sinnvolle semantische Grundlage sein. Seine Verwendung allein belegt aber noch keine durchgehend zugängliche Interaktion. Die Ergebnisanzeige, ihre Beschriftung und das Verhalten bei Änderungen müssen in der tatsächlichen Oberfläche zusammen geprüft werden.

Die W3C-Erläuterung zu WCAG 2.2, Statusmeldungen beschreibt, wann dynamische Hinweise ohne Fokuswechsel für assistive Technik wahrnehmbar sein sollen. Beim Rechner kann etwa eine kurze Meldung „Ergebnis aktualisiert“ relevant sein. Nicht jede Änderung sollte dagegen eine lange Ausgabe ungefragt vorlesen. Vereinbaren Sie, ob nach einem bewussten Berechnen oder während der Eingabe aktualisiert wird, und testen Sie dieses Verhalten praktisch.

Fassen Sie die Planung auf einer Seite zusammen: Nutzerentscheidung, Ergebnistyp, Eingaben und Einheiten, freigegebene Fachregel, Rundung, ausgeschlossene Fälle, Ausgabe und nächster Schritt. Ergänzen Sie die Beispielrechnungen und den Ort, an dem veränderliche Grundlagen gepflegt werden. Diese Angaben sind unsere eigene Planungsempfehlung. Sie machen das Vorhaben konkreter, ohne bereits eine bestimmte technische Architektur vorzuschreiben.

Nach dem Start braucht jede Änderung an Faktoren oder Varianten denselben fachlichen Blick. Wer darf einen Wert ändern? Wer bestätigt, dass die Regel weiterhin passt? Welche Testfälle müssen danach erneut funktionieren? Ein geändertes Produkt kann andere Kombinationen benötigen, obwohl die Oberfläche unverändert aussieht. Die Pflege betrifft deshalb auch Berechnungsregeln und Ergebnisformulierungen, nicht nur den sichtbaren Text neben dem Rechner.

Die Leistungsseite Entwicklung beschreibt individuelle Webfunktionen, Webanwendungen und Erweiterungen vorhandener Lösungen. Für einen Rechner ist ein sinnvoller Ausgangspunkt die konkrete Aufgabe mit zwei oder drei Beispielrechnungen. Daraus lässt sich klären, ob eine kleine Funktion genügt, ob eine Verbindung zu bestehenden Daten nötig ist und welche Fachfragen vor einem belastbaren Angebot beantwortet werden müssen.