Summary
The current designs of UI – Apple’s iOS and macOS, Google’s material-design for Android and even Microsoft’s attempts to modernise Windows – are a welcome evolution for us 4D-developers. UI-elements are getting flat, simple, text based. Those kind of UI-objects are much easier to create ourselves, than those skeuomorphic, nearly photo-like renderings of real world objects from earlier, both OS-versions and real life.
Die aktuellen Trends im UI-Design – Apples iOS und macOS, Googles material-design for Android selbst Microsofts Ansätze Windows zu modernisieren – kommen uns 4D-Entwicklern entgegen. Die UI-Elemente werden flacher, einfacher und es gibt mehr Text als Bildelemente. Diese Elemente können wir viel eher selber erstellen, als die skeupmorphe, fotoähnliche Wiedergabe realer Objekte von früher, sowohl in vorangegangenen OS wie im physischen Leben.
Mit den neuen UI-Ideen experimentiere ich. Hauptsächlich auf dem Mac. Danach teste ich, wie gut es unter Windows 10 aussieht. Paßt soweit.
Buttons
Was habe ich mich abgemüht, eine Vielzahl von Buttons in den 4 Stadien – aktiv, Maus drüber, gedrückt und inaktiv – zu kreieren.
Es hat mich gefreut, als Buttons keine Hintergründe mehr brauchten, als die metallisch spiegelnden gewölbten Flächen verschwanden. Diese Buttons waren einfacher zu erzeugen, solange ich auf die exakten Pixel-Positionen der 4 Kopien achtete.
Jetzt nehme ich einen 3D-Button, gebe ihm den Schaltflächenstil Nichts, beschrifte aus Xliff und definiere das Stylesheet für den Button als System Font in 13 Punkt, große Buttons und solche mit Unicode-Zeichen in 18 Punkt.
Schrift
Die Idee ist, System Font als UI-Schrift zu verwenden. Nur die Stylesheets zum Drucken sollten andere Schriften als den System Font verwenden. Die Stilformate „default“, „button“ und „large“ reichen weit hin. Mit genügend Luft im Formular, mache ich mir keine Sorgen um Laufweiten in den beiden OS.
Statt Bilder zu zeichnen, suche ich nach Unicode-Zeichen, die mir lange Texte in Symbole kürzen. Ich verwende den Bleistift für einen Ändern-Button und die Unicode-Zeichen 0x2b (+) und 0x2015 (—) statt + und – weil sie größer sind und erkennbarer die Button Neu und Löschen symbolisieren. Mit dem Zeichen 0x2699 (⚙) für den Aktionen-Button/rechter Mausklick bin ich noch nicht glücklich.
Das richtige Unicode-Zeichen finden ist schwierig. Ich krakelige mir meines in ShapeCatcher. Gefundene merke ich mir in den Favoriten.
Die Verwendung von Unicode-Zeichen ist in 4D bis zur V15 noch umständlich. Die Formular-Objekte sollten das Unicode-Zeichen aus einem Xliff-Eintrag ziehen, der Methoden-Editor muß in Unicode sichern.
Farben
Passende Farben zusammenzustellen ist eine Kunst. Ich verwende gerne vordefinierte Farbkombinationen, wie die aus Numbers. Das Beitragsbild zu diesem Artikel zeigt Farb-Kombinationen aus WordPress.
6 Farben plus Graustufen sollten meistenteils reichen. Ich entscheide ob konträr-farbig oder eine Farbe in Abstufungen, mehr aus dem hellen oder aus dem dunklen Spektrum.
Aus der klassischen 4D-Farbtabelle waren die 8 Farben aus der unteren Hälfte der Farbtabelle verwendbar. In der ersten Zeile oben waren die 16 Farben der ersten Farbmonitore verewigt. Aus der linken Spalte der unteren Hälfte nahm ich die Farben für die Hintergründe und aus der rechten Spalte die für die Vordergründe.
Der neue 4D-Farbselektor aus den 64-Bit Versionen reduziert auf die wesentlichen Farben. Das spart manchen Gang über Angepaßt… in den Farbwähler des Systems.
Die Beschriftung von 3D-Buttons ohne Schaltfächenstil können eingefärbt werden. Ich finde das hilfreich, um Bereiche meiner 4D.apps abzugrenzen, ähnlich wie in iOS die Farben für Gesundheit (rot) und Notizen (gelb), Mail (blau), Erinnerungen (lila), Freunde (orange), …
Formulare
sind deshalb in hausinternen Anwendungen übervoll, weil so viel reinpassen muß. Ist das Formular übervoll, ist es schwierig das Wichtige vom Sekundären zu unterscheiden. Also wird gerahmt, unterstrichen und farblich laut dargestellt, um die Unterschiede kenntlich zu machen. Ich will davon weg. Mein Ziel sind luftige Formulare.
Um das zu erreichen, kann nicht alles immer sichtbar sein. Wird das Sekundäre angesehen oder editiert, müssen Teile des Formulare ausgetauscht werden. Die Dialog-Subforms ab V12 sind mir dabei eine große Hilfe. Ich brauche nicht mehr zig Seiten in den Formularen, sondern tausche Unterformulare aus. Das fördert die Kapselung, weil den Unterformularen nur mehr Nachrichten geschickt werden und diese darauf selbständig reagieren.
Luftige Formulare, Subforms uam habe ich in diesem Vortrag beschrieben:
Ideen und Rückmeldung nehme ich gerne an.
I’m experimenting with new UI-ideas. Mainly on Mac. Now and then I check how good it looks in Windows 10, which is of less concern, than with earlier Windows-versions.
Buttons
It was very tedious work, to build buttons with 4 states – active, hover, pressed and inactive.
I was happy, when buttons lost their metallic shiny curved backgrounds. These simpler buttons where much easier created and worked well, if I hadn’t fucked up with pixel-alignments.
These days I prefer 3D-buttons with style None. The button-text is an Xliff-entry and the button-stylesheet uses System Font in 13 points, bigger buttons and those showing unicode-symbols use 18 points.
Fonts
I should be sufficient using system font as the font for UI-elements. The only stylesheets left which will not use system font are those used for printing. Only these 3 stylesheets „default“, „button“ and „large“ are really needed. With enough white space, the size differences should be less of a concern on both OSses.
I used to draw pictures for a button. Today I try to find a unicode-character, to iconise for shorter button texts. A pencil symbols the modify-button and the unicode-chars 0x2b (+) and 0x2015 (—), instead of + and -, because those are bigger, symbolise add- and delete-buttons. I’m not really happy with char 0x2699 (⚙) for the action-button/contextual mouse click.
Finding an appropriate unicode-char is not easy. I draw what I’m looking for and let ShapeCatcher find the possible chars.
The usage of unicode-chars in 4D is up to V15 no simple task. The method-editor should save in unicode and form-objects should draw the unicode-char from an xliff-entry.
Colors
Combining colors that fit together is an art. I like the color-combinations from Numbers. For this article’s frontpage I pictured the colorselector from WordPress.
6 Colors plus some greys should be sufficient. My decision is wether I prefer 6 different colors, or six from the same kind of color. Optionally choose from the dark tones or the lighter ones.
From the classic 4D color-palette the lower 8 Colors where usable. The top row resembled the 16 colors of the very first colorscreens. From the lower half I used the very left column of colors for backgrounds and the rightmost column for foregrounds.
The new color-selector of 64-Bit 4D is more to my liking. It saves some extra clicks to select a color from the system-palette.
The button-text of 3d-buttons with button-style None can easily be coloured. I started using color-schemes that give my users a hint where they are. Similar to the use of color-schemes in iOS: health is read, notes is yellow, mail is blue, reminders are purple, friends come in orange, …
Forms
of our-company’s-app are so crammed, because there is so much to be displayed. Crammed forms lead to forms which hardly distinguish between the important things from the secondary ones. So they get fenced, underlined and their colors shout loud. For my own use I prefer layouts more fluffy with enough white space surrounding.
To achieve that I exchange subforms, when secondary information needs to be seen or edited. That’s why I like the new subforms of type dialog as of V12. Those subforms know how to behave by themselves. There is only some messaging between subform and master form to be implemented.
You might better understand what I mean from these slides:
Ideas and feedback welcome.