5 häufige Fehler bei Embedded-GUIs (und wie du sie vermeidest)

Veröffentlicht auf Lopaka.app — Der kostenlose webbasierte LVGL GUI-Builder für Embedded-Entwickler

Einführung

Ich habe Hunderte von Embedded-GUI-Projekten geprüft – von Arduino-Basteleien im Hobbybereich bis zu IoT-Geräten in der Produktion. Und ich sehe immer wieder dieselben Fehler.

Das sind keine Kleinigkeiten. Sie machen den Unterschied zwischen einer Oberfläche, die professionell wirkt, und einer, bei der Nutzer lieber zum seriellen Monitor greifen.

In diesem Beitrag gehe ich die 5 häufigsten Fehler bei Embedded-GUIs durch, die ich sehe, warum sie passieren und wie du sie vermeidest – oft in nur wenigen Minuten.

Fehler Nr. 1: Pixelkoordinaten fest verdrahten

Das Problem

lv_obj_set_pos(label1, 47, 83);
lv_obj_set_pos(btn1, 112, 156);
lv_obj_set_pos(bar1, 23, 201);

Du positionierst jedes Element, indem du Pixelkoordinaten rätst, dann um ±5 Pixel anpasst, erneut flashst, prüfst und wiederholst. Das ist langsam, fragil und bricht in dem Moment, in dem du die Display-Größe änderst.

Warum es passiert

Die meisten Arduino-GUI-Tutorials zeigen dir, wie du Widgets erstellst, aber nicht, wie du sie anordnest. Also rechnest du selbst – und die Rechnerei ist mühsam.

Die Lösung

Nutze einen visuellen GUI-Builder wie Lopaka, der die Positionierung für dich übernimmt:

1. Ziehe Widgets auf eine Zeichenfläche
2. Sieh dein Layout in Echtzeit
3. Exportiere Code mit sauberen, konsistenten Koordinaten
4. Wechsle die Display-Größe, ohne alles neu zu machen

Wenn du von Hand coden musst, nutze relative Positionierung:

// Instead of hardcoded positions:
lv_obj_align(label, LV_ALIGN_CENTER, 0, -40);
lv_obj_align(btn, LV_ALIGN_CENTER, 0, 20);
lv_obj_align(bar, LV_ALIGN_BOTTOM_MID, 0, -20);

Fehler Nr. 2: Keine visuelle Hierarchie

Das Problem

Alles auf dem Screen hat dieselbe Größe, dieselbe Farbe, dasselbe visuelle Gewicht. Der Nutzer weiß nicht, wohin er zuerst schauen soll.

┌─────────────────────────────┐
│ Temperature: 25.6C          │
│ Humidity: 65%               │
│ Pressure: 1013 hPa          │
│ Battery: 75%                │
│ Status: OK                  │
│ Time: 14:32                 │
│ Date: 2026-04-02            │
└─────────────────────────────┘

Das ist ein Daten-Dump, keine Oberfläche.

Warum es passiert

Embedded-Entwickler denken in Datenstrukturen, nicht in visuellem Design. Jeder Sensormesswert erhält dieselbe Behandlung, weil im Code jede Variable gleich wichtig ist.

Die Lösung

Schaffe eine klare Hierarchie:

1. Primäre Informationen – Groß, prominent, in der Mitte des Screens (z. B. Temperatur)
2. Sekundäre Informationen – Mittlere Größe, unterstützender Kontext (z. B. Luftfeuchtigkeit)
3. Tertiäre Informationen – Klein, am Rand (z. B. Zeitstempel, Batterie)

// Primary — big and bold
lv_obj_set_style_text_font(temp_label, &lv_font_montserrat_36, 0);

// Secondary — readable but smaller
lv_obj_set_style_text_font(humidity_label, &lv_font_montserrat_20, 0);

// Tertiary — subtle
lv_obj_set_style_text_font(time_label, &lv_font_montserrat_14, 0);
lv_obj_set_style_text_color(time_label, lv_color_hex(0x888888), 0);

Gute Hierarchie:

┌─────────────────────────────┐
│                             │
│         25.6°C              │  ← Primary (large, center)
│                             │
│    Humidity: 65%            │  ← Secondary (medium)
│    Pressure: 1013 hPa       │
│                             │
│  🔋 75%        14:32        │  ← Tertiary (small, bottom)
└─────────────────────────────┘

Fehler Nr. 3: Touch-Zielgrößen ignorieren

Das Problem

lv_obj_set_size(tiny_button, 40, 20);

Ein Button, der auf einem resistiven 2,8"-Touchscreen 40×20 Pixel groß ist, ist ein Albtraum, wenn du ihn genau treffen willst. Nutzer verfehlen ihn, werden frustriert und hören auf, deine Oberfläche zu nutzen.

Warum es passiert

Entwickler gestalten für das Display, nicht für den Finger. Auf einem 320×240-Screen sehen 40 Pixel vernünftig aus – bis du versuchst, ihn mit einer Fingerspitze zu tippen.

Die Lösung

Minimale Touch-Zielgröße: 40×40 Pixel (idealerweise größer)

// Too small
lv_obj_set_size(btn, 40, 20);

// Good
lv_obj_set_size(btn, 80, 44);

// Better — with padding
lv_obj_set_size(btn, 100, 50);
lv_obj_set_style_pad_all(btn, 8, 0);

Daumenregeln:

• Buttons: mindestens 44px Höhe (Empfehlung aus Apples HIG)
• Abstand zwischen Buttons: mindestens 8px
• Wenn der Text nicht bequem hineinpasst, ist der Button zu klein
• Teste mit deiner echten Hardware – resistive Touchscreens brauchen größere Ziele als kapazitive

Fehler Nr. 4: Kein Feedback für Nutzeraktionen

Das Problem

Der Nutzer drückt einen Button. Es passiert scheinbar nichts. Er drückt ihn erneut. Und noch einmal. Jetzt wurde die Aktion dreimal ausgelöst.

Warum es passiert

Embedded-Systeme sind langsam. Die Lücke zwischen Berührung und visuellem Feedback kann 100–500 ms betragen – eine Ewigkeit in UI-Zeit. Ohne sofortiges Feedback gehen Nutzer davon aus, dass die Berührung nicht registriert wurde.

Die Lösung

Gib sofortiges visuelles Feedback:

// Button press state change
lv_obj_set_style_bg_color(btn, lv_color_hex(0x444444), LV_STATE_PRESSED);
lv_obj_set_style_transform_scale(btn, 240, LV_STATE_PRESSED);

// Loading indicator for slow operations
lv_obj_t *spinner = lv_spinner_create(lv_scr_act(), 1000, 60);
lv_obj_center(spinner);

// Toast notification for completed actions
lv_obj_t *toast = lv_label_create(lv_scr_act());
lv_label_set_text(toast, "Saved!");
lv_obj_align(toast, LV_ALIGN_BOTTOM_MID, 0, -10);
lv_obj_fade_out(toast, 500, 1500);

Feedback-Checkliste:

• Button verändert sein Aussehen, wenn er gedrückt wird
• Lade-Spinner für Vorgänge > 200 ms
• Bestätigungsmeldung für destruktive Aktionen
• Fehlerzustand sichtbar und klar (roter Rahmen, Fehler-Icon)
• Erfolg-Bestätigung für abgeschlossene Aktionen

Fehler Nr. 5: Nicht früh auf echter Hardware testen

Das Problem

Deine GUI sieht im Simulator perfekt aus. Du flashst sie auf die Hardware und entdeckst:

• Farben wirken auf dem echten Display ausgewaschen
• Text ist in der gewählten Größe unlesbar
• Die Touch-Kalibrierung ist um 10 Pixel daneben
• Das Display ist langsamer als erwartet, was zu sichtbarer Redraw-Verzögerung führt

Warum es passiert

Simulatoren sind bequem. Hardware-Tests erfordern Setup. Also verschieben Entwickler Hardware-Tests, bis die GUI „fertig“ ist – und entdecken dann, dass alles falsch ist.

Die Lösung

Teste von Tag eins an auf echter Hardware:

1. Flashe am ersten Tag mit dem Display einen einfachen Test-Screen
2. Prüfe sofort Farben, Schriftarten und Touch-Kalibrierung
3. Iteriere auf der Hardware, nicht nur im Simulator
4. Nutze Lopakas Live-Vorschau zum Gestalten, dann flashe schrittweise

Schnelle Hardware-Sanity-Checkliste:

• Display-Treiber korrekt initialisiert
• Farben entsprechen den Erwartungen (teste mit Farbproben)
• Schriftgrößen sind aus normaler Betrachtungsdistanz lesbar
• Touch-Kalibrierung korrekt (teste Ecken und Mitte)
• Aktualisierungsrate akzeptabel (kein sichtbares Flackern oder Tearing)
• Energieverbrauch im Budget (Displays sind stromhungrig)

Bonus: Der Meta-Fehler

Keine Tools nutzen, die es gibt, um diese Probleme zu lösen.

Du musst nicht jede Pixelposition von Hand coden. Du musst keine Farbschemata raten. Du musst Touch-Zielgrößen nicht manuell berechnen.

Tools wie Lopaka gibt es genau dafür, diese Fehler zu eliminieren:

• Visuelles Layout → Keine fest verdrahteten Koordinaten mehr
• Integrierte Style-Guides → Konsistente visuelle Hierarchie
• Touch-bewusste Größenbestimmung → Buttons sind immer fingerfreundlich
• Vorschau in Echtzeit → Sieh Änderungen sofort, teste schrittweise auf der Hardware
• Sauberer Code-Export → Produktionsreifer LVGL-Code, keine Black-Box-Runtime

Zusammenfassung

Fehler	Auswirkung	Lösung
Fest verdrahtete Koordinaten	Langsame, fragile Layouts	Visuellen Builder oder relative Ausrichtung nutzen
Keine visuelle Hierarchie	Verwirrende Oberfläche	Größe/Farbe nach Wichtigkeit
Kleine Touch-Ziele	Frustrierende UX	Buttons mindestens 40×40px
Kein Nutzer-Feedback	Unsichere Interaktionen	Gedrückt-Zustände, Spinner, Toasts
Spätes Hardware-Testen	Teure Nacharbeit	Von Tag eins an auf der Hardware testen

Ressourcen

• Lopaka.app — Baue GUIs ohne diese Fehler
• LVGL Style System — Vertiefung ins LVGL-Styling
• Apple HIG Touch Targets — Branchstandard für Größen
• Lopaka Discord — Hol dir Hilfe aus der Community

Welche GUI-Fehler hast du gemacht? Teile deine Kriegsgeschichten in den Kommentaren – wir waren alle schon dort.