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.

Sunday, December 25, 2016

FreeDOS 1.2

The official announcement is on our website at—but since I announced the FreeDOS 1.2 RC1 and RC2 here, I figured I'd make a brief mention on this blog too.

We're very excited for the new FreeDOS 1.2 distribution! We've added lots of new features that you should find useful and interesting.

Thanks to everyone in the FreeDOS Project for their work towards this new release! There are too many of you to recognize individually, but you have all helped enormously. Thank you!

Friday, December 23, 2016

LibreOffice updating its user interface

I saw a recent blog post from LibreOffice about an upcoming change to their user interface. They call it the MUFFIN, a new "tasty" user interface concept. You can also find more details at the Design blog, discussing how they are evolving past the restrictions of the toolbar. The new MUFFIN will appear in LibreOffice 5.3.

From the announcement, MUFFIN stands for: My User Friendly Flexible INterface. They break it down this way (quoted):
My: LibreOffice users want a “personal” UI, with different options capable of adapting to the user’s personal habits, and not a single UI without options.

User Friendly: of course, any UI should be as user friendly as possible, but LibreOffice users have clearly asked for a “modular” UI, where they can set their own level of user friendliness, and not a single UI without options.

Flexible: the increasing number of LibreOffice users deploying the software on different hardware platforms (for instance, a desktop and a laptop), each one with different characteristics and screen size and resolution, have asked for a UI that can be tweaked to leverage the screen real estate, and not a single UI without options.

INterface: The MUFFIN concept is the combination of different UI elements, which are going to be available starting from LibreOffice 5.3 either as a standard or experimental feature.
I think this is an interesting and welcome direction for LibreOffice. I don't think the current user interface is bad, but I think the proposed changes are a positive step forward. The new MUFFIN interface is flexible and supports users they way they want to use LibreOffice. I think it will appeal to current and new users, and "lower the bar" for users to come to LibreOffice from Microsoft Office.

To give an example, let me examine two options of the MUFFIN interface: Standard and Notebook.

If you're a current user of LibreOffice and are happy with things they way they are, I think the Standard toolbar is for you. It looks pretty much like the menu interface you use today.

Notice the placement and arrangement of menus is very recognizable. I imagine people who have used LibreOffice for years and don't want to change will prefer to stick to the Standard interface.

Then there's the Notebook toolbar. 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 Ribbon.

Here's a mock-up of the Notebook toolbar, from the Design blog, showing the Notebook toolbar under different circumstances:

I like how most of the Notebook toolbar remains the same (File, Clipboard, and Formatting) and options at the end change based on the context of the document (Tools, Table, Image, and Chart). And note how when manipulating an image, the formatting options are grayed out.

Overall, I'm very pleased and think the new design looks great!
images: Document Foundation (1) (2)

Thursday, December 22, 2016

2016 year in review, part 2

I'm doing a year in review, sharing some of my favorite articles on Usability and Open Source Software. Last week, I posted the first five items from my "top ten" list. Here is the rest of the list:

6. A brief history of visual interfaces
In the beginning was the command line. Evolving from teletype terminals, the command line provided the most fundamental interactive interface to the computer. The operator typed in a command, and the computer did the action requested. In the mid to late 1980s, computer systems began to sport graphical user interfaces. The "desktop" concept was still nascent, but generally used separate windows for separate processes. In this article, I provide a brief history of graphical user interfaces and their evolution.
7. Making your first contribution to open source software
A reader recently emailed me to ask how to get involved in open source software if you haven't done that before. Great question! I believe that open source software needs to be personal to you if you're going to do it at all. But how to get started? Start by looking at the project website for the program you like. They may have a bug list or a bug tracker or some other bug database of "known bugs" or "known feature requests" that you could work on. Here are a few projects I would recommend to you.
8. Examining User eXperience
In most cases, usability and UX are strongly aligned. And that makes sense. If you can use the software to get your work done, you probably have a good opinion of the software (good usability, positive UX). And if you can't use the software to do real work, then you probably won't have a great opinion of it (bad usability, negative UX). A review of this year's UX test for GNOME, and how we might improve it next time.
9. Possibilities
This year, I was invited to attend a speech by Vice President Joe Biden. Biden is an incredible speaker. While his address focused primarily on transportation benefits from a federal stimulus package, Biden spoke on several other topics too. I felt motivated by one particular point he made about America: Possibilities. This point connected with me. Afterwards, I reflected on Biden's story and realized that is one reason why I am so invested in open source software. It's about possibilities.
10. FreeDOS 1.2 Release Candidate 1 (and 2)
You may know that I am involved in many open source software projects. Aside from my usability work with GNOME, I am probably best known as the founder and project coordinator of the FreeDOS Project. This year, we worked to create a new version of the FreeDOS distribution. I don't usually write about FreeDOS on my Usability blog, but since this was a major update for FreeDOS, I shared a few news items here. We released FreeDOS 1.2 Release Candidate 1 on October 31, and FreeDOS 1.2 Release Candidate 2 on November 24. Look for the final version of FreeDOS 1.2 in a few days, on December 25!

Thursday, December 15, 2016

2016 year in review, part 1

2016 has been a great year in open source software, and I wanted to take a moment to reflect on some of my favorite articles from this year. In no particular order:

1. Teaching usability of open source software
In Fall semester, I taught an online class on the usability of open source software (CSCI 4609 Processes, Programming, and Languages: Usability of Open Source Software). This was not the first time I helped others learn about usability testing in open source software, having mentored GNOME usability testing for both Outreachy and the Outreach Program for Women, but this was the first time I taught a for-credit class. In this article, I shared a reflection of my first semester teaching this class. I also received feedback from teaching the class, which I'll use to make the class even better next time! I teach again in Spring semester, starting in January. And I shared a related article in preparation for next semester, looking ahead to teaching the class again.

2. Cultural context in open source software
Have you ever worked on an open source software project—and out of nowhere, a flame war starts up on the mailing list? You review the emails, and think to yourself "Someone over-reacted here." The problem may not be an over-reaction per se, but rather a cultural conflict. I don't mean to reduce entire cultures to a simple scale, but understanding the general communication preferences of different cultures can help you in any open source project that involves worldwide contributors. A brief introduction.

3. First contribution to usability testing
In order to apply for an Outreachy internship, we ask that you make an initial contribution. For usability testing, I suggest a small usability test with a few testers, then write a summary about what you learned and what you would do better next time. This small test is a great introduction to usability testing. It exercises the skills you'll grow during the usability testing internship, and demonstrates your interest in the project. This is a guest post from Ciarrai, who applied for (and was accepted to) the usability testing internship this year. Ciarrai's summary was an excellent example of usability testing, and I posted it with their permission.

4. How to create a heat map
The traditional way to present usability test results is to share a summary of the test itself. What worked well? What were the challenges? This written summary works well, and it's important to report your findings accurately, but the summary requires a lot of reading on the part of anyone who reviews the results. And it can be difficult to spot problem areas. When presenting my usability test results, I still provide a summary of the findings. But I also include a "heat map." The heat map is a simple information design tool that presents a summary of the test results in a novel way.
5. Visual brand and user experience
How does the visual brand of a graphical desktop affect the user experience? Some desktop environments try to brand their desktop with visual elements including a distinctive wallpaper. But it's not just images that define a visual identity for a desktop environment. The shapes and arrangements used in the presentation also define a user interface's visual brand. In this way, the shapes influence our perception and create an association with a particular identity. We recognize a particular arrangement and connect that pattern with a brand.
I'll share the remainder of the list next week.

Wednesday, December 14, 2016

Typing emoji is weird

I was thrilled to read in a recent article on Fedora Magazine that Fedora 25 now includes a feature to type emoji. While I don't often use emoji, I do rely on them in certain situations, usually when texting with friends. It would be nice to use emoji in some of my desktop communications, but I was disappointed after reading the description of how to do it. A summary of the process, from the article:
Fedora 25 Workstation ships with a new feature that, when enabled, allows you to quickly search, select and input emoji using your keyboard.

The new emoji input method ships by default in Fedora 25 Workstation, but to use it you will need to enable it using the Region and Language settings dialog.

Next, enable an advanced input method (which is powered behind the scenes by iBus). The advanced input methods are identifiable in the list by the cogs icon on the right of the list. In this example below, we have added English—US (Typing Booster)

Now the Emoji input method is enabled, search for emoji by pressing the keyboard shortcut Ctrl+Shift+e presenting an @ symbol in the currently focused text input. Begin typing for the emoji you want to use, and pop-over will appear allowing you to browse the matches. Finally, use the keyboard to mouse to make your selection, and the glyph will be placed as input.
If you didn't follow that, here's a recap: add a plug-in to activate emoji, then do this whenever you want to type an emoji:

  1. hit a control-key sequence
  2. look for the @ character to appear
  3. type some text that describes the emoji
  4. if the emoji you want pops up, click on it

Maybe that seems straightforward to you. To me, that seems like a very opaque way to insert an emoji. What emoji can I type? This method is probably okay if I know what emoji are there, such as "heart" or "tree," like in the example. This doesn't appear to be good usability. But if you don't know the available emoji, you may have a hard time. Emojipedia says there are as many as of 1,851 emoji characters supported on current platforms, up to and including Unicode 9.0. Good luck in finding the one you want through the @ method.

I don't know the technical details of what's happening behind the scenes, but I wonder why we couldn't provide a feature to add emoji that's easier to use? Here's one example:

  1. right-click wherever you are typing text
  2. select "Insert emoji" from the pop-up menu
  3. get a dialog box with different emoji on it
  4. click on the emoji you want

I would organize the emoji pop-up menu by type. On my Android phone, I get something similar: all the "face" emoji on one page, all the "nature" emoji on another, etc.

Basically, I think it would be easier to add an item in a right-click menu to insert an emoji. I'm sure there are many challenges here, like maybe not all applications that let you type text support a right-click menu. More likely, it may be difficult or impossible to insert a new item in a program's right-click menu.

But my view is there should be an easier way to insert an emoji.
image: Fedora Magazine, used for illustration

Friday, December 9, 2016

Examining User eXperience

When I talk about usability and User eXperience (UX) I often pause to explain the difference between the two concepts.

Usability is really about how easily people can use the software. Some researchers attach definitions to it, like Learnability and Rememberability, but in the end usability is all about real people trying to do real tasks in a reasonable amount of time. If people can easily use the software to do the things they need to do, then the software probably has good usability. If people can't do real tasks, or they can't do so in a reasonable amount of time, then the software probably has bad usability.

User eXperience (UX) is more about the emotional attachment that people have when using the software. You can also consider the emotional response people have to using the software. Does the software make them feel happy and that they want to use the software again next time? Then the software probably has a positive UX. If the software makes users feel unhappy and not want to use the software again, then the software probably has a negative UX.

In most cases, usability and UX are strongly aligned. And that makes sense. If you can use the software to get your work done, you probably have a good opinion of the software (good usability, positive UX). And if you can't use the software to do real work, then you probably won't have a great opinion of it (bad usability, negative UX).

But it doesn't always need to be that way. You can have it the other way around. It just doesn't happen that often. For example, there's an open source software game that I like to play sometimes (I won't name it here). It's a fun game, the graphics are well done, the sounds are adorable. When I'm done playing the game, I think I've had a fun time. And days or weeks later, when I remember the game, I look forward to playing it again. But the game is really hard to play. I don't know the controls. The game doesn't show you what to do to move around or to fire the weapons. And for a turn-based game with a time limit, it's important that you know how to move and shoot. Every time I play this game, I end up banging on keys to figure out what key does what action. It's not intuitive to me. Essentially, I have to re-learn how to play the game every time I play it.

That game has bad usability, but a positive UX. I don't know how to play it, I have trouble figuring out how to play it, but (once I figure it out) I have a fun time playing it and I look forward to playing it again. That's bad usability and a positive UX.

And that means we can't rely on good usability to have a positive UX. We need to examine both.

When I mentored Diana, Renata and Ciarrai this summer in GNOME and Outreachy, Diana performed a UX test on GNOME. This was the first time we'd attempted a UX test on GNOME, and I think we all recognize that it didn't go as well as we'd hoped. But I think we have a good foundation to make the next UX test even better.

We did some research into UX testing, and one method that looked interesting was asking test participants to identify their emotional response with an emoji. Diana looked around and found several examples of emojis, and we decided to move forward with this scale:

The emoji range from "angry" and "sad" on the left to "meh" and "?" in the middle, to "happy" and "love" on the right. It seemed a good scale to ask respondents to indicate their emotion.

For the test, we identified three broad scenario tasks that testers would respond to. Each tester logged into a GNOME workstation with a fresh account, so they would get the "new user" experience. From there, each tester was asked to complete the scenario tasks. We intentionally left the scenario tasks as somewhat vague, so testers wouldn't feel "boxed in" with the test. We only wanted testers to exercise GNOME. The scenario tasks represented what new users would likely do when they used GNOME for the first time, and asked testers to access their email (we wiped the machine afterwards) and to pretend the files on a USB fob drive contained their files from an old machine and to copy these files to the new computer wherever they saw fit.

The scenario tasks took about thirty minutes to complete. Afterward, Diana interviewed the testers, including asking them to respond with the emoji chart. Specifically, "Thinking back to the first ten minutes or so, what emoji represents what you thought of GNOME" and "Thinking about the last ten minutes or so, what emoji represents what you thought of GNOME."

From those questions, we hoped to identify what new users thought of GNOME when they first started using it, and after they'd used it for a little while.

However, when we looked at the results, I saw two problems:

We didn't use enough testers. Diana was only able to find a few testers, and this clearly wasn't enough to find consensus. With iterative usability testing, you usually only need about five testers to get "good enough" results to make improvements. But that assumes usability testing, not UX testing. We need more than five UX testers to understand what users are thinking.

We used too many emoji. Ten emoji turns out to be a lot. If you go through the list of emoji, you may ask what's the difference between #3, #4, and#5. All seem to express "meh." And is there significant distinction between #8 and #9? Both are "happy." There may be similar overlap on other emoji in this list. Having too many choices makes it that much more difficult to read the emotions of users.

I spoke at the Government IT Symposium this week, and I gave three presentations. One of them was "Usability Testing in Open Source Software" and was about our usability tests this summer with GNOME and Outreachy. Attendees had great comments about Renata's traditional usability test and Ciarrai's paper prototype test. People also liked the heat map method to examine usability test results. When I talked about the UX test, attendees thought the emojis were a good start, but also suggested the method could be improved. I asked for help to make this better next time.

These are a few things we might do differently in the next UX test:

Use the emojis, but use fewer of them. Others agreed that there are too many emojis for testers to choose from. Also, that many options without significant variation means testers may ascribe a feeling to an emoji that you don't share. With fewer emoji, we should have better reproducibility. Some people suggested five emoji (similar to a typical Likert scale) or six emoji (more difficult to give a "no feeling" response).

Also ask testers to name their feeling. When we ask testers to identify the emoji that represents their emotional response to part of the test, also ask the testers to name that feeling. "I pick X emoji, which means 'Y'." Then you have another data point to use in describing the UX.

Use a Likert scale. One researcher suggested that UX would be easier to quantify if we asked testers to respond to a traditional five-point or six-point Likert scale, from "hate" to "love."

Use word association. I had thought about doing this before, so it was good to hear the suggestion from someone else. When asking testers to talk about how they felt during part of the test, ask the testers to pick a few words from a word list. Say, five words. The word list could be created by selecting a range of emotions ("love" and "meh" and "hate," for example) and using a thesaurus to generate other alternative words for the same emotion. Sort the list alphabetically so similar words aren't grouped next to each other. We'd need to be careful in creating the word list like this, but it could provide an interesting way to identify emotion. How many "love" words did testers select versus "hate" words, etc? One way to display the results is a "word cloud" on the base words ("love" and "meh" and "hate," in this example).

Mix UX testing with usability testing. In this UX test, we decided to let users experiment with GNOME before we asked them what they thought about GNOME. We provided the testers with a few broad scenario tasks that represented typical "first time user" tasks. After testers had experienced GNOME, we asked them what they thought about it. Others suggest it would be better and more interesting to pause after each scenario task to ask testers what they think. Do the emoji exercise or other UX measurement, then move on to the next task. This would provide a better indicator about how their emotional response changes as they use GNOME. And it could provide some correlation between a difficult scenario task and a sudden negative turn in UX.

Add more UX questions. When I asked for help in UX testing, several people offered other questions they use to examine UX. Some also shared questionnaires they use for usability testing. And there's some crossover here. A few questions that we might consider adding include "How would you describe the overall look and feel?" and "What is your first impression of X?" and "Talk about what you're seeing on this screen and describe what you're thinking." These questions can be useful in usability testing, but also provide some insight to UX.

Thursday, November 24, 2016

FreeDOS 1.2 Release Candidate 2

We started FreeDOS in 1994 to create a free and open source version of DOS that anyone could use. We've been slow to make new releases, but DOS isn't exactly a moving target anymore. New versions of FreeDOS are mostly about updating the software and making FreeDOS more modern. We made our first Alpha release in 1994, and our first Beta in 1998. In 2006, we finally released FreeDOS 1.0, and updated to FreeDOS 1.1 in 2012. And all these years later, it's exciting to see so many people using FreeDOS in 2016.

If you follow my work on the FreeDOS Project, you should know that we are working towards a new release of FreeDOS. You should see the official FreeDOS 1.2 release on December 25, 2016.

We are almost ready for the new FreeDOS 1.2 release! Please help us to test this new version. Download the FreeDOS 1.2 RC2 ("Release Candidate 2") and try it out. If you already have an operating system on your computer (such as Linux or Windows) we recommend you install FreeDOS 1.2 RC2 in a PC emulator or "virtual machine." Report any issues to the freedos-devel email list.

You can download FreeDOS 1.2 RC2 from our Download page or at ibiblio.

Here's what you'll find:

  • Release notes
  • Changes from FreeDOS 1.1
  • FD12CD.iso (full installer CDROM) —If you have problems with this image, try FD12LGCY.iso
  • (boot floppy for CDROM)
  • (full installer USB image)
  • (minimal installer USB image)

Thanks to everyone in the FreeDOS Project for their work towards this new release! There are too many of you to recognize individually, but you have all helped enormously. Thank you!

Monday, October 31, 2016

FreeDOS 1.2 Release Candidate 1

You may know that I am involved in many open source software projects. Aside from my usability work with GNOME, I am probably best known as the founder and project coordinator of the FreeDOS Project.

I started the FreeDOS Project back in 1994, when MS-DOS was still the platform of choice for many people. You can read the history of FreeDOS on our website, but the short version is this: I announced the FreeDOS Project in June 1994 as a way to replace the functionality of MS-DOS. The idea of a free DOS quickly caught on, and soon developers across the world came together to contribute to and improve FreeDOS.

It's 2016, and FreeDOS is still going strong. In fact, we are planning a new release this year: FreeDOS 1.2 should be available on December 25, 2016.

You can get FreeDOS 1.2 RC1 at our Download page

You can help us make FreeDOS 1.2 a reality! We just released the FreeDOS 1.2 RC1 ("Release Candidate 1") for folks to try out. Please download and test this latest version of FreeDOS! Report any bugs or problems to the freedos-devel email list.

Saturday, October 29, 2016

Solitaire in a Bash script

I like to write Bash scripts. It stems from my time as a Unix and Linux systems administrator, years ago. I used to automated everything. So I got very good at writing shell scripts. Even today when managing a personal server, I write Bash scripts to automate various jobs so I don't have to keep logging into the server all the time. For example, I have a job that parses an RSS news feed with Bash.

I admit that my Bash scripts aren't always for automation. Some of my scripts are just for fun. Like the Bash script to fill out my March Madness basketball brackets. It can be an interesting diversion to write a Bash script to do something innovative.

And lately, I've started writing another such Bash script. Let me tell you about it.

We all know the classic Klondike Solitaire card game. There have been countless computer implementations of Solitaire on every platform. We even had a simple Solitaire game on our old Apple IIe computer in the 1980s. If you run Linux, you may be familiar with AisleRiot, which supports multiple card solitaire games, including the classic Klondike Solitaire. More recently, Google now provides a browser-based version of Klondike Solitaire; just search for the term "solitaire" and you'll get an option to "Click to play" the web version.

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. You might think that's the toughest part, but I don't think so; I'll explain at the end.

So, how do you write a solitaire card game in a shell script?

I found it was easiest to leverage the strength of shell scripts: files. I started with all 52 cards in a single "deck" file, shuffled it, then "drew" cards from the deck into piles on the tableau.

Let's start with the basics. Creating 52 cards, comprised of thirteen cards of four different suits, is straightforward:

for s in c d h s ; do
  for n in $(seq 1 13) ; do
    echo "$s$n"

You can direct the output to a file, and you have a file containing an ordered representation of all 52 cards. On a Linux system, you can use GNU shuf(1) to randomize ("shuffle") an input file, which can also be a pipe. So to define a shuffled deck of 52 cards, you do this:


for s in c d h s ; do
  for n in $(seq 1 13) ; do
    echo "$s$n"
done | shuf > $deck

Drawing cards from the deck requires a little more work, but not much more. I wrote a simple function popn() that takes ("pops") the first n lines of a file and returns those lines, and shortens the file at the same time. Usually, this will be one at a time, but we'll need the flexibility later.

On top of that function, I wrote another simple function drawcard() that draws a single card from the deck and assigns it to the end of a "drawn cards" pile. This function also needs a little extra logic to deal with an empty deck; if the deck is empty, we return the drawn cards to the deck and start over. This is why it's important to pop from the start of the deck and append drawn cards to the end of the "drawn cards" pile; you can easily reset the deck using the drawn cards:

function popn() {
  # pop the first n($2) items from a file($1) and print it
  head -$2 $1
  cp $1 /tmp/tempfile
  awk "NR>$2 {print}" /tmp/tempfile > $1

function drawcard() {
  if [ $(cat $deck | wc -l) -eq 0 ] ; then
    cp $draw $deck

  popn $deck 1 >> $draw

In Klondike Solitaire, the play area is a tableau of seven piles of cards, where the first n-1 cards are piled "face down" and the last card is placed "face up." So for the first column, there are no "face down" cards, and only one "face up" card. On the seventh column, you start with six "face down" cards, and only one "face up" card. The player must move cards on these seven piles, eventually transferring the cards to four separate "foundation" piles, where each pile is dedicated to a separate suit: clubs, diamonds, hearts, and spades.

Creating the play area requires the use of Bash arrays. I rarely use arrays in Bash, but they are a very useful feature. Bash supports both indexed arrays (0, 1, 2, …) and associative arrays (where the index is a string value). You define a variable as an indexed array using the declare -a directive, and as an associative array with the declare -A directive.

With this, it's simple enough to define the tableau card piles as separate files, then use the popn() function to deal cards from the deck into these files.

declare -a tabdraw
for n in $(seq 1 7) ; do tabdraw[$n]="/tmp/sol/tab.draw.$n" ; done

declare -a pile
for n in $(seq 1 7) ; do tab[$n]="/tmp/sol/tab.$n" ; done

declare -A found
for s in c d h s ; do found[$s]="/tmp/sol/found.$s" ; done

# deal cards from deck into tableau {curly brackets needed on array refs}

for n in $(seq 1 7) ; do popn $deck 1 >> ${tab[$n]} ; done

for n in $(seq 1 7) ; do popn $deck $((n - 1)) >> ${tabdraw[$n]} ; done

And that's the guts of a Solitaire game in Bash! When assembled, my Bash script looked like this:


# create work directory

[ ! -d $tmpdir ] && mkdir $tmpdir

# create variables


declare -a tabdraw
for n in $(seq 1 7) ; do tabdraw[$n]="$tmpdir/tab.draw.$n" ; done

declare -a pile
for n in $(seq 1 7) ; do tab[$n]="$tmpdir/tab.$n" ; done

declare -A found
for s in c d h s ; do found[$s]="$tmpdir/found.$s" ; done

# create functions

function popn() {
  # pop the first n($2) items from a file($1) and print it
  head -$2 $1
  cp $1 $tmpf
  awk "NR>$2 {print}" $tmpf > $1

function drawcard() {
  if [ $(cat $deck | wc -l) -eq 0 ] ; then
    cp $draw $deck

  popn $deck 1 >> $draw

function showcards() {
  # show the cards again - repaint the screen


  for n in $(seq 1 7) ; do cat ${tabdraw[$n]} | wc -l > $tmpdir/wc.$n ; done

  paste $tmpdir/wc.[1-7]
  paste ${tab[*]}

  echo '___  ___  ___  ___'

  paste ${found[*]}

  echo '___'

  cat $deck | wc -l
  tail -1 $draw

# build and shuffle initial deck

for s in c d h s ; do
  echo "${s}0" > ${found[$s]}

  for n in $(seq 1 13) ; do
    echo "$s$n"
done | shuf > $deck

# deal cards from deck into tableau {curly brackets needed on array refs}

for n in $(seq 1 7) ; do popn $deck 1 >> ${tab[$n]} ; done

for n in $(seq 1 7) ; do popn $deck $((n - 1)) >> ${tabdraw[$n]} ; done

# loop until quit ('q')

while [ "$input" != "q" ] ; do
  case "$input" in
    # draw next card
    # parse into card1,card2
    # is this a valid request?
    # is this a valid move?


  echo -n '?> '
  read input

# cleanup

rm -rf $tmpdir

I have left unfinished the logic to move cards around on the tableau. This might seem like the most difficult part, but not really. Since every pile on the tableau is a file, it's easy enough to seek a requested card in each of the "face up" piles, then extract all lines (cards) from that "face up" pile and append them onto another "face up" pile. You'd need a little extra logic in there to move Kings to an empty space on the tableau, but that's not very difficult.

I envisioned splitting the logic into three parts:

1. Verifying that this is a valid request
For example, the user is not allowed to move a black card onto a black card. Also, the user can only move cards in descending order on the tableau, and ascending order on the foundation. That's easy logic.
2. Confirming that the cards are there to move
This should be a fairly straightforward process using fgrep(1) to locate the requested cards on the tableau or in the foundation.
3. Moving the cards
I believe this should be easy, if you remember that cards are only entries in files. You can easily write a function that outputs all lines starting with card A, and appends them to the end of another file. At the same time, the function can truncate the first file starting at card A.

When you start the script, you should see output similar to this:

0       1       2       3       4       5       6
s12     c11     s2      h7      s11     h11     d3
___     ___     ___     ___
c0      d0      h0      s0

The output is intentionally functional, and uses paste(1) to merge the output from several tableau files. What you're seeing:
  • The first line shows the number of cards remaining in each of the tableau "face down" piles.
  • The second line shows the "face up" cards for each pile on the tableau. This sample output indicates: 12 (Queen) of Spades, 11 (Jack) of Clubs, 2 of Spades, 7 of Hearts, 11 (Jack) of Spades, 11 (Jack) of Hearts, and 3 of Diamonds.
  • The third line shows the empty foundation piles. I initialized these as the "zero" cards so the logic to transfer cards to the foundation could remain simple; you only move cards of the same suit in ascending order.
  • The fourth line shows the number of cards remaining to be drawn on the deck.
  • The fifth line shows the "face up" card from the deck. In this case, it is the 13 (King) of Clubs.
  • The last line shows a prompt (?>) for the user to enter a command.

This Bash script was a lot of fun to write, but I don't have time to finish it. The script took an afternoon to write, and an hour to tweak. Even so, I think this is a solid start to play Solitaire in a Bash script.

Feel free to finish this script. Please assume Creative Commons Attribution. So if you use it somewhere else, such as to write an article and publish it, you should credit me as the original author.

Sunday, October 2, 2016

Looking ahead: Usability of open source software

This Spring semester, I look forward to teaching CSCI 4609 Processes, Programming, and Languages: Usability of Open Source Software. This is the second time I will teach the class at the University of Minnesota Morris, although it's more like the fifth time because I structured the course outline to be very similar to the Outreachy internships I've mentored now for three cycles.

Interested in a preview of the course? Here's a quick breakdown of the syllabus:
CSCI 4609: Usability of Open Source Software

Introduction to usability studies and how users interact with systems using open source software as an example. Students learn usability methods, then explore and contribute to open source software by performing usability tests, presenting their analysis of these tests, and making suggestions or changes that may improve the usability.

Course objectives:
  • To understand what is usability and apply basic principles for how test usability
  • Design and develop personas, scenarios, and other artifacts for usability testing
  • Create an execute a usability test against an actual product
  • To identify and reflect on the value and presentation of usability test results

Each student will work with the professor and other students to choose an individual project to complete during the second half of the term.

  • Class engagement (discussions, presentations, feedback)
  • Projects (small group project, and larger individual project)
  • Final paper to document your individual project

Each discussion will be worth 5 points. This is graded on a scale: no points for no discussion posted, and 1 to 5 points based on the quality of your discussion. For example: a well thought-out discussion will be given 5 points; a sketched out discussion post will earn 1 point.

Course outline:
  1. Introduction
  2. What is usability?
  3. How do we test usability?
  4. Personas
  5. Scenarios
  6. Scenario tasks
  7. User interfaces
  8. Mini project (two weeks)
  9. Final project (four weeks)
  10. Final paper
Based on what I learned from teaching the class last time, I'll be sure to arrange the weeks to leave more time for the final project, and to spread discussion throughout the week. For example, in the first half of the course, there's a lot of research and practice: learn about a topic and post a summary, then apply what you have learned towards a specific assignment. This time, I'll have the first discussion assignment due around Thursday each week, and the practice assignment due on Sunday, assuming each week starts on a Monday and ends on Sunday night.

I will also change the points. Last time, I had a 60/40 split for discussion points and final paper. I totaled your discussion, and that was 60% of your grade; your final paper was the other 40%. This year, I plan to make the points cumulative. If you assume 20 discussions at 5 points each, that's 100 points for discussion. The paper is an additional 50 points. That makes it clear you cannot skip the discussion and hope for a strong paper; neither can you punt the paper and rely on your discussion points. You need to participate every week and you need to make an effort on the final paper to get a good grade in the class.
image: University of Minnesota Morris

Sunday, September 25, 2016

Great first year at LAS GNOME!

This was the first year of the Libre Application Summit, hosted by GNOME (aka "LAS GNOME"). Congratulations to the LAS GNOME team for a successful launch of this new conference! I hope to see more of them.

In case you missed LAS GNOME, the conference was in Portland, Oregon. I thoroughly enjoyed this very walkable city. Portland is a great place for a conference venue. When I booked my hotel, I found lots of hotel options within easy walking distance to the LAS GNOME location. I walked every day, but you could also take any of the many light rail or bus or trolley options running throughout the city.

I encourage you to review this year's conference schedule to learn about the different presentations. I'll share only a few highlights of my own. I also live-tweeted through many of the presentations, and I'll share some of those tweets here:

Alexander Larsson gave a great presentation ("Taking back the apps from the distributions") about Flatpak. I'd followed Flatpak before, but until Alexander's presentation, I never really grokked what Flatpak can do for us. With Flatpak, anyone can provide an application or app anywhere, on any distribution.

Today, you may be comfortable installing whatever application you need through your distribution. But what if your distribution doesn't provide the application you are looking for? And what if you want to run an application that a distribution isn't likely to want to provide (such as a commercial third-party office application or game)? In these cases, you either hope the person providing the application can provide a package for your distribution, or you go without.

With Flatpak, you can bundle an application to run on any Linux distribution, and it should just run. I see this as a huge opportunity for indie games on Linux! Imagine the next version of PuzzleQuest also being available for Linux, or a version of Worms for Linux, or a version of Inside for Linux. With Flatpak, these indie developers could bundle up their apps for Linux—and sell them.

Also, a great thing about going to conferences is the opportunity to finally meet people you've only chatted with online. Ciarrai was one of my interns during the May-August cycle of Outreachy, and we finally got to meet at LAS GNOME! We had been emailed back and forth in the weeks ahead of time, since we knew we'd both be there. But it was great to finally meet them in person!

LAS GNOME had scheduled talks in the morning, and "unconference" topics in the afternoon. With an "unconference," people suggest topics for an impromptu presentation or workshop, and attendees vote on them.

In the afternoon of day 1, I hosted an informal workshop on usability testing, at the same time my friend Asheesh gave an unconference presentation on web app packaging in Sandstorm. I was surprised to see so many developers at my how-to presentation about usability testing. Thanks to all who attended! Scott snapped this selfie of the two of us:

On day 2, Asheesh Laroia gave a presentation ("How to make open source web apps viable") about Sandstorm. Asheesh and I have known each other for a few years now, and I've followed his work with Sandstorm. But it was great to see Asheesh walk us through a demo of Sandstorm to really show off what it can do. In short, Sandstorm provides an open source software platform that helps people collaborate over the web.

And Sandstorm is designed with several layers of security, so it's very locked down. Even if you can "break out" of one web application, you can't get elsewhere on the system. As Asheesh put it during his talk, it's like Google Docs, but more secure:

On day 3, Stephano Cetola shared a wonderful story about how he got involved in open source software and made it his career ("Endless Summer of Code: Getting Involved in OSS"). I loved how Stephano talked about his experimental nature, and how he learned about technology by letting the "magic smoke" out of things.

Because of his eagerness and willingness to learn, Stephano found new opportunities to grow—eventually landing a position where he works for Intel, working on the Yocto project. A great journey that was a joy to experience!

Finally, I gave my presentation on usability testing for GNOME ("GNOME Usability Testing"). I opened by talking about different ways (direct and indirect) that you can test usability of software. From there, I gave an overview of the Outreachy internship, and what Renata, Ciarrai and Diana worked on as part of their internships.

I was thrilled for Ciarrai to share their part of usability testing from this cycle of Outreachy. Ciarrai's project was a paper prototype test of a new version of GNOME Settings. Renata conducted a traditional usability test of other ongoing work in GNOME, and Diana worked on a User eXperience (UX) test of GNOME.

I think my presentation went well, and we had a lot of great questions. Thanks to everyone!

Again, congratulations to the LAS GNOME team for a successful first year!
image: LAS GNOME
photo: Scott

Sunday, September 18, 2016

Headed to LAS GNOME!

By the time this gets posted on the blog, I will be headed to LAS GNOME. I'm really looking forward to being there!

I'm on the schedule to talk about usability testing. Specifically, I'll discuss how you can do usability testing for your own open source software projects. Maybe you think usability testing is hard—it's not! Anyone can do usability testing! It only takes a little prep work and about five testers to get enough useful feedback that you can improve your interface.

As part of my presentation, I'll use our usability tests from this summer's GNOME usability tests as examples. Diana, Renata and Ciarrai did a great job on their usability testing.

These usability testing projects also demonstrate three different methods you can use to examine usability in software:

Ciarrai did a paper prototype test of the new GNOME Settings. A paper prototype is a useful test if you don't have the user interface nailed down yet. The paper prototype test allows you to examine how real people would respond to the interface while it's still mocked up on paper. If you have a demo version of the software, you can do a variation of this called an "animated prototype" that looks a lot like a traditional usability test.

Renata performed a traditional usability test of other areas of ongoing development in GNOME. This is the kind of test most people think of when they hear about usability testing. In a traditional usability test, you ask testers to perform various tasks ("scenario tasks") while you observe what they do and take notes of what they say or how they attempt to complete the tasks. This is a very powerful test that can provide great insights to how users approach your software.

Diana led a user experience (UX) test of users who used GNOME for the first time. User experience is technically different from usability. Where usability is about how easily real people can accomplish real tasks using the software, user experience focuses more on the emotional reaction these people have when using the software. Usability and user experience are often confused with each other, but they are separate concepts.

I hope to see you at the conference!
Interested in my slides from LAS GNOME? You can find them on my personal website at I'll keep them there for at least the next few weeks.
image: LAS GNOME

Saturday, September 10, 2016

Wrap-up from this cycle of Outreachy

Now that all interns have completed their work, I wanted to share a few final thoughts about this cycle of Outreachy. Hopefully, this post will also help us in future usability testing.

This was my third time mentoring for Outreachy, but my first time with more than one intern at a time. As in previous cycles, I worked with GNOME to do usability testing. Allan Day and Jakub Steiner from the GNOME Design Team also pitched in with comments and advice to the interns when they were working on their tests and analysis.

As before, I structured the usability testing internship along similar lines to an online class. In fact, I borrowed from the usability testing internship schedule when I taught CSCI 4609 Processes, Programming, and Languages: Usability of Open Source Software, an online elective computer science program at the University of Minnesota Morris. We first learned about usability testing, then we practiced usability testing. In this way, the internship was broken up into two phases: a research phase and a project phase.


With three interns, we decided from the beginning that we should focus on three different areas for our usability tests. In previous cycles, with only one intern at a time, we conducted traditional usability tests that spanned several common design patterns used in GNOME. In this cycle, we wanted to continue with a traditional usability test, but we wanted to explore other areas of GNOME usability.

Based on the previous experience and interests of Renata, Ciarrai and Diana, we assigned them to do these three usability tests:

  1. Renata: A traditional usability test of ongoing development in GNOME.
  2. Ciarrai: A paper prototype test of the new GNOME Settings.
  3. Diana: A first-time GNOME User eXperience (UX) test.

A paper prototype test uses a slightly different test design from a traditional usability test, but the analysis is the same. In a paper prototype test, as in a traditional usability test, you ask a tester to respond to various scenario tasks. But in a paper prototype test, the tester is acting against a paper mock-up of the design. In this case, Ciarrai used screenshot mock-ups of the updated GNOME Settings.

Renata led a traditional usability test. In her test, we asked Renata to further examine areas that had improved based on the last cycle of GNOME usability testing. This allowed us to measure any usability gains in the design.

Diana performed a different kind of test. Technically, a user experience test is not a usability test; usability and user experience are different concepts. Usability is how easily users can use the software to accomplish real tasks in a reasonable amount of time. But user experience is more about the emotional engagement of the user when using the software. It's possible for a program to have good usability and poor UX, or for a program to have poor usability but good UX, but in most cases you will find a positive correlation between usability and user experience. Most of the time, if a program has good usability, it will likely have positive UX. And if a program has poor usability, it will likely have negative UX.


When planning any usability test, it's important to start with an understanding of who uses the software. Typically, a project should have these documented as personas, fake personalities that reflect real-world users. With personas, a project can discuss design changes in a more concrete way. Rather than a designer or developer planning a change "because it's cool" or "because I like it," they can plan changes that will help the "Sally" persona do her work, or will make the "Stephen" persona more productive, or will allow the "Chris" persona to more easily work with the software.

Once you understand the users, you need to define how the users will use the software. These are the use scenarios. Users might have different needs that carry different expectations. For a word processor program, one user might use the program to write a report at work, while another user might use the program to write a research paper (with footnotes!) for class, while another user might use the program to jot a quick letter to a friend.

From this understanding of use scenarios, you can then create a usability test. In most usability tests, the test is usually comprised of scenario tasks, which you give one at a time to each tester. The scenario task should set up a brief context for the task, then ask the tester to do something specific. The task needs to be general enough that the tester has latitude to complete the task the way they would normally do it, yet specific enough that both the test moderator and test volunteer would know when the task is completed.

Take notes while your testers use the software. This is usually made easier if you ask each tester to speak aloud what they are doing or what they are looking for (if they are looking for a Print button, they should say "I need to print, and I'm looking for a Print button"). Also note any comments they make while working on each task ("This seems difficult" or "I can't seem to find the Print button" or "That was easy").

And that's the process Diana, Renata and Ciarrai followed when they did their tests. Diana's UX test was a little different, because UX is not the same as usability so required a slightly different test design, but still she asked testers to explore GNOME via three broad scenario tasks.

After the test, you collate your notes and analyze your data. For a traditional usability test, I find it is easiest to start with a heat map. I discuss heat maps elsewhere on my blog. From the heat map, it's easy to look for "cool" and "hot" rows, which reflect scenario tasks that were easy for testers or more difficult. This is often my first step to examine themes.

Both Renata and Ciarrai used heat maps in their analysis. Ciarrai's heat map analysis method was a variant on the typical method, due to their test being a paper prototype test. The testers didn't interact with a live version of the software, but a paper mock-up using screenshots of the new design. So Ciarrai's analysis was made more difficult, but they did a great job.

For Diana's test, I asked her to try a different analysis method. After each tester explored GNOME, she asked them to describe their initial reaction (their first few minutes) to GNOME by pointing to an emoji. Diana had prepared a list of ten emojis that ranged from "ewww" to "happy." She also asked testers to describe their experience at the end of the test using the same emoji scale. Diana then followed up with a brief interview designed to explore how testers perceived GNOME.

Notes on the UX test for next time:

I have mentored several traditional usability test before, as part of Outreachy and as an instructor for CSCI 4609, so we had a lot of prior experience going into Renata's traditional usability test and Ciarrai's paper prototype test. That's probably why both went very well. But this was our first time doing a user experience test, and while I think we got some useful results from it, I think we can improve the user experience test the next time we do a UX test.

First, I think we need more testers in the user experience test. In most usability tests, you don't need very many testers to uncover most problems and get actionable results. This assumes that each tester will uncover many of the same problems found by the next tester. Some usability researchers claim you only need to test with five testers. I agree with that, but you need to remember the assumption: each tester uncovers many of the same problems the next tester will find. Nielsen finds a single tester will uncover about 31% of the problems in a single usability test.

But in UX testing, you aren't uncovering usability problems. Instead, you are examining how real people respond to the software. You are looking for something akin to emotional attachment, not ease of use. So five testers is not enough. Diana initially included five testers for her UX test, and later expanded to seven. Even that isn't enough. I think the next time we do a GNOME user experience test, we will want around twenty testers.

We should also closely examine the number of emoji that testers respond to. I worked with Diana to select ten emoji that span a range of emotions. I based this test design on a common contemporary UX test design, including that used in an article in the Washington Post where the newspaper asked readers to respond to political events (specifically, the Republican National Convention) by selecting from a list of emoji. Over a thousand readers responded in that case. With such great numbers, the results quickly narrowed down to show the top one or two emoji responses for each political moment. For example, when responding to "I declare Trump and Pence to be nominees for President and Vice President," the responses tailed off quickly: 553, 334, 90, 79, 70, … That makes it easy to identify the one or two dominant reactions.

The next time we do a user experience test, increasing the testers will help us to consistently identify emotional response via emoji. We might also reduce the number of emoji, so fewer testers have fewer options to choose from. At the same time, we need to be careful not to restrict the responses too much or we risk artificial results.

To offset this, and in addition to emoji, we might also ask the testers to pick three or five adjectives from a list that describe their reaction to the test. We can use synonyms of various emotions, so testers have a wide range of words with which to describe their reactions, yet we can combine results more easily. For example, synonyms of "confused" include baffled, bewildered, befuddled and dazed. If a tester felt confused at the beginning of the UX test, they might pick three adjectives "baffled, bewildered, confused" that would give a score of +3 to "confused." Similarly, synonyms of "happy" include cheerful, contented, delighted and ecstatic.

A few thoughts for future mentors:

Mentoring in Outreachy is a very rewarding experience, but it's also a lot of work.

When mentoring three interns in this cycle in Outreachy, I assumed the effort would be about the same as my online class with ten students. The research phase was certainly straightforward; we were researching the same topics. But once we entered the project phase, and Diana, Renata and Ciarrai each started work on their own projects, I was constantly switching gears as I reviewed each intern's work and provided direction and guidance. I think I did a good job here, but it came with a ton of effort on my end.

As weeks progressed in the project phase, I began to rely more heavily on Jakub and Allan to help me out. I seemed to constantly send them reminders to review that week's work and respond to the interns. I hope I haven't made a nuisance of myself or pushed too hard.

Looking back, mentoring three interns on three different usability tests was more work than my online class with ten students because the three interns were working on completely different projects, while students in my CSCI 4609 class worked on similar projects. In my online class, students had different starting points in their Personas and Use Scenarios, but they worked together on the same program for a "dry run" usability test. For the final project, students could pick any open source program that appealed to them, but in the "dry run" I picked the program for them to examine (based on common interests we explored in the first few weeks of class). This meant most of my energies as professor were pointed in the same direction. But in mentoring three projects for Outreachy, I was always getting pulled in a different direction.

I'm not sure how my experience compares to a project that focuses on coding. At a guess, I think it's not very comparable. Your mileage may vary.

My guess is the effort to mentor several interns in a coding project is probably the same as being the project maintainer for any active open source software project. I've been involved in open source software since 1993, and an active developer since 1994, so I know the effort isn't too great if you are reviewing code patches for a codebase that you are very familiar with. As maintainer of the program, you know where the puzzle pieces go, and you should have a good idea what the side effects may be for a new patch.

If you volunteer as a mentor to a future cycle in Outreachy, make sure to plan your time very carefully. Be aware of time commitments and how your work in Outreachy will intersect with other things you want to do. I over-committed myself, for example. I can't do that again.

A few thoughts for future interns:

One of the steps in your application to Outreachy is the first contribution. For the usability testing internship, I asked applicants to pick a few scenario tasks from previous usability tests, and do a usability test with a few test volunteers, then write a short article about your first contribution. I intentionally asked applicants to test with only a few users, usually less than five, because I wanted them to see what usability testing was like before they committed to the internship. Three isn't enough testers to get actionable results, so I think I will increase this to five testers next time.

I find that this first contribution really does provide an indicator to later performance. Applicants who did well in their initial contribution did well in their internship. We were able to predict performance (to some degree) based on their initial contribution. Diana, Ciarrai and Renata were accepted into the program because their initial contributions represented good work. Other applicants to the program who weren't selected may have done a good job but were not selected due to space, while others didn't seem to take the first contribution very seriously (they thought it was "busywork") or they waited until the last moment to do their initial contribution, leaving no time to evaluate their work before we had to make a decision.

If you plan to apply for a future cycle in Outreachy, don't forget the initial contribution. Take it seriously. Reach out to the project's mentors and discuss the initial contribution and how to approach it. I know I took into consideration each applicant's engagement and relative success in the initial contribution, and that mattered when selecting interns for the program.
image: Outreachy

Friday, September 9, 2016

Keeping DOS alive with FreeDOS

I wanted to share a recent interview with about the FreeDOS Project, an open source software project that's been close to me since 1994. Jason Baker from Red Hat interviewed me about FreeDOS, why we started it, and what to expect in FreeDOS 1.2 (out later this year).

Here's a brief excerpt from "Keeping DOS alive and kicking with open source":

DOS: the Disk Operating System. For many of us whose computer coming-of-age story spanned across the 80s and 90s, we remember it, fondly or not, as the gateway into our computers. But somewhere along the way, DOS gave way to graphical environments, and some of us opted to move to open source alternatives.

But in the free software world, DOS is still alive and well in the form of FreeDOS, an open source operating system maintained by Jim Hall and a team of dedicated developers who are keeping the DOS legacy alive well into the twenty-first century. And more than simply an existing code base, FreeDOS is still being actively developed and is approaching a new release in the near future ("When it's ready," according to Jim). FreeDOS has proved to be an important tool to numerous legacy applications powering critical systems which were never migrated to a more modern operating system.

I caught up with Jim to learn more about the FreeDOS project and where it's headed in this interview.

Read the article for the full interview»
image: Official FreeDOS fish (cc-by)
by Bas Snabilie, adapted by Mateusz Viste
from FreeDOS Images

Presenting at the Government IT Symposium

I'm pleased to announce that I will be presenting "Usability testing in open source software" at the 35th Annual Government IT Symposium, in December 2016!

As you might guess from the title, this presentation is about how to do usability testing. I'll use my previous experience in usability testing in open source software as an example, and walk through three different usability tests from this year's Outreachy internship with GNOME.

Are you planning to attend the Symposium? If so, here are the presentation details:
In this session, you’ll learn about different ways to perform usability testing. Jim has mentored usability testing for the GNOME Foundation, including three usability tests during Summer 2016. This presentation will discuss different methods you can use for usability testing, and general lessons that you can use now. Jim will also present results from the usability tests of GNOME from Summer 2016.
My presentation is scheduled for Thursday, December 8th, 2016 1:15 p.m. to 2:15 p.m.

Also, I'll be doing a separate presentation about "Leadership lessons from unusual places." Check out my other blog Coaching Buttons to learn more about that!
image: MN Government IT Symposium

Tuesday, September 6, 2016

Wrapping up user experience testing

This is a follow-up to my other item about wrapping up Outreachy. Diana posted part two of her analysis from first-time GNOME user experience testing.

In this test, Diana asked testers to simulate an "unboxing" of a new system. The tester logged in to GNOME using a fresh "test" account so they get the first-time user experience. After allowing each tester to explore GNOME via three broad scenario tasks, Diana asked them to rate their reaction to GNOME using emoji, and followed up with several interview questions.

What went well:

  • File management (Nautilus)
  • Browsing the web (GNOME Web)

What was difficult:

  • GNOME initial setup
  • Email setup (Evolution)

Diana's user experience test used only a few testers (initially five, expanded to seven) so it's hard to evaluate trends from this research. However, Diana makes these general recommendations based on her observations:

  • Add more colors
  • Reduce number of steps in initial setup
  • Simplify password experience
  • Relocate the input language settings

Diana goes into more depth in her discussion. Read Diana's analysis for more»
image: Outreachy

Friday, September 2, 2016

Making your first contribution to open source software

A reader recently emailed me to ask how to get involved in open source software if you haven't done that before. Great question!

I believe that open source software needs to be personal to you if you're going to do it at all. Open source software is a hobby—but it's more than that. I find myself thinking about the open source software projects I maintain, contribute to, and use almost daily. So if you're going to contribute to open source software, make it something you care about.

But how to get started? It can be somewhat intimidating to look at the software that's already been created and think "How can I contribute to that?" One easy way to contribute is by fixing bugs. Every program maintainer is always interested to receive bug fixes! So play with a program that you like. If you find a bug, dig into the source code and fix it. Or if you think the program would be better if it did things a little differently, add that new feature! Email your patches to the program maintainer and see if they accept it. Pretty much all the open source software developers I know are happy to receive patches that fix bugs or add new functionality.

Start by looking at the project website for the program you like. They may have a bug list or a bug tracker or some other bug database of "known bugs" or "known feature requests" that you could work on.

But here are a few projects I would recommend to you. These are of special interest to me:

​The FreeDOS Project
I'm also the founder and project coordinator for FreeDOS, a free implementation of the DOS operating system. We just discussed/reviewed a bunch of bugs on the mailing list, and folks have been updating the ​FreeDOS bug tracker. So the bug list should be updated. Most of the FreeDOS Project (and certainly the bugs listed in the bug tracker) are written in C and x86 Assembly. We use OpenWatcom for our C compiler, and NASM for our Assembler. Both are open source. You will need to install FreeDOS somewhere to work on it - I recommend installing FreeDOS in a virtual machine or PC emulator such as QEMU, Bochs, Plex86, VMWare, Virtualbox, or any other PC emulator.

Simple Senet
I wrote Simple Senet a few years ago. My original intention had been to write a playable version of the board game Senet. But as an experiment, I distracted myself by creating a Senet simulator, where two AI players compete: an "aggressive" player vs a "defensive" player. It's interesting to see which play style wins. It's written in C using ncurses for display to a text terminal. A few suggestions:
  1. Update Simple Senet so a real player can move pieces on the board. The rule system for Senet is very simple, so I imagine a human would use a keyboard up/down/left/right to select the piece they want to move, then space or Enter or some other key to move the piece.
  2. Implement a rules subsystem. Senet is a very very old game. It may be the oldest game known! Because it's so old, there are no written rules from ancient times. Experts have had to figure out how to play the game based on evidence; there is some agreement on the rules (PDF), but not everyone plays the same rules. I wanted to separate the rules into a "rules system" that you could select from. One way to do this is via command line options: senet --kendall to play with Kendall's rules, or senet --jequier to play with Jequier's rules, and so on for --tait and --bell. I was going to make these "top level" options as "macros" that are the same as combining a bunch of other command line options like --stop-squares=15,26,28,29,30 or --start=on or --start=off and so on for other options.
  3. Port the game to GNOME. But this is likely better accomplished as a complete re-write.

Atomic Tanks
This is a fun little game that I used to play a lot. I've even submitted some patches, long ago. I recall Atomic Tanks is written in C. In Atomic Tanks, you control a little tank and you combat other (AI) tanks using outlandish weapons. It's basically a trajectory game: angle and power. One change I would recommend is the fonts: the text fonts are pretty basic. You might see if you can find a better free font (for example, from Google Fonts) that you could load instead.

GNU Robots
I wrote this game a long time ago, but others have updated it after me. It was last updated in 2008. It's a game where you write a program for a little robot, then set it loose and watch it explore a virtual world. GNU Robots is written in C, but the robot programs are written in Scheme (implemented by GNU Guile). I recall the build process needs updating, so you might do that. Also, the game currently displays the whole world at once using tiles for each square. They are pretty small and can be difficult to see. I think it would be more fun to have the game "zoom into" the immediate play area (say, the surrounding 7×7 squares, assuming the robot is always in the center square) and display a smaller version of the entire map off to the side with a "highlight" square around the area that is currently zoomed. That would allow players to watch their robot more closely, but still see where the robot is positioned relative to the map.
image: Official FreeDOS fish (cc-by)
by Bas Snabilie, adapted by Mateusz Viste
from FreeDOS Images

Thursday, September 1, 2016

Wrapping up Outreachy

This summer, I mentored three interns as part of Outreachy. Outreachy (formerly the Outreach Program for Women) helps people from groups underrepresented in free and open source software get involved. This was my third time working with Outreachy, but my first time working with more than one intern at a time.

Diana, Ciarrai and Renata have wrapped up their usability tests and posted their analysis. I've highlighted several of their analysis already, but I wanted to share a brief update here, all in one article:

First-time user experience test
In this test, Diana asked testers to simulate an "unboxing" of a new system. The tester turned on the computer, watched the computer start up, and logged in to a fresh "test" account so they get first-user experience. After allowing them to explore GNOME via three broad scenario tasks, Diana asked the testers to rate their reaction to GNOME using emoji.

Diana has posted part one of her analysis, discussing the participants and providing an overview of their reactions. She will soon post part two of her analysis, to share results of the UX test in more detail and suggest a few recommendations for GNOME based on what was observed in the test.

Paper prototype test of new Settings application
The usability test with a paper prototype can be very similar to a traditional usability test with a final product. Ciarrai's usability test examined the new GNOME Settings application. This application is still being designed, so Ciarrai used a paper prototype in her usability test.

Traditional usability test of other areas of GNOME development
Renata's test was a traditional usability test of GNOME. This is basically the same usability test that applicants performed during their initial contribution to Outreachy. In fact, Renata's test examined how certain design areas in GNOME Photos and GNOME Calendar have improved since the usability test performed by Gina in a previous cycle of Outreachy.
image: Outreachy

Friday, August 26, 2016

GNOME usability test analysis

Renata has posted an analysis of her GNOME usability test. You may recall this was a traditional usability test of other areas of GNOME development. We also wanted to measure how GNOME has improved since our last usability test (which was examined in a previous cycle of Outreachy).

Read Renata's blog posts for details, but I'll share very brief overview here. I find it's best to do the analysis in two parts: a heat map, and a discussion of themes.

Heat map

click to view larger version

What were the challenges?

The heat map shows several "hot" rows: creating an album in Photos, adding a new calendar in Calendar, and adding an online account in Calendar. You can also see other "warm" rows as well, but I'll leave those for you to read in Renata's blog.

Create an album (Photos)
Renata observed: "This task was definitely the most challenging to accomplish. All participants went through similar steps to complete this one. First they clicked “Albums” on the view switcher and then tried clicking “Name your first album”, thinking that this option would create a new album. That didn’t work, so they tried right clicking on the screen which also didn’t work. After that, they looked for a “Create an Album” option in the “Application menu” and could not find it. Some participants even searched for “Create an Album” in the search bar. Finally, they tried right clicking on “Photos” and found the “Add to Album” option on the bottom of the screen."

Add a new calendar (Calendar)
From Renata's blog: "In general, all participants were confused by the term “Add a new Calendar” or “Create a new Calendar”. They would expect for an option like “Add a new Calendar” to be located somewhere in the application menu or in a “more obvious” location and not under the “Calendar Settings”. Some even created a new event instead of adding new calendar. Almost all testers were not sure which option to choose for adding the calendar. Testers expected feedback after they named the calendar. They complained about not having an “Apply” button since they were not quite sure if they added the new album."

Add an online account (Calendar)
Renata says this: "The first thing some testers did to is choosing the “synchronize” option on header bar menu. The “+” and “-” signs [in the Online Accounts menu] were not that obvious to indicate their meanings. They would rather prefer something like “Add an Account” and “Remove an Account” buttons."

Renata goes into more depth in her analysis, and covers themes and offers a few suggestions. Read Renata's analysis for more»
image: Outreachy