Saturday, December 16, 2017

Top ten in 2017 (part 1 of 2)

It's been a great year in the usability of open source software. As I look back on the last twelve months, I thought it would be interesting to highlight a few of my favorite blog posts from the year. And here they are, in no particular order:

1. The importance of the press kit
In December 2016, we released FreeDOS 1.2. Throughout December and into January, FreeDOS was the subject of many many articles in tech press, magazines, websites, and journals. I credit our press kit, which made it really easy for anyone to write an article about FreeDOS. In this essay, I explain how we created our press kit, and the features your open source software press kit should contain so journalists can write about you.
2. Good usability but poor user experience
I like to remind people that usability is not the same as user experience. They really are two different concepts. Usability is about making software that real people can use to do real tasks in a reasonable amount of time. User experience is more about the emotional response users have when they use the software. Often, programs that have good usability will have a positive user experience, and vice versa. But it's possible for a program to have good usability and a negative user experience. Here's one example.
3. I can't read your website
The current trend in website design seems to be grey text on a light background. That's really hard for most people to read. And your small font sizes aren't helping, either. Here are a few examples of the same stanza of text in different styles. See also Calculating contrast ratios of text and The readability of DOS applications as interesting followup.
4. Screencasts for usability testing
When you're moderating a usability test, you may ask your testers to use the "speak aloud" protocol, where they say out loud what they are trying to do. If they are looking for a Print button, they should say "I'm looking for a Print button." As the tester works through the usability test, you might take notes about what the tester is doing, and where they are "looking" with their mouse. An easier way to track this is to record a screencast, for later playback. Here's an example in GNOME.
5. How many testers do you need?
Usability testing in open source software isn't that hard. But when I talk about how to do a usability test in open source software, most people ask me "How many testers do I need?" It turns out that you don't need that many people. The short answer is "about five."

I'll share part two of my top-ten list next week!

Sunday, December 10, 2017

The art of the usability interview

During a usability test, it's important to understand what the tester is thinking. What were they looking for when they couldn't find a button or menu item? During the usability test, I recommend that you try to observe, take notes, capture as much data as you can about what the tester is doing. Only after the tester is finished with a scenario or set of scenarios should you ask questions.

But how do you ask questions in a way to gain the most insight? Asking the right questions can sometimes be an art form; it certainly requires practice. A colleague shared with me a few questions she uses in her usability interviews, and I am sharing them here for your usability interviews:

Before starting a scenario or set of scenarios:

  • What are three things you might do in this application?
  • What menu options do you see here and what do you think they do?
  • What might you do on this panel?
  • What is your first impression of the application?
  • What do these icons do? What do they represent?

After finishing a set of scenarios:

  • Who do you think the application was created for?
  • How easy did you think it was to get around the application?
  • If you could make one change to the application, what would it be?
  • Is there a feature you think is missing?
  • Do you remember any phrases or icons that you didn't understand?

The goal is to avoid leading questions, or any questions that suggests a "right" and "wrong" answer.

Saturday, November 18, 2017

Happy birthday to Fortran!

A recent article reminded me that the Fortran programming language is now sixty years old! This is a major milestone. And while I don't really write Fortran code anymore, the article was a great reminder of my early use of Fortran.

My first compiled language was Fortran. I was an undergraduate physics student at the University of Wisconsin-River Falls, and as part of the physics program, every student had to learn Fortran programming. Since this was the very early 1990s, we used FORTRAN 77 (the new capitalization of "Fortran" would be established with Fortran 90, a few years later).

We learned FORTRAN 77 so could do numerical analysis, or other programmatic analysis of lab data. For example, while spreadsheets of the era could calculate a linear fit to x-y data, including standard deviations, we could not fit polynomials to nonlinear data. But given a maths textbook, you could write your own program in FORTRAN 77. I wrote many programs like this throughout my undergraduate career.

As a research intern at a national lab between my junior and senior years, my mentors discovered I knew FORTRAN. So I got the assignment to port a FORTRAN IV program to FORTRAN 77 (Fortran 90 had recently been defined, and the lab didn't have the compiler yet). It was my first programming "job" and through experience I realized I wanted a career in IT rather than physics research.

I also taught myself the C programming language, and thereafter switched to C when I needed to write a program. I haven't needed to write Fortran code since then.

The last time I wrote anything in Fortran was a few years ago. At the time, I read an article about a proposed proof to the Collatz conjecture: the so-called "hailstone" sequence. From Slashdot: "A hailstone sequence starts from any positive integer n the next number in the sequence is n/2 if n is even and 3n+1 if n is odd. The conjecture is that this simple sequence always ends in 1. Simple to state but very difficult to prove and it has taken more than 60 years to get close to a solution."

I hadn't heard of the hailstone sequence before, but I thought it was an interesting problem. I could have easily written this program in C or even Bash, but I used the opportunity to return to my roots with Fortran. I created a simple FORTRAN 77 program to iterate the hailstone sequence. To celebrate Fortran's milestone birthday, I'd like to share my program with you:

C     IS 3N+1. ITERATE.

 10   PRINT *, 'Enter starting number (any positive integer):'
      READ *, N

C      PRINT *, 'You entered: ', N

      IF (N.LT.1) THEN
         PRINT *, 'You must enter a positive integer'
         GOTO 10


      PRINT *, N

      ITER = 0

 20   IF (MOD(N,2).EQ.0) THEN
         N = N / 2
         N = (3 * N) + 1

      ITER = ITER + 1

      PRINT *, N
      IF (N.NE.1) GOTO 20

      PRINT *, 'Number of iterations: ', ITER


This program doesn't demonstrate the best programming practices, but it does represent many FORTRAN 77 programs. To illustrate, allow me to walk you through the code:

First, FORTRAN code was originally written on punched cards. The first FORTRAN used columns to understand the program listing. FORTRAN 77 programs used the same column rules:

  • If a C or * in column 1, the line is a comment
  • Program labels (line numbers) are in columns 1–5
  • Program statements begin on column 7, but cannot go beyond column 72
  • Any character in column 6 will continue the line from the preceding line (not used here)

While you could (and should) declare variables to be of a certain type, FORTRAN 77 used a set of implicit rules to assign variable types: all variables starting IN are assumed INTEGER, and variables starting with other letters are declared REAL (floating point).

My program uses only two variables, N and ITER, which are both integer variables.

FORTRAN 77 is a simple language, so you should be able to figure out what the program is doing based on those rules. I'll add a note about the code starting with line label 20. FORTRAN 77 doesn't have a do-while loop concept, so you end up constructing your own using a label, IF, and GOTO.

And that's what happens starting at label 20. The program begins a loop iteration, following the rules of the hailstone sequence: for each positive integer n the next number in the sequence is n/2 if n is even and 3n+1 if n is odd. After updating the ITER iteration count and printing the current value of N, the program continues to loop back to line label 20 (using GOTO) until N reaches 1.

When the loop is complete, the program prints the number of iterations, and exits.

Here's a sample run:

 Enter starting number (any positive integer):
 Number of iterations:           14

Happy birthday, Fortran!

Wednesday, November 15, 2017

QEMU and function keys (follow-up)

Since I posted my suggestion for QEMU a few weeks ago, I've learned a few things about QEMU. Thanks so much to the folks who contacted me via email to help me out.

A brief review of my issue:

I like to run FreeDOS in QEMU, on my Linux laptop. QEMU makes it really easy to boot FreeDOS or to test new installations. During our run up to the FreeDOS 1.2 release, I tested every pre-release version by installing under QEMU.

But one problem pops up occasionally when using QEMU. A lot of old DOS software uses the function keys to do various things. The most common was F1 for help, but it was common for an install program to use F10 to start the install.

And with QEMU, you can use those keys. Except some of them. Some function keys, like F10, are intercepted by the window system or desktop environment. You can get around this in QEMU by using the QEMU console (available in the menu bar or tabs) and typing a sendkey command, like sendkey f10. But that's kind of awkward, especially for new users. Nor is it very fast if you often need to use the function keys.

So I suggested that QEMU add a toolbar with the function keys.

Of course, QEMU's preference is that QEMU should grab the keyboard and intercept all the function keys, blocking the window system shortcut keys like F10. So QEMU wants to do this. And I understand that QEMU used to do this. Sounds like the current issue is a regression in the Wayland implementation—and I run Fedora Linux, so I'm using Wayland.

As Daniel responded via the QEMU tracker for my bug:

Recently though, there has been a regression in this area. With the switch to Wayland instead of Xorg, the standard GTK APIs for doing this keyboard grabbing / accel blocking no longer work correctly. Instead apps need to add custom code to talk to the Wayland compositor IIRC. There's work underway to address this but its a way off.

So that explains it. I'm happy to have this captured by the application. Doing the keyboard interception "live" is a much better solution (better usability) than the toolbar I suggested. Thanks!

Wednesday, November 1, 2017

My suggestion for QEMU

I have been involved in open source software since 1993. And in 1994, I believed so strongly in the ability for people to come together to write code that I created the FreeDOS Project, to replicate the functionality of MS-DOS. And twenty-three years later, I'm still using and developing FreeDOS.

My desktop system is Linux, and I run FreeDOS using QEMU (Quick EMUlator). QEMU is very easy to use, and provides great flexbility to define your virtual machine. I run FreeDOS in QEMU when I want to play an old DOS game, or when I want to test some legacy software, or when I want to write code to update a FreeDOS program.

But one problem pops up occasionally when using QEMU. A lot of old DOS software uses the function keys to do various things. The most extreme example is WordPerfect, which was arguably the most popular commercial word processor of the day. WordPerfect is notorious for using all of the function keys, in every combination, including use of Ctrl and Alt to access all the common features. I think WordPerfect probably used all of the expanded keys too, like Home and End.

Other DOS programs use the function keys in different ways. The most common was F1 for help, but it was common for an install program to use F10 to start the install.

And with QEMU, you can use those keys. Except some of them. And strictly speaking, that's not QEMU's fault. Some function keys, like F10, are intercepted by the window system or desktop environment. You can get around this in QEMU by using the QEMU console (available in the menu bar or tabs) and typing a sendkey command, like sendkey f10. But that's kind of awkward, especially for new users. Nor is it very fast if you often need to use the function keys.

So as a frequent user of QEMU, I'd like to suggest a modification to the user interface: a toolbar with the function keys. Here's a simple mock-up to show what I mean:

A possible improvement would be to add "modifier" buttons for Ctrl, Shift, and Alt to make it easier for users to enter combinations like Ctrl-F1 or Shift-F5 or Alt-F7.

I've already submitted this idea as a feature request in the QEMU tracker, and it's been added to a Wishlist. If you are a QEMU developer, or want to make a contribution to QEMU, I encourage you to work on this toolbar.

Monday, September 18, 2017

Reflection on trip to Kiel

On Sunday, I flew home from my trip to Kiel, Germany. I was there for the Kieler Open Source und LinuxTage, September 15 and 16. It was a great conference! I wanted to share a few details while they are still fresh in my mind:

I gave a plenary keynote presentation about FreeDOS! I'll admit I was a little concerned that people wouldn't find "DOS" an interesting topic in 2017, but everyone was really engaged. I got a lot of questions—so many that we had to wrap up before I could answer all the questions.

FreeDOS has been around for a long time. We started FreeDOS in 1994, when I was still an undergraduate physics student. I loved DOS at the time, and I was upset that Microsoft planned to eliminate DOS when they released the next version of Windows. If you remember, the then-current version was Windows 3.1, and it wasn't great. And Windows's history up to this point wasn't promising: Windows 1 looked pretty much like Windows 2, and Windows 2 looked like Windows 3. I decided that if Windows 4 would look anything like Windows 3.1, I wanted nothing to do with it. I preferred DOS to clicking around the clumsy Windows interface. So I decided to create my own version of DOS, compatible with MS-DOS so I could continue to run all my DOS programs.

We recently published a free ebook about the history of FreeDOS. You can find it on our website, at 23 Years of FreeDOS.

My second talk that afternoon was about usability testing in open source software. The crowd was smaller, but they seemed very engaged during the presentation, so that's good.

I talked about how I got started in usability testing in open source software, and focused most of my presentation on the usability testing we've done as part of the Outreachy internships. I highlighted the GNOME usability testing from my interns throughout my participation in Outreachy: Sanskriti, Gina, Renata, Ciarrai, and Diana.

Interesting note: Ciarrai's paper prototype test on the then-proposed Settings redesign will be published this week on, so watch for that.

The conference recorded both presentations, and they'll be uploadeded to YouTube in the next few days. I'll link to them when they are up.
image: Kieler Open Source und LinuxTage

Sunday, September 17, 2017

Documentation needs usability, too

If you're like most developers, writing documentation is hard. Moreso if you are writing for end-users. How do you approach writing your documentation?

Remember that documentation needs good usability, too. If documentation is too difficult to read—if it's filled with grammatical mistakes, or the vocabulary is just too dense, or even if it's just too long—then few people will bother to read it. Your documentation needs to reach your audience where they are.

Finding the right tone and "level" of writing can be difficult. When I was in my Master's program, I referred to three different styles of writing: "High academic," "Medium academic," and "Low academic."
High academic is typical for many peer-reviewed journals. This writing is often very dense and uses large words that demonstrate the author's command of the field. High academic writing can seem very imposing.

Medium academic is more typical of undergraduate writing. It is less formal than high academic, yet more formal than what you find in the popular press.

Low academic tends to include most professional and trade publications. Low academic authors may sprinkle technical terms here and there, but generally write in a way that's approachable to their audience. Low academic writing uses contractions, although sparingly. Certain other formal writing conventions continue, however. For example, numbers should be written out unless they are measurements; "fifty" instead of "50," and "two-thirds" instead of "2/3." But do use "250 MB" and "1.18 GHz."
In my Master's program, I learned to adjust my writing style according to my instructors' preferences. One professor might have a very formal attitude towards academic writing, so I would use High academic. Another professor might approach the subject more loosely, so I would write in Medium academic. When I translated some of my papers into articles for magazines or trade journals, I wrote in Low academic.

And when I write my own documentation, I usually aim for Low academic. It's a good balance of professional writing that's still easy to read.

To make writing your own documentation easier, you might also consult the Google Developer Documentation Style Guide. Google just released their guide for anyone to use. The guide has guidelines for style and tone, documenting future features, accessible content, and writing for a global audience. The guide also includes details about language, grammar, punctuation, and formatting.