Friday, December 29, 2017

So long, Linux Journal

If you don't know, Linux Journal has ceased publication. Unless an investor drops in at the last minute, the LJ website will soon shut down. Thus ends over twenty-three years in Linux and open source publication. That's quite a legacy!

Linux Journal first hit shelves in April 1994. To remind you about those times: that's when Linux reached the 1.0 version milestone. That's also the same year that I started the FreeDOS Project. Elsewhere in technology, Yahoo!, Amazon, and Netscape got their start in 1994. That's also the same year the shows E.R. and Friends first hit TV. Also that year, the movies Pulp Fiction, Forrest Gump, Speed, and Stargate.

In 1994, you most likely connected to the Internet using a dial-up modem. KDE and GNOME were several years away, so the most popular Linux graphical interface in 1994 was FVWM, or the more lightweight TWM. In 1994, you probably ran an 80486 Intel CPU, unless you had upgraded to the recently-released Pentium CPU. In mainstream computing, Microsoft's Windows 3.1 ruled; Windows95 wouldn't come out for another year. In the Apple world, Macs ran MacOS 7.1 and PowerPC CPUs. Apple was strictly a hardware company; no one had heard of iTunes or an iPod.

With that context, we should recognize Linux Journal as having made an indelible mark in computing history. LJ chronicled the new features of Linux, and Linux applications. I would argue that Linux Journal helped raise the visibility of Linux and fostered a kind of Linux ecosystem.

Linux Journal operated in the same way that Linux developers did: LJ encouraged its community to write articles, essays, and reviews for the magazine and website. You didn't do it for the money; I think I received tiny payments for the articles I submitted. Rather, you wrote for LJ for the love of the community. That's certainly why I contributed to Linux Journal. I wanted to share what I had learned about Linux, and hoped others would enjoy my contributions.

So before the Linux Journal website goes dark, I wanted to share a few articles I wrote for them. Here you are:


Update:

Looks like Linux Journal was saved at the last minute by investors! From the article:
In fact, we're more alive than ever, thanks to a rescue by readers—specifically, by the hackers who run Private Internet Access (PIA) VPN, a London Trust Media company. … In addition, they aren't merely rescuing this ship we were ready to scuttle; they're making it seaworthy again and are committed to making it bigger and better than we were ever in a position to think about during our entirely self-funded past.

Saturday, December 23, 2017

Top ten in 2017 (part 2 of 2)

Following up from part 1, here's the rest of my favorite blog articles from this year:

6. Debian and GNOME usability testing
Intrigeri emailed me to share that "During the Contribute your skills to Debian event that took place in Paris last week-end, we conducted a usability testing session" of GNOME 3.22 and Debian 9. They have posted their usability test results at Intrigeri's blog: "GNOME and Debian usability testing, May 2017." The results are very interesting and I encourage you to read them! Here's an overview.
7. FreeDOS is 23 years old
In the 1980s and early 1990s, I was a huge DOS nerd. I loved DOS, and used it for everything. I wrote all my class papers in WordPerfect or shareware Galaxy Write on MS-DOS, and did all of my physics lab analysis using the As-Easy-As shareware spreadsheet. I just though DOS was a great little operating system. So I wasn't pleased when Microsoft said they were going to "kill" MS-DOS with the next release of Windows (Windows95). In June 1994, I announced an open source software project to create our own compatible implementation of DOS, which became the FreeDOS Project. In June 2017, FreeDOS turned 23 years old. See also our free FreeDOS ebook.
8. A look back at Linux 1.0
The Linux kernel turned 26 years old this year. To celebrate, I installed one of the first true Linux distributions: SoftLanding Systems Linux 1.03, featuring the then-new Linux 1.0 kernel. I wrote about it on Opensource.com. Great to go back to explore what Linux looked like in 1994.
9. How I put Linux in the enterprise
I used to work in higher ed. In the late 1990s, we moved to a new student records system. We created an "add-on" web registration system, so students could register on-line—still a new idea in 1998. But when we finally went live, the load crushed the web servers. No one could register. We tried to fix it, but nothing worked. Then we had the idea to move our web registration to Linux, which rescued our failing system. I wrote about the experience on Opensource.com, and shared some lessons you can apply to your own Linux migration.
10. Reflection on trip to Kiel
This summer, I attended the Kieler Open Source und Linux Tage in Kiel, Germany. I shared two presentations: a history of the FreeDOS Project, and how to do usability testing in open source software. Here is my summary of that trip.

And here's looking forward to a great 2018!

Saturday, December 16, 2017

Top ten in 2017 (part 1 of 2)

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

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

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

Sunday, December 10, 2017

The art of the usability interview

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

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

Before starting a scenario or set of scenarios:

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

After finishing a set of scenarios:

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


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