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.