Man sollte eine Oberfläche immer so gestalten, daß der Anwender nicht durch das Verhalten eines Schalters überrascht wird oder gar die Arbeit einer längeren Zeit zerstört.Schalter oder Menüpunkte, die weitere Fenster öffnen (auch Dialoge) werden mit 3 Punkten gekennzeichnet, z.B. "Laden...".Pull-Down Menüs sollten nach Möglichkeit die Menüpunkte "Datei" mit den Unterpunkten "Neu", "Laden...", "Sichern", "Sichern als...", "Ende" in dieser Rehenfolge enthalten, wobei nicht benötigtes weggelassen oder ersetzt werden kann (z.B. "Exportieren..." statt "Sichern" oder "Löschen" statt "Neu") - natürlich können auch andere Sprachen genutzt werden. Vor "Ende" sollte ein Ruler eingefügt werden.Ein "Bearbeiten" Pull-Down Menü (folgt möglichst nach "Datei") enthält, wenn man eine Zwischenablage (Clipboard) benutzt die Punkte "Ausschneiden", "Kopieren" und "Einfügen" in dieser Reihenfolge.Das erste Hilfe-Menü (menu::AddHelpMenu() - es sind technisch mehrere möglich, wenn auch nicht unbedingt sinnvoll) enthält immer einen Menüpunkt zum konfigurieren von Xclasses (Fonts, Farben, Zeiten). Dort sollte man auch alle Hilfe-Menüpunkte sowie einen Punkt zur Programminformation unterbringen.Der Text eines dafür nicht gedachten Gadgets (und damit dessen Bedeutung) darf nicht geändert werden, da dies den Anwender verwirrt. Dies ist zwar Xclasses-Konform mit Schattengruppen realisierbar, sollte aber trotzdem nicht auf einzelne Gadgets, sondern nur Gruppen angewendet werden. Eine Außnahme ist vielleicht bei einem Start/Stop Button denkbar, sollte aber auch dort gut bedacht werden (wenn die Bedeutung erhalten bleibt als Schalter für die selbe Funktion)..Möchte man einen Ein/Aus-Schalter, darf nicht die Klasse selknob genutzt werden, statt dessen ist checkbox oder selbutton zu verwenden. Selknob ist nur bei MX-Gadgets erlaubt (z.B. mxknob). Unter Umständen kann man hier auch Choice benutzen, um die beiden Optionen klarer zu erleutern.Bei MX-Gadgets ist selknob den selbuttons vorzuziehen.Die Klasse fbutton erzeugt meist eine ordentlichere Oberfläche, da keine riesigen Buttons dargestellt werden und der Raum statt dessen von anderen Klassen sinnvollger genutzt werden kann (z.B. listviews). Andererseits bieten große Buttons vor allem bei "wichtigen" Funktionen eine schnellere Anwahlmöglichkeit, da diese mit dem Mauszeiger leichter erreichbar sind - gut bei "Notstopp"-Knöpfen oder ähnlichem oder wenn ohnehin sonst keine andere Klasse den Raum nutzt. Dann kann ein großer Button aber andererseits auch wieder störend wirken.Die Klasse output ist bei sich ändernden Texten der Klasse text vorzuziehen, nicht zuletzt, da sie Cut&Paste unterstützt.Benutzt man ein input-Gadget oder auch output-Gadget mit einem vorangestellten Text in einer vertikalen Gruppe, sollte man die anderen Gadgets in der Gruppe mit einem lefttext Gadget verknüpfen (bzw. die erweitere Add-Methode von Group benutzen), da so alle Objekte in einer optischen Linie erscheinen. Jedoch sollte man dies nur dann machen, wenn diese Gadgets thematisch zusammengehören.Ruler sind eine praktische Methode, in einer Gruppe verschiedene Themenbereiche voneinander zu trennen, ohne dazu eine neue Gruppe anzulegen. Zu viele Ruler können jedoch arg stören! Ein sinnvoller Wert für den Freiraum (Space()) ist 4 (Vorgabe).Bordergroups sollten nur benutzt werden, um thematisch zusammenhängende Gadgets (oder Untergruppen) zusammenzufassen. Ansonsten sind normale Gruppen oder auch spacegroups zu empfehlen.Wenn man in einer Gruppe genügend Raum hat, sollte man den Abstand zwischen den darin enthaltenen Gadgets erhöhen (XDistance()/YDistance()). Der Abstand sollte jedoch trotzdem möglichst klein bleiben, um den Zusammenhang der Gadgets nicht zu zerreißen.Innerhalb einer Gruppe zentrierte Gadgets sehen oft besser (nicht zuletzt professioneller) aus.Schalter innerhalb einer Gruppe, die im Gegensatz zueinander stehen (z.B. "Sichern" und "Abbruch") sollten im DialogMode() der Gruppe dargestellt werden. Dabei befindet sich links die "stärkste" Aussage (z.B. "Sichern") und rechts die "schwächste" (z.B. "Abbruch"). WICHTIG: Diese Aufteilung entspricht der unter X11 typischen Anordnung und muß deshalb so benutzt werden; auf manchen anderen System ist diese gerade andersherum (z.B. Macintosh).Bezeichner von Gadgets sollten aussagekräftig, aber nie zu lang gewählt werden. Statt dessen sollte man weitere Erleuterungen in den HelpText (Bubbles-Help) verlegen. Ausnahmen stellen hier Pull-Down-Menüs dar, da es dort keine Hilfe-Texte gibt und der Raum dort nicht so begrenzt ist (oft sehen etwas breite Pull-Down-Menüs auch besser aus, dann sollte man ruhig Leerzeichen anfügen).Als Fonts sollten möglichst die Xclasses Standardfonts benutzt werden (Konstanten FONT_...), da sie vom Anwender geändert und auf seine Bildschirmverhältnisse angepaßt werden können.Ungenutzter Freiraum eigent sich oft gut als Info-Bereich über das Programm (Autor, Copyright) und erspart einen Info-Dialog.Xclasses unterscheidet bei Eingabefeldern (input) zwischen Return und Tabulator. Tabulator wechselt zu einem anderen Objekt, während Return die Eingabe absendet und dadurch eine Reaktion des Programms erzeugt. Sollte dieser Weg nicht brauchbar sein, gibt es einen Tip in den FAQ's, dies zu umgehen.