Saturday, January 7, 2017

The importance of the press kit

I'd like to share a few lessons I've learned about creating a press kit. This helped us spread the word about our recent FreeDOS 1.2 release, and it can help your open source software project to get more attention.
I'm part of several open source software projects, but probably the one that I'll be remembered for is FreeDOS. As an open source software implementation of DOS, you might not think that FreeDOS will get much attention in today's tech news. Yet when we released FreeDOS 1.2 a few weeks ago, we got a ton of news coverage.

Slashdot was the first to write about FreeDOS 1.2, but we also saw coverage from Engadget Germany, LWN, Heise Online, PC Forum Hungary, FOSS Bytes, ZDNet Germany, PC Welt, Tom's Hardware, and Open Source Feed. And that's just a sample of the news! There were articles from the US, Germany, Japan, Hungary, Ukraine, Italy, and others.

In reading the articles people had written about FreeDOS 1.2, I realized something that was both cool and insightful: most tech news sites re-used material from our press kit.

You see, in the weeks leading up to FreeDOS 1.2, I assembled additional information and resources about FreeDOS 1.2 release, including a bunch of screenshots and other images of FreeDOS in action. In an article posted to our website, I highlighted the press kit, and added "If you are writing an article about FreeDOS, feel free to use this information to help you." And they did!

We track a complete timeline of interesting events on our FreeDOS History page, including links to articles. Comparing the press coverage from FreeDOS 1.0, FreeDOS 1.1 and FreeDOS 1.2, we definitely saw the most articles about FreeDOS 1.2. And unlike previous releases where only a few tech news websites wrote articles about FreeDOS and other news outlets mostly referenced the first few sites, the coverage of FreeDOS 1.2 was mostly original articles. Only a small handful were references to news items from other news sites.

I put that down to the press kit. With the press kit, journalists were able to quickly pull interesting information and quotes about FreeDOS, and find images they could use in their articles. For a busy journalist who doesn't have much time to write about a free DOS implementation in 2016, our press kit made it easy to create something fresh. And news sites love to write their own stories rather than link to other news sites. That means more eyeballs for them.

Here are a few lessons I learned from creating our press kit:
Include basic information about your open source software project.
What is your project about? What does it do? How is it useful? Who uses it? What are the new features in this release? These are the basic questions any journalist will want to answer in their article, if they choose to write about you. In the FreeDOS press kit, I also included a history about FreeDOS, discussing how we got started in 1994 and some highlights from our timeline.
Write in a casual, conversational tone that's easy to quote.
In writing about your project, pretend you are writing an email to someone you know. Or if you prefer, write like you are posting something to a personal blog. Keep it informal. Avoid jargon. If your language is too stuffy or too technical, journalists will have a hard time quoting from you. In writing the FreeDOS press kit, I started by listing a few common questions that people usually ask me about FreeDOS, then I just responded to them like I was answering an email. My answers were often long, but the paragraphs were short so easier to skim.
Provide lots of screenshots of your project doing different things.
Whether your program runs from the command line or in a graphical environment, screenshots are key. And tech news sites like to use images; they are a cheap way to draw attention. So take lots of screenshots and include them in your press kit. Show all the major features through these screenshots. But be wary of background images and other branding that might distract from your screenshots. In particular, if the screenshot will show your desktop, set your wallpaper to the default for your operating system, or use a solid color in the range medium- to light-blue. For the FreeDOS press kit, I took a ton of screenshots of every step in the install process. I also grabbed screenshots of FreeDOS at the command line, running utilities and tools, and playing some of the games we installed.
Organize your material so it's easy to read.
You may find your press kit will become quite long. That's okay, as long as this doesn't make it difficult for someone to figure out what's there. Put the important stuff first. Use a table of contents, if you have a lot of information to share. Use headings and sections to break things up. If a journalist can't find the information they need to write an article about your project, they may skip it and write about something else. I organized our press kit like a simple website. An index page provided some basic information, with a list of links to other material contained in the press kit. I arranged our screenshots in separate "pages." And every page of screenshots started with a brief context, then listed the screenshots without much fanfare. But every screenshot included a description of what you were seeing. For example, I had over forty screenshots from installing FreeDOS, and I wrote a one-sentence description for each.
Be your own editor.
No matter how much work you put into it, one will want to use your press kit if it is riddled with spelling errors and poor grammar. Consider writing your press kit material in a word processor and running a spell check against it. Read your text aloud and see if it makes sense to you. When you're done, try to look at your press kit from the perspective of someone who hasn't used your project before. Can they easily understand what it's about? To help you in this step, ask a friend to review the material for you.
Advertise, advertise, advertise!
Don't assume that tech news sites will seek you out. You need to reach out to them to let them know you have a new release coming up. Create your press kit well in advance, and about a week or two before your release, individually email every journalist or tech news website that might be interested in you. Most news sites have a "Contact us" link or list of editor "beats" where you can direct yourself to the writer or editor most likely to write about your topic. Craft a short email that lets them know who you are, what project you're from, when the next release will happen, and what new features it will include. Give them a link to the press kit directly in your email. But make the press kit easy to see in the email. Use the full URL to the press kit, and make it clickable. Also link to the press kit from your website, so anyone else who visits your project can quickly find the information they need to write an article.
By doing a little prep work before your next major release, you can increase the likelihood that others will write about you. And that means you'll get more people who discover your project, so your open source software project can grow.

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