Monday, September 18, 2017

Reflection on trip to Kiel

On Sunday, I flew home from my trip to Kiel, Germany. I was there for the Kieler Open Source und LinuxTage, September 15 and 16. It was a great conference! I wanted to share a few details while they are still fresh in my mind:

I gave a plenary keynote presentation about FreeDOS! I'll admit I was a little concerned that people wouldn't find "DOS" an interesting topic in 2017, but everyone was really engaged. I got a lot of questions—so many that we had to wrap up before I could answer all the questions.

FreeDOS has been around for a long time. We started FreeDOS in 1994, when I was still an undergraduate physics student. I loved DOS at the time, and I was upset that Microsoft planned to eliminate DOS when they released the next version of Windows. If you remember, the then-current version was Windows 3.1, and it wasn't great. And Windows's history up to this point wasn't promising: Windows 1 looked pretty much like Windows 2, and Windows 2 looked like Windows 3. I decided that if Windows 4 would look anything like Windows 3.1, I wanted nothing to do with it. I preferred DOS to clicking around the clumsy Windows interface. So I decided to create my own version of DOS, compatible with MS-DOS so I could continue to run all my DOS programs.

We recently published a free ebook about the history of FreeDOS. You can find it on our website, at 23 Years of FreeDOS.

My second talk that afternoon was about usability testing in open source software. The crowd was smaller, but they seemed very engaged during the presentation, so that's good.

I talked about how I got started in usability testing in open source software, and focused most of my presentation on the usability testing we've done as part of the Outreachy internships. I highlighted the GNOME usability testing from my interns throughout my participation in Outreachy: Sanskriti, Gina, Renata, Ciarrai, and Diana.

Interesting note: Ciarrai's paper prototype test on the then-proposed Settings redesign will be published this week on OpenSource.com, so watch for that.

The conference recorded both presentations, and they'll be uploadeded to YouTube in the next few days. I'll link to them when they are up.
image: Kieler Open Source und LinuxTage

Sunday, September 17, 2017

Documentation needs usability, too

If you're like most developers, writing documentation is hard. Moreso if you are writing for end-users. How do you approach writing your documentation?

Remember that documentation needs good usability, too. If documentation is too difficult to read—if it's filled with grammatical mistakes, or the vocabulary is just too dense, or even if it's just too long—then few people will bother to read it. Your documentation needs to reach your audience where they are.

Finding the right tone and "level" of writing can be difficult. When I was in my Master's program, I referred to three different styles of writing: "High academic," "Medium academic," and "Low academic."
High academic is typical for many peer-reviewed journals. This writing is often very dense and uses large words that demonstrate the author's command of the field. High academic writing can seem very imposing.

Medium academic is more typical of undergraduate writing. It is less formal than high academic, yet more formal than what you find in the popular press.

Low academic tends to include most professional and trade publications. Low academic authors may sprinkle technical terms here and there, but generally write in a way that's approachable to their audience. Low academic writing uses contractions, although sparingly. Certain other formal writing conventions continue, however. For example, numbers should be written out unless they are measurements; "fifty" instead of "50," and "two-thirds" instead of "2/3." But do use "250 MB" and "1.18 GHz."
In my Master's program, I learned to adjust my writing style according to my instructors' preferences. One professor might have a very formal attitude towards academic writing, so I would use High academic. Another professor might approach the subject more loosely, so I would write in Medium academic. When I translated some of my papers into articles for magazines or trade journals, I wrote in Low academic.

And when I write my own documentation, I usually aim for Low academic. It's a good balance of professional writing that's still easy to read.

To make writing your own documentation easier, you might also consult the Google Developer Documentation Style Guide. Google just released their guide for anyone to use. The guide has guidelines for style and tone, documenting future features, accessible content, and writing for a global audience. The guide also includes details about language, grammar, punctuation, and formatting.

Wednesday, September 13, 2017

On my way to Kieler Open Source und Linux Tage

Just wanted to share a brief update that I'm now on my way to Kiel, Germany for the Kieler Open Source und Linux Tage. I will be sharing two presentations:

The FreeDOS Project: Then and Now

I'll be talking about the history of the FreeDOS Project, and a little about where things are headed. If you don't know about FreeDOS: FreeDOS is a complete, free, DOS-compatible operating system that you can use to play classic DOS games, run legacy business software, or develop embedded systems. Any program that works on MS-DOS should also run on FreeDOS.

Usability Testing in Open Source Software

This presentation is for anyone who works on open source software, and wants to make it easier for everyone to use. I'll talk about some easy methods you can use to test the usability of your software, and then how to quickly identify the "trouble spots" that you need to fix.

If you're planning to attend Kieler, please let me know!

Update: I've made my slides available for download. You can find them on my personal page. Both presentations are available under the Creative Commons Attribution (CC BY).
image: Kieler Open Source und LinuxTage

Saturday, September 9, 2017

23 Years of FreeDOS

On June 29th, 2017, FreeDOS turned 23 years old. There’s nothing special about "23," but I thought it would be great to celebrate the anniversary by having a bunch of past and current users share their stories about why they use FreeDOS. So, I made a call for users to write their own FreeDOS stories.

Many people shared their FreeDOS story, many of which were shared on the FreeDOS Blog. We have collected these stories into a free ebook, 23 Years of FreeDOS. (CC BY 4.0) This ebook contains the voices of many of the users who contributed their stories, as well as the history of FreeDOS.

These stories are written from different perspectives, such as: "How did you discover FreeDOS?" "What do you use FreeDOS for?" and "How do you contribute to FreeDOS?" In short, I requested users to answer the question: "Why FreeDOS?"

Many individuals have helped make FreeDOS what it is, but this ebook represents only a few of them. I hope you enjoy this collection of 23 years of everything FreeDOS!

To download the free ebook, go to 23 Years of FreeDOS (ebook) on the FreeDOS website.
image: FreeDOS

Flat design is harder to understand

Interesting research from the Nielsen Group shows that a flat web design is harder for people to understand. The usability study was conducted against web pages, but the results apply equally well to graphical user interfaces.

First, let me define the "flat" web design: Websites used to use colors on links (usually blue) with underline, and 3D-style buttons. Web designers really didn't have to do anything to make that happen; the standard web styles defines blue as a link color (purple as a visited link color) and any button element will appear in a 3D style (such as beveled edges).

In recent years, it has become fashionable for web designers to "flatten" the website design: links appear like normal paragraph text, and buttons are plain rectangles with no special decoration. Here's a trivial example of a flat web design:
Title text

Hi there! This is some sample text that you might find on a website. Let's say you are on a shopping website, this text might be an item description. Or if you're on a news website, this might be the summary for a news article. And below it, you might have a link for more information.

Click here for more
Looking at that example, do you know what to click on? Do you know that you can click on something? Actually, you can click on the title text or the "Click here for more." Both are links to Google.

These flat user interface elements attract less attention and cause uncertainty, according to Nielsen's research.

The Nielsen article is very interesting, and if you are interested in usability or user interface design (or web design), then I encourage you to read it. The article includes "gaze maps" (heat maps that show where testers looked on the web page) on web pages that used a flat design (weak signifiers) versus a more traditional design (strong signifiers).

It's not all bad, though. A flat design can work in some specific circumstances. From the article: "As we saw in this experiment, the potential negative consequences of weak signifiers are diminished when the site has a low information density, traditional or consistent layout, and places important interactive elements where they stand out from surrounding elements." (emphasis mine) And, "Ideally, to avoid click uncertainty, all three of those criteria should be met, not just one or two."

So your best bet in user interface design is to make sure clickable items look clickable: buttons should have a 3D design, and links should be styled with a different color and underline to look like clickable links instead of regular text.

Thursday, September 7, 2017

Dissecting the Sierpinski Triangle program

Last week, I shared my return to old school programming. My first home computer was an Apple II clone called the Franklin ACE 1000, and it was on this machine that my brother and I taught ourselves how to write programs in AppleSoft BASIC. And last week, I had an itch to return to the Apple II and write a simple BASIC program to generate the Sierpinski Triangle:


Let me briefly show you how to code the Sierpinski Triangle in AppleSoft BASIC. Fortunately, this is a simple program that only uses a few functions and statements:
DIM
Create an array variable

LET
Assigns a value to a variable

FORNEXT
Basic iteration loop structure

PRINT
Display information to the screen

INT()
Return the integer portion of a number

RND()
Return a random number between 0 and 1

And for the graphics, these statements:
GR or HGR
Set standard graphics (GR) mode or high-resolution graphics (HGR) mode

COLOR= or HCOLOR=
Set the color for drawing graphics in GR or HGR mode, respectively

PLOT or HPLOT
Make a single pixel dot in GR or HGR mode, respectively

So with those instructions, I was able to iterate a chaos generation of the Sierpinski Triangle. Again, if you aren't familiar with this method to generate the Sierpinski Triangle, the brief rules are:
  1. Set three points that define a triangle
  2. Randomly select a point anywhere (x,y)
Then:
  1. Randomly select one of the triangle's points
  2. Set the new x,y to be the midpoint between the previous x,y and the triangle point
  3. Repeat
Let's start with the first step, to define the triangle's end points. I used two parallel single-dimension arrays, and assigned values to them. This assigns the points at 0,39 (left,bottom) and 20,0 (middle,top) and 39,39 (right,bottom):
DIM X(3)
DIM Y(3)
LET X(1) = 0
LET X(2) = 20
LET X(3) = 39
LET Y(1) = 39
LET Y(2) = 0
LET Y(3) = 39
Note that in AppleSoft BASIC, arrays start at 1. And of course, all lines must have line numbers, but I won't show those here.

Then I defined a random point anywhere on the board. Since it's random, it doesn't really matter what I pick, so I hard-coded this at 10,10:
LET XX = 10
LET YY = 10
To draw each pixel in the Sierpinski Triangle, we need to be in graphics mode. So I use GR to set standard graphics mode, and set the draw color to blue (7):
GR
COLOR= 7
I chose to make 2,000 iterations on the triangle. Maybe this was overkill for GR mode, but it worked well in HGR mode, so I just left it. You start an iteration loop with the FOR statement that specifies the start and end values, and close the loop with the NEXT statement. Since you can have nested loops, the NEXT statement requires the variable you are iterating:
FOR I = 1 TO 2000
...
NEXT I
Inside the loop, I pick a triangle end point at random, then do some simple math to find the midpoint between the current XX,YY and the end point. AppleSoft BASIC only allows variable names up to two characters long. So here, IX stands for "index."

Technically, RND(1) returns a floating point value from 0 to 0.999…, so multiplying by 3 gives 0 to 2.999…. Adding 1 to this results in a floating point value between 1 and 3.999…. To use this as the index of an array, I want an integer, so I use the INT() function to return just the integer part, resulting in a final integer value between 1 and 3, inclusive:
LET IX = 1 + INT (3 * RND (1))
With that, I can compute the midpoint:
LET XN = INT ((XX + X(IX)) / 2)
LET YN = INT ((YY + Y(IX)) / 2)
Again, since AppleSoft BASIC only allows variable names of up to two characters long, XN represents "X new" and YN represents "Y new."

Then I reassign those values back to XX and YY, then plot the pixel on the screen:
LET XX = XN
LET YY = YN
PLOT XX,YY
And as a way to track the progress of the overall iteration, I print the counter I before starting the loop over again:
PRINT I
And that's how to create a Sierpinski Triangle in AppleSoft BASIC!

(Oops, I used floating point variables throughout, when I should have been using integer variables. My bad. If I were to code this again, I would use variables like XX% instead of XX. That would also obviate the need to use the INT() function, since the value would be automatically cast to integer when saving the value to the integer variable.)


BASIC is a very straightforward language, with only a few statements and essential functions. AppleSoft BASIC was not a very difficult language to learn. Even as a young child, I quickly figured out how to create simple math quizzes. From there, I graduated to larger and more complex programs, including one that effectively emulated the thermonuclear war simulator from the 1983 movie, War Games!

But I'll stop here, and leave it to you to learn more about BASIC on your own. You can find AppleSoft BASIC programming guides in lots of places on the Internet. Landsnail's Apple II Programmer's Reference is a good one.

Saturday, September 2, 2017

Return to old school programming

When my brother and I were growing up, our parents brought home an Apple II personal computer. Actually ours was one of the first Apple "clones," a Franklin ACE 1000, but it ran all of the original Apple software. And more importantly, you could write your own programs with the included AppleSoft BASIC.

My brother and I cracked open the computer guide that came with it, and slowly taught ourselves how to write programs in BASIC. My first attempts were fairly straightforward math quizzes and other simple programs. But as I gained more experience in BASIC, I was able to harness high resolution graphics mode and do all kinds of nifty things.

AppleSoft BASIC was my first programming language. And while I eventually moved on to other compiled languages (I prefer C) and other programming environments, I think I'll always have a soft spot for AppleSoft BASIC.

BASIC was a very simple programming language. Two-letter variable names, line numbers, and other hallmarks were typical for AppleSoft BASIC. But even within these limitations, you could create pretty impressive programs if you were clever.

Recently, I've been spending free time playing around with an Apple II emulator, writing a few simple programs as a "throwback" to that old school programming. The Apple IIjs emulator runs in your web browser and very effectively simulates running an old Apple II computer from the 1980s. You can find other Apple II emulators specifically for Linux.

I want to share a program I recently wrote on Apple IIjs: a chaos generation of the Sierpinski Triangle. If you aren't familiar with this method to generate the Sierpinski Triangle, the brief rules are:

  1. Set three points that define a triangle (A,B,C)
  2. Randomly select a point anywhere (x,y)
Then:
  1. Randomly select one of the triangle's points (A,B,C)
  2. Set the new x,y to be the midpoint between the previous x,y and the triangle point
  3. Repeat

And with this rule set, I created a very simple iteration of the Sierpinski Triangle. This sample uses the standard graphics resolution mode (GR) with 40×40 pixels.


The code to generate this image is fairly straightforward:


Two thousand steps takes forever to run on the simulated 6502 microprocessor, by the way. Just like computing in the 1980s.

For a more interesting view of the Sierpinski Triangle on the Apple II, it helps to switch to a higher resolution. Apple's high resolution mode (HGR) allowed a whopping 280×192 pixels.


This requires changing two lines of code: line 50 sets HGR mode instead of GR mode, and line 140 uses HPLOT instead of PLOT.


I don't have our original Franklin ACE 1000 anymore, or an original Apple II computer, but at least I can return to old school programming whenever I like by using an emulator.