Category: Usability, Performance

Adjust text color to be readable on light and dark backgrounds of user interfaces

Most modern user interfaces are supporting different color schemes for day and night: the so called light and dark modes. Selecting a text color for each of those modes is not a big deal and it’s the way to go when designing the user interface.

In some cases, the text color is driven by the displayed contents. In the example below, the tint color is matched to the color of the drink. The global tint color of this app is totally different, but this color adjustment gives a very nice effect. But as you might already see, there is a small problem when it comes to very light or very dark colors: each color either has a good readability on light or dark backgrounds. Some colors might fit to both, but that’s not always the case. In the example below, the light yellow is still visible, but when it comes to small icons or small text, the details are lost.

To overcome this issue, a simple solution is to select two colors for each recipe so that each mode has a different one. That’s fine, but it might totally change the effect of this colored pages.

Can we calculate a suitable color?

Some time ago, there was an article about Black or white text on a colour background? In this one, I described different algorithms to calculate the best text color (black or white) for a colored background. But now, we need the opposite: a colored text that has a good readability on white (light) or black (dark) backgrounds.

When we look at HSL and HSV/HSB color models, we already have a value for ‘lightness’ or ‘brightness’. The idea is to find a color that matches a given hue and saturation and that has a brightness which is readable on light and dark background. For this, we can use different algorithms. Very good results could be achieved with a ‘Weighted W3C Formula‘. This formula take into consideration that the human eye perceives some of the primary colors darker than others.

f'(x) = r ? 0.299 + g ? 0.587 + b ? 0.11

Each color that is located at the border between the black and white overlay is suitable for light and dark backgrounds.

Step 1: convert the given color to HSV/HSB

Step 2: keep hue and saturation constant and adjust the brightness (make the color lighter or darker)

Step 3: convert the HSV/HSB value back to the required color format

Implementation in PHP

A simple calculation for a given RGB color is shown below. The classes used in this snippet are available on GitHub. The code checks the initial brightness of the color and lightens or darkens the values until the ‘border’ calculated by the ‘Weighted W3C Formula’ is reached. This is the case for the value 127, the total range of the brightness is 0 to 255.

$hsv = Convert::rgb2hsv($rgb);

$step = 0.01;
$brightness = Calculate::weightedW3C($rgb);
if ($brightness < 127) {
    while ($brightness < 127 && $hsv[2] >= 0 && $hsv[2] <= 1) {
        $hsv[2] += $step;
        $brightness = Calculate::weightedW3C(Convert::hsv2rgb($hsv));
    }
} else {
    while ($brightness > 127 && $hsv[2] >= 0 && $hsv[2] <= 1) {
        $hsv[2] -= $step;
        $brightness = Calculate::weightedW3C(Convert::hsv2rgb($hsv));
    }
}

return Convert::hsv2rgb($hsv);

Some examples

But how does this result look for different colors? Let’s start with some dark colors. Those are fine for a light background, but they become unreadable on a dark one. The top colors show the input color (before) and the color below shows the output of the calculation above (after).

Color #632300 adjusted to be readable on light and dark background
Color #454545 adjusted to be readable on light and dark background

And now let’s look at some light colors which are fine for dark backgrounds, but they are totally unreadable on light backgrounds.

Color #73FEFF adjusted to be readable on light and dark background
Color #F0C&96 adjusted to be readable on light and dark background

The last color is similar to the example at the beginning and as you can see, the optimized color has a much better readability. This could be achieved for both light and dark colors. The code example shown above is written in PHP. An adoption should be easily possible for any other coding or scripting language

The algorithm mentioned in this post is also available on GitHub https://github.com/mixable/color-utils. This package is usable with composer:

composer require mixable/color-utils

The optimized color can be calculated with:

use Mixable\Color\Calculate;
// ...

$hex = '#ffcc00';
$optimizedColor = Calculate::readableColorForLightAndDarkBackground($hex);

 

UX improvements: `enterkeyhint` to define action label for the keyboard of mobile devices

Usability

The enterkeyhint is a html attribute described in the HTML standard, which can be used to improve the context of action buttons of keyboards on mobile device.

The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.

It allows the following fixed values: enter, done, go, next, previous, search and send. Let’s have a look at those values and the resulting keyboard style on iOS:

<input>

The default behavior without any value.

<input enterkeyhint=”enter”>

The user agent should present a cue for the operation ‘enter’, typically inserting a new line.

<input enterkeyhint=”done”>

The user agent should present a cue for the operation ‘done’, typically meaning there is nothing more to input and the input method editor (IME) will be closed.

<input enterkeyhint=”go”>

The user agent should present a cue for the operation ‘go’, typically meaning to take the user to the target of the text they typed.

<input enterkeyhint=”next”>

The user agent should present a cue for the operation ‘next’, typically taking the user to the next field that will accept text.

<input enterkeyhint=”previous”>

The user agent should present a cue for the operation ‘previous’, typically taking the user to the previous field that will accept text.

<input enterkeyhint=”search”>

The user agent should present a cue for the operation ‘search’, typically taking the user to the results of searching for the text they have typed.

<input enterkeyhint=”send”>

The user agent should present a cue for the operation ‘send’, typically delivering the text to its target.

Photo by Melisa Hildt on Unsplash

 

Unarten im Netz – oder: wie werde ich meine Besucher los

Wer kennt sie noch, die guten alten Popups: kleine Browserfenster, die sich über den Browser gelegt haben. Und das meist, um Werbung anzuzeigen. Diese Zeiten sind zum Glück vorbei, da aktuelle Browser diese von Haus aus unterdrücken.

Doch es gibt eine neue Methode, um Benutzer auf einer Webseite abzuschrecken und zu verjagen: Inline-Overlays (also kleine “Popups” innerhalb der Webseite oder auch Modals genannt). Mit diesen wird der Nutzer meist nach der Emailadresse gefragt, um einen Newsletter zu abonnieren. Ok, ist nicht ganz so nervig wie ein blinkendes Werbe-Popup, aber dennoch unterbricht es den Lesefluss. Und dies meist dann, wenn man sich gerade am Anfang eines Artikels befindet, aus versehen den Mauszeiger aus dem Browserfenster bewegt oder etwas zurück scrollt, um Inhalte erneut zu lesen. Also bei Aktivitäten, die vermuten lassen, dass man das Fenster schließen möchte.

Aber warum? Eine Einschätzung zur Nutzerfreundlichkeit: 0 von 10. Der Nutzer bekommt teilweise nicht einmal die Möglichkeit, den Inhalt zu lesen und soll sich davor schon entscheiden einen Newsletter zu abonnieren. Meines Erachtens mehr abschreckend als nützlich. Denn in den heutigen Zeiten, in denen man immer noch sehr viel Spam im Postfach findet, wird es immer schwerer an Email-Adressen zu kommen.

Aber auch hier hilft Qualität statt Quantität: es wäre sinnvoller sich auf guten Inhalt zu konzentrieren, als zwanghaft zu versuchen, die Leute zu einem Newsletter zu überreden. Also liebe Webmaster: bitte lasst es!

Buttons in Dialogen: Ok und Abbrechen – rechts oder links?

Die Anordnung von Buttons ist meist abhängig vom Betriebssystem, diese Information sollte daher aus den entsprechenden User Interface Guidelines entnommen werden. Hier eine kurze Zusammenfassung:

Windows

Buttons sollten nach ihrer Aktion in folgender Reihenfolge (von links nach rechts) platziert werden:

OK/[Do it]/Ja
[Don’t do it]/Nein
Abbrechen
Annehmen (wenn vorhanden)
Hilfe (wenn vorhanden)

Abbrechen ist immer rechts vom Ok-Button.

MacOS

Ein Button der eine Aktion ausführt sollte am weitesten rechts platziert werden. Der Abbrechen-Button wird links daneben angeordnet. Bei MacOS ist Abbrechen also links von Ok.

Android

Die ablehnendste Aktion eines Dialogs ist immer auf der linken Seite. Ablehnende Aktionen bringen den Nutzer zurück zur letzten Ansicht.

Bestätigende Aktionen sind rechts. Diese Aktionen The affirmative actions are on the right. Bestätigende Aktionen führen den Prozess fort, welcher den Dialog aufgerufen hat. Bei Android ist Abbrechen also links von Ok.

Designrules im Webdesign, die häufig unterschätzt werden

Es gibt viele Dinge, welche zur Verbesserung der Benutzerfreundlichkeit einer Webseite beitragen. Doch auch wenn einige Designelemente gut aussehen, sie könnten einen Einfluss auf die Benutzerfreundlichkeit haben.

Zentrierte Logos schaden der Navigation auf Webseiten

Getting back to the homepage is about 6 times harder when the logo is placed in the center of a page compared to when it’s in the top left corners. (Quelle: nngroup.com)

Buttons sollten keinen Hand-Cursor haben

There is this belief that the hand cursor means “clickable”, but this is incorrect and potentially problematic. My hope is that by the end of the article, you’ll never want to use the hand cursor for buttons ever again. (Quelle: medium.com)

Ist das “mein” oder “dein” Interface?

Wann sollte man “mein” oder “dein” in Benutzeroberflächen nutzen? Kurz zusammengefasst:

  • mein (o.ä.) nutzen, wenn der Nutzer mit dem Produkt interagiert, beispielsweise klicken von Buttons oder auswählen von Checkboxen. Solche Wörter sollten aber nur verwendet werden, um etwas besonders hervor zu heben.
  • dein (o.ä.) verwenden, wenn das Produkt Fragen stellt, Anweisungen gibt oder dem Nutzer Dinge beschreibt. Eben so, wie es ein persönlicher Assistent tun würde.

(Quelle: medium.com)

Design Rules für Eingabefelder

Eingabefelder sind allgegenwertig. Jede Interaktion mit Benutzeroberflächen, egal ob über Desktops oder mobile Endgeräte, erfordert Eingabefelder. Kurz zusammengefasst, welche Punkte hier wichtig sind:

  • Position von Labels: die beste Position für Labels ist links oberhalb vom Eingabefeld. Damit wurden Formulare am schnellsten ausgefüllt. Labels links neben dem Input fuhrten hingegen zu einer Verlangsamung beim Ausfüllen, da hier die Augenbewegung deutlich zunimmt.
  • Platzhalter: Platzhalter sind hilfreich, jedoch nicht wenn diese beim Fokus auf das Eingabefeld verschwinden. Also lieber ein aussagekräftiges Label verwenden. Eine neue Methode, bei dem der Platzhalter beim Fokus auf das Eingabefeld zum Label wird, könnte diesen Nachteil ausmerzen.
  • Keyboard: einige Eingabefelder erfordern nur Zahlen als Eingabe. Auf mobilen Endgeräten kann die Nummerblock-Tastatur sehr hilfreich sein. Aktivieren lässt sich diese durch “tel” als type oder das Attribut “pattern=”[0-9]*”.

(Quelle: uxbooth.com – The New Rules of Form Design)

Cards

Cards sind eine beliebte Möglichkeit, mehrere Elemente auf einer Seite darzustellen. Eigentlich sehr einfach umzusetzen, doch es gibt einige Dinge, die man beachten sollte. Auf zurb.com sind 5 Fehler aufgelistet, die häufig beim Erstellen von Cards gemacht werden. dazu gehören:

  • Große Freiräume durch unterschiedliche Höhen der Cards
  • Zu viele Cards auf einmal
  • Zu viele Aktionen innerhalb einer Card
  • Zu viele Inhalte in einer Card
  • Graphiken in Cards, wenn diese nicht zwingend benötigt werden.

(Quelle: zurb.com – 5 Common Mistakes Designers Make When Using Cards In Design)