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
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:

# read color and background color:

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

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

# 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"
        echo "Not good for body text"
if [ ${rel%.*} -ge 3 ] ; then
        echo "Ok for title text"
        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 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

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.

Saturday, January 7, 2017

The importance of the press kit

I'd like to share a few lessons I've learned about creating a press kit. This helped us spread the word about our recent FreeDOS 1.2 release, and it can help your open source software project to get more attention.
I'm part of several open source software projects, but probably the one that I'll be remembered for is FreeDOS. As an open source software implementation of DOS, you might not think that FreeDOS will get much attention in today's tech news. Yet when we released FreeDOS 1.2 a few weeks ago, we got a ton of news coverage.

Slashdot was the first to write about FreeDOS 1.2, but we also saw coverage from Engadget Germany, LWN, Heise Online, PC Forum Hungary, FOSS Bytes, ZDNet Germany, PC Welt, Tom's Hardware, and Open Source Feed. And that's just a sample of the news! There were articles from the US, Germany, Japan, Hungary, Ukraine, Italy, and others.

In reading the articles people had written about FreeDOS 1.2, I realized something that was both cool and insightful: most tech news sites re-used material from our press kit.

You see, in the weeks leading up to FreeDOS 1.2, I assembled additional information and resources about FreeDOS 1.2 release, including a bunch of screenshots and other images of FreeDOS in action. In an article posted to our website, I highlighted the press kit, and added "If you are writing an article about FreeDOS, feel free to use this information to help you." And they did!

We track a complete timeline of interesting events on our FreeDOS History page, including links to articles. Comparing the press coverage from FreeDOS 1.0, FreeDOS 1.1 and FreeDOS 1.2, we definitely saw the most articles about FreeDOS 1.2. And unlike previous releases where only a few tech news websites wrote articles about FreeDOS and other news outlets mostly referenced the first few sites, the coverage of FreeDOS 1.2 was mostly original articles. Only a small handful were references to news items from other news sites.

I put that down to the press kit. With the press kit, journalists were able to quickly pull interesting information and quotes about FreeDOS, and find images they could use in their articles. For a busy journalist who doesn't have much time to write about a free DOS implementation in 2016, our press kit made it easy to create something fresh. And news sites love to write their own stories rather than link to other news sites. That means more eyeballs for them.

Here are a few lessons I learned from creating our press kit:
Include basic information about your open source software project.
What is your project about? What does it do? How is it useful? Who uses it? What are the new features in this release? These are the basic questions any journalist will want to answer in their article, if they choose to write about you. In the FreeDOS press kit, I also included a history about FreeDOS, discussing how we got started in 1994 and some highlights from our timeline.
Write in a casual, conversational tone that's easy to quote.
In writing about your project, pretend you are writing an email to someone you know. Or if you prefer, write like you are posting something to a personal blog. Keep it informal. Avoid jargon. If your language is too stuffy or too technical, journalists will have a hard time quoting from you. In writing the FreeDOS press kit, I started by listing a few common questions that people usually ask me about FreeDOS, then I just responded to them like I was answering an email. My answers were often long, but the paragraphs were short so easier to skim.
Provide lots of screenshots of your project doing different things.
Whether your program runs from the command line or in a graphical environment, screenshots are key. And tech news sites like to use images; they are a cheap way to draw attention. So take lots of screenshots and include them in your press kit. Show all the major features through these screenshots. But be wary of background images and other branding that might distract from your screenshots. In particular, if the screenshot will show your desktop, set your wallpaper to the default for your operating system, or use a solid color in the range medium- to light-blue. For the FreeDOS press kit, I took a ton of screenshots of every step in the install process. I also grabbed screenshots of FreeDOS at the command line, running utilities and tools, and playing some of the games we installed.
Organize your material so it's easy to read.
You may find your press kit will become quite long. That's okay, as long as this doesn't make it difficult for someone to figure out what's there. Put the important stuff first. Use a table of contents, if you have a lot of information to share. Use headings and sections to break things up. If a journalist can't find the information they need to write an article about your project, they may skip it and write about something else. I organized our press kit like a simple website. An index page provided some basic information, with a list of links to other material contained in the press kit. I arranged our screenshots in separate "pages." And every page of screenshots started with a brief context, then listed the screenshots without much fanfare. But every screenshot included a description of what you were seeing. For example, I had over forty screenshots from installing FreeDOS, and I wrote a one-sentence description for each.
Be your own editor.
No matter how much work you put into it, one will want to use your press kit if it is riddled with spelling errors and poor grammar. Consider writing your press kit material in a word processor and running a spell check against it. Read your text aloud and see if it makes sense to you. When you're done, try to look at your press kit from the perspective of someone who hasn't used your project before. Can they easily understand what it's about? To help you in this step, ask a friend to review the material for you.
Advertise, advertise, advertise!
Don't assume that tech news sites will seek you out. You need to reach out to them to let them know you have a new release coming up. Create your press kit well in advance, and about a week or two before your release, individually email every journalist or tech news website that might be interested in you. Most news sites have a "Contact us" link or list of editor "beats" where you can direct yourself to the writer or editor most likely to write about your topic. Craft a short email that lets them know who you are, what project you're from, when the next release will happen, and what new features it will include. Give them a link to the press kit directly in your email. But make the press kit easy to see in the email. Use the full URL to the press kit, and make it clickable. Also link to the press kit from your website, so anyone else who visits your project can quickly find the information they need to write an article.
By doing a little prep work before your next major release, you can increase the likelihood that others will write about you. And that means you'll get more people who discover your project, so your open source software project can grow.

Thursday, December 29, 2016

2016 year in review, bonus

Last week, I shared a "top ten" list of my favorite blog posts from Open Source Software and Usability. As I reviewed my articles this year, I also saw a few others that I wanted to share as a kind of "bonus" list. These aren't about usability. Rather, they are exercises in Bash shell scripting that I found interesting.

My background with Linux started with Unix systems. I was a Unix systems administrator for several years before I introduced Linux at work. When I managed systems for a living, I learned to do a lot of cool things in shell scripts. And these days, sometimes I like to craft something new in a Bash script. Enjoy!

Reading RSS with Bash
A summary of an article I wrote for Linux Journal. The idea originated with an update to the FreeDOS website. Like many other project websites, we fetch our news from a separate news system, then parse it to display on the front page. Today, we do that every time someone loads the page. Effective, but inefficient. As I update the FreeDOS website, I wanted to automate the news feed to generate a static news "include" file, so I decided to do it in Bash.
Web comics using a Bash script
Another article I wrote for Linux Journal. I follow several web comics. Every morning, I used to open my browser and check out each comic's web site to read that day's comic. That method worked well when I read only a few web comics, but it became a pain to stay current when I followed more than about ten comics. I figured there had to be a better way, a simpler way for me to read all of my web comics at once. So I wrote a Bash script that automatically collects my web comics and puts them on a single page on a personal web server in my home. Now, I just open my web browser to my private web server, and read all my comics at once.
Solitaire in a Bash script
I wanted to write my own version of Klondike Solitaire as a Bash script. Sure, I could grab another shell script implementation of Solitaire called Shellitaire but I liked the challenge of writing my own. And I did. Or rather, I mostly did. I have run out of free time to work on it. So I'm sharing it here in case others want to build on it. I have implemented most of the game, except for the card selection.
March Madness in a Bash script
I don't really follow basketball, but I like to engage with others at my office who do. But I just don't know enough about the teams to make an informed decision on my own March Madness bracket. So a few years ago, I found another way: I wrote a little Bash script to do it for me. I wrote a similar version of the article for Linux Journal, and later compared the results. However, I have since discovered a major flaw in this Bash script which I've now fixed. Look for that article coming soon in Linux Journal.