Monday, February 20, 2017

More about DOS colors

In a followup to my discussion about the readability of DOS applications, I wrote an explanation on the FreeDOS blog about why DOS has sixteen colors. That discussion seemed too detailed to include on my Open Source Software & Usability blog, but it was a good fit for the FreeDOS blog.

It's an interesting overview of how color came to be encoded on PC-compatible computers. The brief overview is this:

CGA, the Color/Graphics Adapter from the earlier PC-compatible computers, could mix red (R), green (G) and blue (B) colors. So that's eight colors, from 000 Black to 111 White.

Add an "intensifier" bit, and you have sixteen colors, eight colors from 0000 Black to 0111 White, and another eight colors from 1000 Bright Black to 1111 Bright White.

There's a bit more about the background and the bit-pattern to represent colors. Read the full article for more: Why DOS has sixteen colors

The readability of DOS applications

My recent article about how web pages are becoming hard to read had me wondering: I grew up with DOS, and I still work with DOS, so what's the readability of DOS applications?

Web pages are mostly black-on-white or dark-gray-on-white, but anyone who has used DOS will remember that most DOS applications were white-on-blue. Sure, the DOS command line was white-on-black, but almost every popular DOS application used white-on-blue. (It wasn't really "white" but we'll get there.) Do an image search for any DOS application from the 1980s and early 1990s, and you're almost guaranteed to yield a forest of white-on-blue images like these:

FreeDOS 1.2 install program

As Easy As, the shareware DOS spreadsheet

Free Point of Sale for DOS, by Dale Harris

DosZip, the file manager for DOS

FreeDOS EDIT

DOS is an old operating system. DOS stands for "Disk Operating System" and was designed to let you run applications. People like to think of DOS as being a command-line operating system, and while you could do manipulate file contents at the command prompt with a limited set of tools, DOS really didn't have the rich set of command-line tools like Unix and Linux enjoy. You mostly used the DOS command line to run different applications.

As an operating system interface, DOS was entirely text-based. It used BIOS services on your computer to do most of its work, including displaying text. With DOS, you had a color palette of sixteen colors, enumerated 0 (black) to F (bright white). But most users didn't know the 0–F codes, only the sixteen ANSI escape codes, divided into "normal" and "bright" modes. I've also included the RGB color representation of each:
NormalBright
30Black0,0,0Gray85,85,85
31Red170,0,0Bright Red255,85,85
32Green0,170,0Bright Green85,255,85
33Brown170,85,0Yellow255,255,85
34Blue0,0,170Bright Blue85,85,255
35Magenta170,0,170Bright Magenta255,85,255
36Cyan0,170,170Bright Cyan85,255,255
37White170,170,170Bright White255,255,255
You used these codes by loading an ANSI driver (called ANSI.SYS on MS-DOS, or NANSI.SYS on FreeDOS) and entering an ANSI escape sequence. Most people I know used the ANSI escape codes to make their DOS prompt more colorful, which you could do by using $E to represent an ESC character. For example, you could set red text with $E[31m or bright red text with $E[31;1m. Similarly, the range 40–47 represented background colors.

You may wonder about the brown/yellow line. That's not a typo; it wasn't really "yellow" and "bright yellow" although some references did call them that.

The general trend in the RGB color representations is the "normal" mode colors use 0 or 170, but "bright" mode colors replace 0 with 85 and 170 with 255.

If you have any familiarity with DOS, you should remember most applications using white-on-blue text. But how readable was this text? Using a Bash script to calculate contrast ratios of text, we can compute the readability of a few common color configurations from popular DOS applications.

White text on a blue background was generally considered (at the time) as easier to read, and prettier to look at, than plain white-on-black. And if you've sprung for that expensive monitor that can display colors, you want color. So white-on-blue quickly became a de facto standard.

Remember that DOS didn't support styling of text. You couldn't do italics or bold. Instead, applications such as word processors used colors to represent styles. Most text would be displayed as white-on-blue. Bold text was bright-white-on-blue, italics text was often green-on-blue or cyan-on-blue, and headings were often yellow-on-blue. Error messages might appear in white-on-red or black-on-red with the title in bright-white-on-red. Warnings might be black-on-brown or white-on-brown with yellow-on-brown titles. Status lines were frequently black-on-cyan or black-on-white.

Let's examine the contrast ratios of these color combinations:
White on Blue5.71
Bright White on Blue13.29
Yellow on Blue12.45
Green on Blue4.26
Cyan on Blue4.63
Black on Red2.70
White on Red3.33
Bright White on Red7.75
Black on Brown4.00
White on Brown2.25
Yellow on Brown4.91
Black on Cyan7.32
Black on White9.03
The W3C definition of the contrast ratio falls in the range 1 to 21 (typically written 1:1 or 21:1). The higher the contrast ratio, the more the text will stand out against the background. For example, black text on a white background has a contrast ratio of 21:1.

The W3C says body text should have a contrast ratio of at least 4.5:1, with headings at least 3:1. But that seems to be the bare minimum. The W3C also recommends at least 7:1 for body text and at least 4.5:1 for headings.

But it's also important to remember that DOS text was quite large, compared to today's standards. By default, DOS used an 80-column, 25-line display. Even on a modest 15-inch display (not unreasonable for the time) each character is around .15" [3.81mm] wide and .36" [9.144mm] high. That's quite large compared to today's websites that may use 11pt text. (Assuming your DPI is set correctly for your display, if 72pt is an inch, 11pt is about .152" [3.86mm] high.)

With text at that scale, I think that means the minimum contrast ratio for DOS applications can be somewhere between the W3C's recommendations for body text and heading text. Let's assume a round number of about 4:1.

So how do DOS applications stack up? Notice that white-on-blue is a very comfortable 5.71. Actually, in the above examples, all text on the blue background is quite readable. Other colors are quite clear, as well. Only black-on-red (2.70), white-on-red (3.33) and white-on-brown (2.25) fall below the recommended minimum of 4:1.

Let's examine the DOS application screenshots. The FreeDOS 1.2 installer uses black-on-white (9.03) for its main text, with list selection in yellow-on-blue (12.75). The FreeDOS EDIT program uses white-on-blue (5.71) for its main text, with its menu in black-on-white (9.03) and status bar in black-on-cyan (7.32).

The As Easy As spreadsheet used white-on-blue (5.71) for its main text and data enty line, with comments in green-on-blue (4.26) column and row labels in black-on-white (9.03) and black-on-white (9.03) status bar and white-on-black (9.03) hint line.

These are all very easy to read colors, even by today's standards. I'm not suggesting that websites switch to a white-on-blue color scheme, but it is interesting to note that even with a simple color palette, DOS applications were doing okay for readability.

Saturday, February 18, 2017

Calculating contrast ratios of text

In a comment on my other article about how web pages are becoming hard to read, Shaun referenced the W3C Web Content Accessibility Guidelines. They provide an algorithm to determine if your text meets minimum accessibility guidelines.

The W3C definition of the contrast ratio requires several calculations: given two colors, you first compute the relative luminance of each (L1 and L2) then calculate the contrast ratio. The ratio will fall in the range 1 to 21 (typically written 1:1 or 21:1). The higher the contrast ratio, the more the text will stand out against the background. For example, black text on a white background has a contrast ratio of 21:1.

The W3C says body text should have a contrast ratio of at least 4.5:1, with headings at least 3:1. But that seems to be the bare minimum. The W3C also recommends at least 7:1 for body text and at least 4.5:1 for headings.

Calculating this can be a chore, so it's best to automate it. Shaum implemented the algorithm in XSLT so he could test the various colors in websites. I created a similar implementation using Bash. It's a little ugly, but I thought I'd share it here:

First, you need a way to input colors. I wanted something that could interpret different representations of colors: in html and css, black is the same as #000 or #000000 or rgb(0,0,0). When evaluating the readability of my text, I might want to use any of these.

Fortunately, there's a neat tool in GNOME to provide that input. GNOME Zenity is a scripting tool to display GTK+ dialogs. It supports many modes to read input and display results. One of the input modes is a color selector, which you use this way:
zenity --color-selection
You can give it other options to set the window title and provide a default color. Zenity returns the selected color on standard output. You can even set a default color. So to present two dialogs, one to read the text color and another to read the background color, you simply do this:
color=$( zenity --title 'Set text color' --color-selection --color='black' )
background=$( zenity --title 'Set background color' --color-selection --color='white' )
Zenity returns values like rgb(255,140,0) and rgb(255,255,255), which is fortunate because the W3C calculation for luminance requires values in the range 0 to 255. I wrote a simple function to pull apart the RGB values. There are probably simpler ways to parse RGB, but a quick and easy way is to let awk split the values at the comma. That means a value like rgb(255,140,0) gets split into rgb(255 and 140 and 0) so the R value is a substring starting at the fifth character, G is the second element, and B is a substring up to the last parenthesis.

Once I have the RGB values, then I calculate the luminance using bc. The funky math with e() and l() are to get around a limitation in bc. Specifically, the formula requires a fractional power, and bc can only do integer powers. But if you follow the math, you can get there using e() and l():
function luminance()
{
        R=$( echo $1 | awk -F, '{print substr($1,5)}' )
        G=$( echo $1 | awk -F, '{print $2}' )
        B=$( echo $1 | awk -F, '{n=length($3); print substr($3,1,n-1)}' )

        echo "scale=4
rsrgb=$R/255
gsrgb=$G/255
bsrgb=$B/255
if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 * l((rsrgb+0.055)/1.055) )
if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 * l((gsrgb+0.055)/1.055) )
if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 * l((bsrgb+0.055)/1.055) )
0.2126 * r + 0.7152 * g + 0.0722 * b" | bc -l
}
Once you have the luminance value of the text color and background color, you can compute the contrast ratio. The W3C formula to do this is quite simple, but requires knowing which is the lighter and darker colors. This is an extra step in bc. I wrote this Bash function to calculate the ratio based on two colors:
function contrast()
{
        echo "scale=2
if ( $1 > $2 ) { l1=$1; l2=$2 } else { l1=$2; l2=$1 }
(l1 + 0.05) / (l2 + 0.05)" | bc
}
With those functions, it's fairly straightforward to write a Bash script that reads two colors, then computes the contrast ratio. My script also uses Zenity to output the data:
#!/bin/sh

# read color and background color:

color=$( zenity --title 'Set text color' --color-selection --color='black' )
if [ $? -ne 0 ] ; then
        echo '** color canceled - assume black'
        color='rgb(0,0,0)'
fi

background=$( zenity --title 'Set background color' --color-selection --color='white' )
if [ $? -ne 0 ] ; then
        echo '** background canceled - assume white'
        background='rgb(255,255,255)'
fi

# compute luminance:

function luminance()
{

}

lum1=$( luminance $color )
lum2=$( luminance $background )

# compute contrast

function contrast()
{

}

rel=$( contrast $lum1 $lum2 )

# print results

( echo "Color is $color on $background"
echo "Contrast ratio is $rel"

if [ ${rel%.*} -ge 4 ] ; then
        echo "Ok for body text"
else
        echo "Not good for body text"
fi
if [ ${rel%.*} -ge 3 ] ; then
        echo "Ok for title text"
else
        echo "Not good for title text"
fi) | zenity --text-info --title='Contrast Ratio'
With this script, I have a handy way to calculate the contrast ratio of two colors: text color vs background color. For black text on a white background, the contrast ratio is 21.00, the most visible. The #333 dark gray on white has a contrast ratio of 12.66, which is fine. And the lighter #808080 gray on white has a contrast ratio of 3.95, too low for normal text but acceptable for large text like headings. Very light #ccc gray on white has a contrast ratio of 1.60, which is way too low.

Wednesday, February 15, 2017

I can't read your website

An article at Backchannel discusses an interesting trend in website design, and how the web became unreadable. It's a good read, but I'll summarize briefly:

Web pages are becoming too hard to read.

Put another way, a popular trend in web design is to use low-contrast text. Maybe that looks really cool, but it is also really hard to read. From the article: "I thought my eyesight was beginning to go. It turns out, I’m suffering from design."

I've noticed this trend too, and I do find it hard to read certain websites. Even this blog used to use a #333 dark grey text on white, just because I thought it looked better that way. And to be honest, others were doing it, so I did it too. But when I changed the text to black on white, I find my blog easier to read. I hope you do too.

The colors you choose for your text can affect the readability of your site. This is directly connected to usability.

Don't believe me? Here is a sample paragraph, repeated using different colors.

White on black:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Black on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
White on dark gray:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Dark grey on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
White on gray:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Gray on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Which one do you find easiest to read?

Saturday, February 11, 2017

Experimenting with LibreOffice 5.3

I finally installed LibreOffice 5.3 to try it out. (This is actually version 5.3.0.3.) This version comes with a new interface called MUFFIN, which I wrote about as LibreOffice updating its user interface.

MUFFIN stands for My User Friendly Flexible INterface. Because someone clearly wanted that acronym to spell "MUFFIN." The new interface is still experimental, so you'll need to activate it through Settings→Advanced. When you restart LibreOffice, you can use the View menu to change modes. The new interface has several modes:
  1. Default
  2. Single Toolbar
  3. Sidebar
  4. Notebookbar
You can probably guess what the first three modes are about. These just tweak the interface in different ways, but I'd say it's still very "LibreOffice-y."

The last mode, Notebookbar, is interesting. This is very similar in concept to the Microsoft Office Ribbon. People who come from an Office background and are used to how Ribbon behaves, and how it changes based on what you are working on, should like the Notebookbar setting.

And in Notebookbar, you have a few options:
  1. Contextual groups
  2. Contextual single
  3. Tabbed
For me, "Tabbed" was the default when I activated Notebookbar. LibreOffice functions are divided into different tabs, which are clearly labelled. New tabs appear and disappear as suits the context of what you are working on. For example, if you insert a table, then when you go into the table, you get a "Table" tab, with different table-oriented actions like adding a new row or column.

Here are a few quick screenshots of the different tabs in Notebookbar. The "Home" tab is the default, so that's my first screenshot:








I haven't experimented too much with the other modes in Notebookbar, but "Contextual single" gives you a single action bar loaded with icons. I find it too busy, even though there's a lot of empty space in it. The single bar just "feels" too busy.

"Contextual groups" is closer to what you might think of as the "Microsoft Office Ribbon." Rather than adding new tabs to expose new functionality, the Notebookbar changes the content of the bar to add features as they are needed. If you insert a new table, then a table style menu appears. Exit the table, and the Notebookbar removes the table style menu in favor of other actions.

I'll need more time to explore and experiment with Notebookbar. My first impression is that I like it, and that I prefer tabs to contextual groups. I may share more on this blog as I continue to learn the new interface.

Friday, February 10, 2017

Microsoft's next Windows RT

Apologies for the brief diversion while I discuss Windows.

The Inquirer recently wrote about a future version of "Windows Cloud" that Microsoft will (one day) push its users to, probably whether or not you want it, just as they pushed their Windows 7 users to Windows 10. The difference is that the new operating system isn't really what you think of as "Windows." Instead, it's more like a Chromebook.

Now, I have no problem with the Google Chromebook. The Chromebook has a lot of great use-applications. The platform becomes irrelevant. Instead of a traditional operating system, you get a desktop and a web browser. All your applications are in "the Cloud," so Google's G Suite for your word processor, spreadsheet, and presentation software (think Word, Excel, and Powerpoint). Your email is in Gmail. And anything else you want to do is on a website somewhere. It's a great platform for a highly mobile world.

My wife has a Chromebook, and she loves it! In fact, she's thinking it's time to upgrade to the new Chromebook that's coming out soon.

I used to run a Chromebook when I was the campus CIO at a small university; I ran Linux on my desktop, but for meetings I usually brought my Chromebook.

At that same university, I envisioned that we would someday replace our meeting room PCs with Chromeboxes (the desktop version of a Chromebook) or Chromebits (a "micro" version of a Chromebox that plugs directly into an HDMI slot on a display). And we probably could have replaced many of our classroom PCs and general lab PCs with Chromeboxes or Chromebits; as a Google campus, all our apps were in Google's Cloud, so G Suite and Gmail.

Chromebooks ($200) and Chromeboxes ($150) and Chromebits ($100) are great Cloud-integrated systems at a low price. But that's the trick: the core assumption is that everything is in the Cloud. You don't run local applications on a Chromebook. You can't install applications on a Chromebook.

And now Microsoft seems set to move into this space, as well. The difference is that "Windows Cloud" (as they call it) will be a Cloud-integrated system with the "Windows" label on it. And people expect to install applications on "Windows."

The Inquirer article makes a great point here, both acknowledging why Microsoft would want to move to Windows Cloud, while questioning the wisdom of doing so:
There is a logic to Microsoft's entry into this market. Google's Chromebooks do well in certain markets, thanks to their low cost and zippy speeds on even low power processors, and Microsoft would naturally want to swipe some of that market.

However, despite improvements to Windows Universal Apps, explaining to the average consumer that they can't run their existing programs on their new computer is going to be as problematic as ever, and calling it "Windows 10" is going to mess with people's heads, as quite clearly, it isn't.

It feels like Microsoft are missing the point. If you buy a Chromebook, you know what you are getting. But if you buy a Windows machine, you have 30 years of heritage and expectation attached to the brand and people aren't going to be happy if you deliver a new version with less.
That last paragraph says it all. I think if Microsoft wanted to do a "Cloud-integrated" system like this, it would be better to avoid the "Windows" name. Maybe adopt the "Surface" name, like "Surface Cloud." Or leverage the "Edge" web browser name, and call it the "Edgebook" or something along those lines. At least then, users would carry different expectations to the new product.

Maybe this is a signal that it's time for Microsoft to retire the "Windows" label. Sure, Microsoft probably does want to shift it's operating system into the Cloud (whether or not that's a good thing, I'll leave that to you) but keeping the "Windows" label will hold them back. Learn from the disaster of "Windows RT" where users quickly discovered that while it looked like Windows and felt like Windows, you couldn't install "Windows" applications on it. With a new name, Microsoft can shift user expectations.

Saturday, January 28, 2017

Good usability but poor experience

Usability is about real people using the system to do real tasks in a reasonable amount of time. You can find variations of this definition by different researchers, including more strict definitions that include the five attributes of Usability:

1. Learnability
How easily you can figure out the interface on your own.
2. Efficiency
How quickly you can accomplish your tasks.
3. Memorability
Having used the software at least once, how easily can you recall how to use it the next time you use it?
4. Error rate
When using the software, how often users tend to make mistakes.
5. Satisfaction
If the software is pleasing to use.
However, that last item is treading on different territory: User eXperience (UX). And UX is different from usability.

If usability is about real people using the software to do real tasks in a reasonable amount of time, User eXperience is more about the user's emotional response when using the software. Or their emotional attachment to the software. UX is more closely aligned to the user's impression of the software beyond usability, beyond using the software to complete tasks.

Usually, usability and UX go together. A program with good usability tends to have positive UX. A program with poor usability tends to have negative UX. But it is possible for them to differ. You can have a program that's difficult to use, but the user is happy using it. And you can have a program that's very simple to use, but the user doesn't really like using it.

Let me give you an example: a simple music player. It's so simple that it doesn't have a menu. There's an "Add songs to playlist" button that seems obvious enough. The play and stop buttons are obvious (a button with the word "Play" to play music, and a button next to it labelled "Stop" to stop playing music.). To change the volume, there's a simple slider labeled "Volume" that has "quiet" and "loud" on each end of the slider.

It's easy to use. The music player is obvious and well-labeled. You can imagine it scores well with Learnability, Efficiency, Memorability, and Error rate.

But it's bare. There's no decoration to it. The program uses a font where the letters are blocky, small-caps, and spaced very close together. It uses the same font in the music list.

And the colors. Everything is white-on-black. The "Play" button is a sort of sickly green, and the "Stop" button is a sort of reddish-brown. The "Add songs to playlist" button is a weird purple. The box that shows the music play list is an eerie green.
Girls Just Want To Have Fun; Cyndi Lauper
Beat It; Michael Jackson ♪playing
When Doves Cry; Prince
Karma Chameleon; Culture Club
Love Is A Battlefield; Pat Benatar


Volume:
quiet————loud
The program works well, but you just don't like using it. Every time you use the music player, your stomach turns. The colors are depressing. As soon as you load your play list and start playing, you cover the window with another window so you don't have to look at the program. After you use it a few times, you switch to another program. Even if the other program isn't as easy to use, at least you'll like using the other music player.

So that's one example of a program that would have good usability but negative UX.