Tuesday, April 18, 2017

A better March Madness script?

Last year, I wrote an article for Linux Journal describing how to create a Bash script to build your NCAA "March Madness" brackets. I don't really follow basketball, but I have friends that do, so by filling out a bracket at least I can have a stake in the games.

Since then, I realized my script had a bug that prevented any rank 16 team from winning over a rank 1 team. So this year, I wrote another article for Linux Journal with an improved Bash script to build a better NCAA "March Madness" bracket. In brief, the updated script builds a custom random "die roll" based on the relative strength of each team. My "predictions" this year are included in the Linux Journal article.

Since the games are now over, I figured this was a great time to see how my bracket performed. If you followed the games, you know that there were a lot of upsets this year. No one really predicted the final two teams for the championship. So maybe I shouldn't be too surprised if my brackets didn't do well either. Next year might be a better comparison.

In the first round of the NCAA March Madness, you start with teams 1–16 in four regions, so that's 64 teams that compete in 32 games. In that "round of 64," my shell script correctly predicted 21 outcomes. That's not a bad start.

March Madness is single-elimination, so for the second round, you have 32 teams competing in 16 games. My shell script correctly guessed 7 of those games. So just under half were predicted correctly. Not great, but not bad.

In the third round, my brackets suffered. This is the "Sweet Sixteen" where 16 teams compete in 8 games, but my script only predicted 2 of those games.

And in the fourth round, the "Elite Eight" round, my script didn't predict any of the winners. And that wrapped up my brackets.

Following the standard method for how to score "March Madness" brackets, each round has 320 possible points. In round one, assign 10 points for each correctly selected outcome. In round two, assign 20 points for each correct outcome. And so on, double the possible points at each round. From that, the math is pretty simple.

round one:21 × 10 =210
round two:7 × 20 =140
round three:1 × 40 =40
round four:0 × 80 =0
My total score this year is 390 points. As a comparison, last year's script (the one with the bug) scored 530 in one instance, and 490 in another instance. But remember that there were a lot of upsets in this year's games, so everyone's brackets fared poorly this year, anyway.

Maybe next year will be better.

Did you use the Bash script to help fill out your "March Madness" brackets? How did you do?

Monday, April 3, 2017

How many testers do you need?

When you start a usability test, the first question you may ask is "how many testers do I need?" The standard go-to article on this is Nielsen's "Why You Only Need to Test with 5 Users" which gives the answer right there in the title: you need five testers.

But it's important to understand why Nielsen picks five as the magic number. MeasuringU has a good explanation, but I think I can provide my own.

The core assumption is that each tester will uncover a certain amount of issues in a usability test, assuming good test design and well-crafted scenario tasks. The next tester will uncover about the same amount of usability issues, but not exactly the same issues. So there's some overlap, and some new issues too.

If you've done usability testing before, you've observed this yourself. Some testers will find certain issues, other testers will find different issues. There's overlap, but each tester is on their own journey of discovery.

How many usability issues is up for some debate. Nielsen uses his own research and asserts that a single tester can uncover about 31% of the usability issues. Again, that assumes good test design and scenario tasks. So one tester finds 31% of the issues, the next tester finds 31% but not the same 31%, and so on. With each tester, there's some overlap, but you discover some new issues too.

In his article, Nielsen describes a function to demonstrate the number of usability issues found vs the number of testers in your test, for a traditional formal usability test:

…where L is the amount of issues one tester can uncover (Nielsen assumes L=31%) and n is the number of testers.

I encourage you to run the numbers here. A simple spreadsheet will help you see how the value changes for increasing numbers of testers. What you'll find is a curve that grows quickly then slowly approaches 100%.

Note at five testers, you have uncovered about 85% of the issues. Nielsen's curve suggests a diminishing return at higher numbers of testers. As you add testers, you'll certainly discover more usability issues, but the increment gets smaller each time. Hence Nielsen's recommendation for five testers.

Again, the reason that five is a good number is because of overlap of results. Each tester will help you identify a certain number of usability issues, given a good test design and high quality scenario tasks. The next tester will identify some of the same issues, plus a few others. And as you add testers, you'll continue to have some overlap, and continue to expand into new territory.

Let me help you visualize this. We can create a simple program to show this overlap. I wrote a Bash script to generate SVG files with varying numbers of overlapping red squares. Each red square covers about 31% of the gray background.

If you run this script, you should see output that looks something like this, for different values of n. Each image starts over; the iterations are not additive:








As you increase the number of testers, you cover more of the gray background. And you also have more overlap. The increase in coverage is quite dramatic from one to five, but compare five to fifteen. Certainly there's more coverage (and more overlap) at ten than at five, but not significantly more coverage. And the same going from ten to fifteen.

These visuals aren't meant to be an exact representation of the Nielsen iteration curve, but they do help show how adding more testers gives significant return up to a point, and then adding more testers doesn't really get you much more.

The core takeaway is that it doesn't take many testers to get results that are "good enough" to improve your design. The key idea is that you should do usability testing iteratively with your design process. I think every usability researcher would agree. Ellen Francik, writing for Human Factors, refers to this process as the Rapid Iterative Testing and Evaluation (RITE) method, arguing "small tests are intended to deliver design guidance in a timely way throughout development." (emphasis mine)

Don't wait until the end to do your usability tests. By then, it's probably too late to make substantive changes to your design, anyway. Instead, test your design as you go: create (or update) your design, do a usability test, tweak the design based on the results, test it again, tweak it again, and so on. After a few iterations, you will have a design that works well for most users.

Sunday, April 2, 2017

A throwback theme for gedit

This isn't exactly about usability, but I wanted to share it with you anyway.

I've been involved in a lot of open source software projects, since about 1993. You know that I'm also the founder and coordinator of the FreeDOS Project? I started that project in 1994, to write a free version of DOS that anyone could use.

DOS is an old operating system. It runs entirely in text mode. So anyone who was a DOS user "back in the day" should remember text mode and the prevalence of white-on-blue text.

For April 1, we used a new "throwback" theme on the FreeDOS website. We rendered the site using old-style DOS colors, with a monospace DOS VGA font.

Even though the redesign was meant only for a day, I sort of loved the new design. This made me nostalgic for using the DOS console: editing text in that white-on-blue, without the "distraction" of other fonts or the glare of modern black-on-white text.

So I decided to create a new theme for gedit, based on the DOS throwback theme. Here's a screenshot of gedit editing a Bash script, and editing the XML theme file itself:

The theme uses the same sixteen color palette from DOS. You can find the explanation of  why DOS has sixteen colors at the FreeDOS blog. I find the white-on-blue text to be calming, and easy on the eyes.

Of course, to make this a true callback to earlier days of computing, I used a custom font. On my computer, I used Mateusz Viste's DOSEGA font. Mateusz created this font by redrawing each glyph in Fontforge, using the original DOS CPI files as a model. I think it's really easy to read. (Download DOSEGA here: dosega.zip)

Want to create this on your own system? Here's the XML source to the theme file. Save this in ~/.local/share/gtksourceview-3.0/styles/dosedit.xml and gedit should find it as a new theme.
<?xml version="1.0" encoding="UTF-8"?>
  reference: https://developer.gnome.org/gtksourceview/stable/style-reference.html
<style-scheme id="dos-edit" name="DOS Edit" version="1.0">
<author>Jim Hall</author>
<description>Color scheme using DOS Edit color palette</description>
  Emulate colors used in a DOS Editor. For best results, use a monospaced font
  like DOSEGA.

<!-- Color Palette -->

<color name="black"           value="#000"/>
<color name="blue"            value="#00A"/>
<color name="green"           value="#0A0"/>
<color name="cyan"            value="#0AA"/>
<color name="red"             value="#A00"/>
<color name="magenta"         value="#A0A"/>
<color name="brown"           value="#A50"/>
<color name="white"           value="#AAA"/>
<color name="brightblack"     value="#555"/>
<color name="brightblue"      value="#55F"/>
<color name="brightgreen"     value="#5F5"/>
<color name="brightcyan"      value="#5FF"/>
<color name="brightred"       value="#F55"/>
<color name="brightmagenta"   value="#F5F"/>
<color name="brightyellow"    value="#FF5"/>
<color name="brightwhite"     value="#FFF"/>

<!-- Settings -->

<style name="text"                 foreground="white" background="blue"/>
<style name="selection"            foreground="blue" background="white"/>
<style name="selection-unfocused"  foreground="black" background="white"/>

<style name="cursor"               foreground="brown"/>
<style name="secondary-cursor"     foreground="magenta"/>

<style name="current-line"         background="black"/>
<style name="line-numbers"         foreground="black" background="white"/>
<style name="current-line-number"  background="cyan"/>

<style name="bracket-match"        foreground="brightwhite" background="cyan"/>
<style name="bracket-mismatch"     foreground="brightyellow" background="red"/>

<style name="right-margin"         foreground="white" background="blue"/>
<style name="draw-spaces"          foreground="green"/>
<style name="background-pattern"   background="black"/>

<!-- Extra Settings -->

<style name="def:base-n-integer"   foreground="cyan"/>
<style name="def:boolean"          foreground="cyan"/>
<style name="def:builtin"          foreground="brightwhite"/>
<style name="def:character"        foreground="red"/>
<style name="def:comment"          foreground="green"/>
<style name="def:complex"          foreground="cyan"/>
<style name="def:constant"         foreground="cyan"/>
<style name="def:decimal"          foreground="cyan"/>
<style name="def:doc-comment"      foreground="green"/>
<style name="def:doc-comment-element" foreground="green"/>
<style name="def:error"            foreground="brightwhite" background="red"/>
<style name="def:floating-point"   foreground="cyan"/>
<style name="def:function"         foreground="cyan"/>
<style name="def:heading0"         foreground="brightyellow"/>
<style name="def:heading1"         foreground="brightyellow"/>
<style name="def:heading2"         foreground="brightyellow"/>
<style name="def:heading3"         foreground="brightyellow"/>
<style name="def:heading4"         foreground="brightyellow"/>
<style name="def:heading5"         foreground="brightyellow"/>
<style name="def:heading6"         foreground="brightyellow"/>
<style name="def:identifier"       foreground="brightyellow"/>
<style name="def:keyword"          foreground="brightyellow"/>
<style name="def:net-address-in-comment" foreground="brightgreen"/>
<style name="def:note"             foreground="green"/>
<style name="def:number"           foreground="cyan"/>
<style name="def:operator"         foreground="brightwhite"/>
<style name="def:preprocessor"     foreground="brightcyan"/>
<style name="def:shebang"          foreground="brightgreen"/>
<style name="def:special-char"     foreground="brightred"/>
<style name="def:special-constant" foreground="brightred"/>
<style name="def:specials"         foreground="brightmagenta"/>
<style name="def:statement"        foreground="brightmagenta"/>
<style name="def:string"           foreground="brightred"/>
<style name="def:type"             foreground="cyan"/>
<style name="def:underlined"       foreground="brightgreen"/>
<style name="def:variable"         foreground="cyan"/>
<style name="def:warning"          foreground="brightwhite" background="brown"/>