Thursday, March 7, 2019

Purism's PureOS is convergent

Three years ago on April 2, 2016, I wrote an article about A brief history of user interfaces. In that article, I followed up on another essay of mine about visual brand and user experience, where I introduced the concept of breaking down a user interface into component parts, as a way to identify the distinctive features that create a "visual brand."

At the end of my article, I made a comment that desktop and mobile operating systems were converging:
Today, computers are more than a box with a monitor, keyboard, and mouse. We use smartphones and tablets alongside our desktop and laptop computers. In many cases, "mobile" (phones and tablets) displace the traditional computer for many tasks. I think it's clear that the mobile and desktop interfaces are merging. Before too long, we will use the same interface for both desktop and mobile.

The key to making this work is a user interface that truly unifies the platforms and their unique use cases. We aren't quite there yet, but GNOME 3 and Windows 10 seem well positioned to do so. I think MacOS X and iOS (Apple's mobile platform) feature similar interfaces without uniting the two. Perhaps Apple's is a better strategy, to provide a slightly different user interface based on platform. I think it will be interesting to see this area develop and improve.
This is a similar sentiment to a comment I made on another blog in 2013 about the future of technology. In that article, I theorized how technology might change over time, proposing that our phones might soon substitute for a desktop; just plug in your phone to a keyboard and display, and you can continue your work:
What about five years from now? How will technology inherit the future? What devices will we use at that time? The convergence of mobile devices and laptops seems likely. Some vendors have experimented in this space, with mixed success. It seems a matter of time until someone strikes the right balance, and this new device becomes the next "must-have" technology that displaces even the iPad. …

While the market seems unwilling to adopt this device today, we may in five years consider it obvious that our computer fits in our pocket, as a phone, ready to be docked to a keyboard and monitor for more traditional "desktop" computing.
Well, the future is now. The convergence of mobile devices and laptops is happening. Jeremiah Foster, Director PureOS at Purism, writes in Many Devices, One OS that "Purism’s PureOS is convergent, and has laid the foundation for all future applications to run on both the Librem 5 phone and Librem laptops, from the same PureOS release."

PureOS (which is really GNOME apps on top of the Linux kernel) now sports an Adaptive Design. That means the application can rearrange the user interface to suit the display device it is run from. Take a web browser, for example. On a desktop, you might place UI controls at the top - typical for most desktop UI designs. But on a mobile device, such as a phone, it may be better to move the UI controls elsewhere, such as to the bottom.

Think of Adaptive Design as the application equivalent to Responsive Web Design. A website that uses Responsive Web Design might collapse a list of navigation links to a menu when viewed on a narrow display device, such as a phone. Or the website might rearrange or resize some content (such as images) to better suit a smaller display. Almost every modern website leverages Responsive Web Design.

Congratulations to the folks at Purism for their work in Adaptive Design. Foster comments that Adaptive Design means Purism can re-use PureOS currently used on their 13" and 15" laptops and leverage it to run their 5" phones, coming soon. That's good news for Purism, but it's also a great step forward for technology innovation.

Tuesday, March 5, 2019

Outreachy GNOME usability testing wrap-up

The December-March cycle of Outreachy has finished, and I wanted to do a quick recap of the work from our intern, Clarissa.

As I mentioned when we started week 1 GNOME usability testing, most of our work in the internship was testing designs that haven't gone "live" yet (this is called "prototype usability testing"). Allan and Jakub created mock-ups of new designs, and Clarissa did usability testing on them.

That means a lot of the applications were still being worked on, and were often delivered in Flatpak format since these "in development" versions were not part of a systemwide release (which would have likely been included natively in a Linux distribution somewhere).

As a result, we ran this cycle of usability testing in a more "loose" fashion that we have in previous cycles. We didn't have a long run-up to usability testing, where we could take our time learning about usability testing and carefully constructing new scenario tasks. Rather, Allan provided an overview of what he was hoping to get out of each usability test (how do users respond to this new feature, do they interact with the user interface differently, etc?) and Clarissa had to quickly assemble scenario tasks based on that. I helped with focus and wording on the scenario tasks.

We didn't expect anyone in the internship to come with previous experience, but we needed someone who could learn quickly. We expected that the intern would "learn as you go" and Clarissa did a great job with that!

Clarissa ran three usability tests, which she describes in her Final internship report on her blog. The three tests were:
  1. A new GNOME Sound Settings design (see results)
  2. New designs for GNOME Files and GNOME Notes (see results)
  3. Updated design for GNOME gedit (see results)
In Clarissa's Final internship report, she also shares some thoughts and lessons learned from the internship. Please read Clarissa's blog for her takeaways, but I wanted to highlight this one:
A bigger number of testers does not always give you more precise results. When I applied to the internship, I tried to look for the bigger amount of volunteers as I could because I thought it would bring me better results and I would have a better contribution, and, consequently, I would be chosen for the internship (hehe :P). On the first week of the internship I studied with the help of some articles that Jim sent me and I discovered that the time you spend running tests with more testers than you actually need can be spent with writing results faster and giving the design team more time to work on new designs. I discovered that it was true on the first round, when I ran tests with 7 volunteers, when I needed only 5. I wrote about how many testers do we need here.
I've highlighted the important bit.

You don't need very many testers to get useful results. This is especially important if you are doing iterative testing: create a design, test it, tweak the design based on results, test it again, tweak the design again, test it again, final tweaks based on results. You can learn enough about the design by using only five testers. If each tester exercises about 31% of usability problems, after five testers you've uncovered 85% of the issue. That's enough to make changes to the design.

Doing more tests with more testers doesn't really get you much further down the road. Do each round of usability testing with about five testers and you'll be fine. And that's exactly what Clarissa found.

I'm very proud of Clarissa for her work in this cycle of Outreachy. She great work and provided many useful results that I'm sure the Design team will be able to use to tweak future designs. That's why we do usability testing.

On a personal note, it was great to stay involved in GNOME and be part of usability testing. I believe being a mentor is a valuable experience. If you haven't mentored an intern as part of your work in open source software, I encourage you to do so. Outreachy is a wonderful opportunity because it provides paid internships for women and other underrepresented groups to work in open source software.

But there are other ways to mentor someone. Find an outlet that works for you, and bring someone under your wing. By helping others get involved in open source software, we make the entire open source community stronger.

Monday, January 14, 2019

This is in English

I just posted a blog item in Spanish, by way of showing support for Clarissa, my intern on the Outreachy program. But I'm sure my Spanish is pretty rusty these days, so I wanted to share what I was trying to communicate, by writing it again in English.
I usually speak and write in English, but for this article, I am writing it in Spanish.

A few weeks ago, I read a blog article by my intern Clarissa in Outreachy. In her article, Clarissa wrote about her challenges in the program. One challenge for her was writing in English. Her native language is Portuguese.

Clarissa's writing is so good that I often forget that English is not her native language. So I wanted to share that experience by writing a blog article of my own in another language. I can speak some Spanish; I learned it in high school and lived for part of a summer in Mexico (about a month, part of a student-abroad language-immersion program for advanced students). But I don't write in Spanish very well.

Writing in Spanish is very difficult for me. I know many of the words, but some I need to translate via Google Translate. I'm sure I'm writing seems stilted and awkward. That's because I'm writing in a language that I don't usually write in.

I support Clarissa in her internship. Writing in another language is really difficult. I can do it, but it takes about twice the time for me me to write what I want to because I'm not very strong in the Spanish language. From this, I can really appreciate the challenges that Clarissa goes through in writing for Outreachy.

This is in Spanish

Yo hablo y escribo inglés. Pero para este artículo, yo escribo en español.

Hace unas semanas, leí un artículo del blog de mi pasante Clarissa en Outreachy. En su artículo, Clarissa escribió sobre sus desafíos en el programa. Un desafío fue escribir en inglés. Su lengua natural es el portugués.

La escritura de Clarissa es buena porque a olvido que el inglés no es su lengua natural. Así que quería compartir la experiencia escribiendo un artículo de mi blog en otro lengua. Puedo hablar algo de español; lo aprendí en la escuela secundaria y durante viví un verano en México. Pero no escribo muy bien el español.

Escribir en español es muy difícil. Conozco muchas de las palabras, pero algunas tengo que traducirlas en Google Translate. Estoy seguro de que mi escritura parece incómoda. Eso es porque estoy escribiendo en una lengua que no suelo escribir.

Apoyo a Clarissa en su pasantía. Escribir en otro idioma es muy difícil. Puedo hacerlo, pero me lleva mucho tiempo escribir lo que quiero porque no domino el idioma español. Aprecio más los desafíos que Clarissa tiene por escrito para Outreachy.

Friday, December 21, 2018

Top ten of 2018

As always, I enjoy writing about the usability of open source software. This year, I've written several articles about usability—some on my blog, others as articles in journals and websites. As I look back on the last twelve months, I thought it would be interesting to highlight a few of my favorite blog posts from the year. And here they are, in no particular order:

1. Why the Linux console has sixteen colors
At the 2018 Seattle GNU/Linux Conference after-party, I gave a lightning talk about why the Linux console has only sixteen colors. Lightning talks are short, fun topics. I enjoyed giving the lightning talk, and the audience seemed into it, too. So I thought I'd share my lightning talk here. These are my slides in PNG format, with notes added.
2. Usability Testing in Open Source Software
I recently attended the 2018 Seattle GNU/Linux Conference, where I gave a presentation about usability testing in open source software. I promised to share my presentation deck. Here are my slides in PNG format, with notes added.
3. Making a first contribution in Outreachy usability testing
This year, I decided to get back into the Outreachy program as a mentor. Outreachy is a paid internship program for women and others who are under-represented in open source software. As part of an intern's application process, we ask that they make a first contribution to their project. Since I would mentor usability testing for GNOME, this post explained how to do a usability test as part of that initial contribution. I think it's a good starting point for anyone who wants to get into usability testing.
4. Open source tools I used to write my latest book
I recently wrote a book about FreeDOS. Using FreeDOS is my celebration of the 24th anniversary of FreeDOS. This is a collection of how-tos about installing and using FreeDOS, essays about my favorite DOS applications, and quick-reference guides to the DOS command line and DOS batch programming. I've been working on this book over several months, with the help of a great professional editor. The book was produced almost entirely with open source software. I'd like to share a brief insight into the tools I used to create, edit, and produce Using FreeDOS.
5. The next step in open data is open source
For the last three years, I have served as CIO in local government. Governments at all levels are moving to embrace open data, where governments share public data proactively with citizens. Open data can be used, reused, mixed, and shared by anyone. I believe that next step is open source. Where we provide government data sets for anyone to view, adapt, and remix, we need to offer government source code for others to view, adapt, and remix.
6. What an icon says about you
When I first started doing usability testing, I focused on icons. How will users perceive the function exposed by a single button, especially if that button is an icon? Icons can be abstract or representative. For example: in a word processing program, what icon would you click to print a document? In this essay, I discuss elements of icons, and offer advice to Firefox as they proposed a new icon set.
7. A few thoughts on GNOME usability
I recently learned that GNOME developers have proposed moving the application menu off the "top black bar" and into the application window. In this post, I shared a few thoughts on the new design concept.
8. A few thoughts on copyright
Every once in a while, I'll come across a discussion where someone justifies pirating a movie or popular TV show with "nothing of value was lost." Basically, these people claim that it isn't really "stealing" if the content creator (HBO, Disney, etc) keeps the original copy. But whether you realize it or not, copyright protection works for more than just the Big Media companies (HBO, Disney, etc). Copyright works for Free software and open source software, too. In fact, the copyleft afforded by the GNU General Public License only works because of copyright protections.
9. Open source software reading list
A colleague had asked what books I'd recommend about open source software. I go back a ways with open source software. I first contributed to Free software and open source software in 1993, before the term "open source software" was widely adopted. So my list of book recommendations has some older titles on there. And that's good, because this list also provides a solid grounding for contributing to open source software.
10. What open source software programs I love
Earlier this year, someone asked me what Free software and open source software programs I really love. I thought I'd share that here, too. As I started to go through my favorite programs, I realized it was quite long. So I'm trying to keep the list short here, just the programs I use the most.

Saturday, December 8, 2018

Week 1 of GNOME usability testing

The Outreachy internship started this week! For this cycle, we are joined by Clarissa, who will help us with usability testing in GNOME.

I wanted to share our progress in the internship. I hope to provide regular status updates on our work.

For this week, I want to start with a grounding in Usability testing. You can do usability testing in different ways. Alice Preston described the types of usability methods for the STC newsletter (Vol 10, No. 3). I can't find a copy of that newsletter online, but in the list, she describes 11 ways to evaluate usability in a design. Preston's list is:

  1. Interviews/Observations: One-on-one sessions with users.
  2. Focus Groups: Often used in marketing well before there is any kind of prototype or product to test, a facilitated meeting with multiple attendees from the target user group.
  3. Group Review or Walk-Through: A facilitator presents planned workflow to multiple attendees, who present comments on it.
  4. Heuristic Review: Using a predefined set of standards, a professional usability expert reviews someone else's product or product design and presents a marked checklist back to the designer.
  5. Walk-Around Review: Copies of the design/prototype/wireframe are tacked to the walls, and colleagues are invited to comment.
  6. Do-it-Yourself Walk-Through: Make mock-ups of artifacts, but make the scenarios realistic. Walk through the work yourself.
  7. Paper Prototype Test: Use realistic scenarios but a fake product.
  8. Prototype Test: A step up from a paper prototype, using some type of animated prototype with realistic scenarios.
  9. Formal Usability Test: Using a stable product, an animated prototype, or even a paper prototype, test a reasonably large number of subjects against a controlled variety of scenarios.
  10. Controlled Experiment: A comparison of two products, with careful statistical balancing, etc
  11. Questionnaires: Ask testers to complete a formal questionnaire, or matching questionnaire.


Most of our work in the internship will be testing designs that haven't gone "live" yet (this is called "prototype usability testing"). Allan and Jakub will create mock-ups of new designs, and Clarissa will do usability testing on them. You can read a bit about this on Allan's blog post.

In that post, Allan writes:
Therefore, for this round of the Outreachy internships, we are only going to test UX changes that are actively being worked on. Instead of testing finished features, the tests will be on two things:
  1. Mockups or prototypes of changes that we hope to implement soon (this can include static mockups and paper or software prototypes)
  2. Features or UI changes that are being actively worked on, but haven’t been released to users yet

Ciarrai interned with us a few years ago, and worked on prototype usability testing for the then-upcoming GNOME Settings app redesign. We wrote an article together for OpenSource.com about paper-based usability testing that you might find interesting.

You may also be interested in an older article I wrote about usability testing with prototypes. I don't expect that we'll be testing with the animated prototypes that my article proposes, but it's good background material.

As you prepare for usability testing, you may ask "How many testers do I need?" The answer is "about five" if you are doing a traditional usability test. For a paper prototype test, this may be different. How many do you think we need?

For additional background, you might be interested to read this essay about how many testers you need, and why the answer is "about five." Note that "five" only applies to doing usability testing in a traditional or "formal" usability test, where you test real people with real scenario tasks against a real product. For paper prototype testing, you have a different value for L, so we'll need a different number of testers. But this is a good start to understanding the assumptions.

Usability expert Jakob Nielsen has a good video about "five testers" that I often recommend.

Looking for more background information? Here are a few additional articles related to "how many testers do I need?"



That last article makes an interesting point that I'll quote here: "Studies to evaluate a prototype of a novel user-interface design often concern the discovery of severe show-stopper problems. Testing usually reveals such severe errors relatively quickly, so these tests often require fewer participants."

But, how many testers do you think you'll need for each iteration of prototype testing?

Monday, November 12, 2018

Why the Linux console has sixteen colors (SeaGL)

At the 2018 Seattle GNU/Linux Conference after-party, I gave a lightning talk about why the Linux console has only sixteen colors. Lightning talks are short, fun topics. I enjoyed giving the lightning talk, and the audience seemed into it, too. So I thought I'd share my lightning talk here. These are my slides in PNG format, with notes added:
Also, my entire presentation is under the CC-BY:
When you bring up a terminal window, or boot Linux into plain text mode, maybe you've wondered why the Linux console only has sixteen colors. No matter how awesome your graphics card, you only get these sixteen colors for text:
You can have eight background colors, and sixteen foreground colors. But why is that?
Remember that Linux is a PC operating system, so you have to go back to the early days of the IBM PC. Although the rules are the same for any Unix terminal.

The origins go back to CGA, the Color/Graphics Adapter from the earlier PC-compatible computers. This was a step up from the plain monochrome displays; as the name implies, monochrome could only display black or white. CGA could display a limited range of colors.

CGA supported mixing red (R), green (G) and blue (B) colors. In its simplest form, RGB is either "on" or "off." In this case, you can mix the RGB colors in 2×2×2=8 ways. So RGB=100 is Red, and RGB=010 is Green, and RGB=001 is Blue. And you can mix colors, like RGB=011 is cyan. This simple table shows the binary and decimal representations of RGB:
To double the number of colors, CGA added an extra bit called the "intensifier" bit. With the intensifier bit set, the red, green and blue colors would be set to their maximum values. Without the intensifier bit, each RGB value would be set to a "midrange" intensity. Let's represent that intensifier bit as an extra 1 or 0 in the binary color representation, as iRGB:
That means 0100 gives "red" and 1100 (with intensifier bit set) results in "bright red." Also, 0010 is "green" and 1010 is "bright green." And 0000 is "black," but 1000 is "bright black."

Oh wait, there's a problem. "Black" and "bright black" are the same color, because there's no RGB value to intensify.

But we can solve that! CGA actually implemented a modified iRGB definition, using two intermediate values, at about one-third and two-thirds intensity. Most "normal" mode (0–7) colors used values at the two-thirds intensity. Translating from "normal" mode to "bright" mode, convert zero values to the one-third intensity, and two-thirds values to full intensity.

With that, you can represent all the colors in the rainbow: red, orange, yellow, blue, indigo, and violet. You can sort of fake the blue, indigo, and violet with the different "blue" shades.

Oops, we don't have orange! But we can fix that by assigning 0110 yellow a one-third green value that turned the color into orange, although most people saw it as brown.

Here's another iteration of the color table, using 0x0 to 0xF for the color range, with 0x5 and 0xA as the one-third and two-thirds intensities, respectively:
And that's how the Linux console got sixteen text colors! That's also why you'll often see "brown" labeled "yellow" in some references, because it started out as plain "yellow" before the intensifier bit. Similarly, you may also see "gray" represented as "bright black," because "gray" is really "black" with the intensifier bit set.

So let's look at the bit patterns. You have four bits for the foreground color, 0000 black to 1111 bright white:
And you have three bits for the background color, from 000 black to 111 white:
But why not four bits for the background color? That's because the final bit is reserved for a special attribute. With this attribute set, your text could blink on and off. The "Blink" bit was encoded at the end of the foreground and background bit-pattern:
That's a full byte! And that's why the Linux console has only sixteen colors; the Linux console inherits text mode colors from CGA, which encodes colors a full byte at a time.

It turns out the rules are the same for other Unix terminals, which also used eight bits to represent colors. But on other terminals, 0110 really was yellow, not orange or brown.