Sunday, February 26, 2017

How to get started in open source software

A friend pointed me to the Open Source Guides website, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. I thought it was very interesting for new contributors, so I thought I'd share it here.

The website provides lots of information about starting or joining an open source project. There's lots to read, but I hope that doesn't seem like too much for people interested in getting started in open source software. Open Source Guides has several sections for new developers:
  1. How to Contribute to Open Source
  2. Starting an Open Source Pro ject
  3. Finding Users For Your Project
  4. Building Welcoming Communities
  5. Best Practices for Maintainers
  6. Leadership and Governance
  7. Getting Paid for Open Source Work
  8. Your Code of Conduct
  9. Open Source Metrics
  10. The Legal Side of Open Source
I'm not connected with Open Source Guides, but I think it's a great idea!

Of course, there are other ways to learn about open source software, how to get involved and how to start your own project. Eric Raymond's essay series The Cathedral and the Bazaar are the typical go-to examples about open source software. Along similar lines, Opensource.com has a very brief primer on open source contributor guidelines. And there are countless other articles and books I could mention here, including a few articles written by me.

But I'm interested in the open source software community, and anything that helps new folks get started in open source software will help the community grow. So if you're interested in getting involved in open source software, I encourage you to read the Open Source Guides.

Friday, February 24, 2017

Top open source projects

TechRadar recently posted an article about "The best open source software 2017" where they list a few of their favorite open source software projects. It's really hard for an open source software project to become popular if it has poor usability—so I thought I'd add a few quick comments of my own about each.

Here you go:

The best open source office software: LibreOffice


LibreOffice hasn't changed its user interface very substantially for a very long time. In the recent LibreOffice 5.3 release, they introduced a new interface option, which they call the MUFFIN (My User Friendly Flexible INterface).

The new interface has several modes, including Single Toolbar, Sidebar, and Notebookbar. The last mode, Notebookbar, is interesting. 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 Notebookbar setting.

To comment on the new interface: 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.

The best open source photo editor: GIMP


I use GIMP at home for a lot of projects. Most often, I use GIMP to create and edit images for my websites, including the FreeDOS Project website. Although we've recently turned to SVG where possible on the FreeDOS website, for years all our graphics were made in the GIMP.

A few years ago, I asked readers to suggest programs that have good usability (I also solicited feedback through colleagues via their blogs and their readers). Many people talked about GIMP, the open source graphics program (very similar to Photoshop). There were some strong statements on either side: About half said it had good usability, and about half said it had bad usability.

In following up, it seemed that two types of users thought GIMP had poor usability: Those who used Photoshop a lot, such as professional graphics editors or photographers. Those who never used Photoshop, and only tried GIMP because they needed a graphics program.

So GIMP is an interesting case. It's an example of mimicking another program perhaps too well, but (necessarily) not perfectly. GIMP has good usability if you have used Photoshop occasionally, but not if you are an expert in Photoshop, and not if you are a complete Photoshop novice.

The best open source media player: VLC


I haven't used VLC, part of the VideoLAN project, in a few years. I just don't watch movies on my computer. But looking at the screenshots I see today, I can see VLC has made major strides in ease of use.

The menus seem obvious, and the buttons are plain and simple. There isn't much decoration to the application (it doesn't need it) yet it seems polished. Good job!

The best open source video editor: Shotcut


This is a new project for me. I have recorded a few YouTube videos for my private channel, but they're all very simple: just me doing a demo of something (usually related to FreeDOS, such as how to install FreeDOS.) Because my videos aren't very complicated, I just use the YouTube editor to "trim" the start and end of my videos.

Shotcut seems quite complicated to me, at first glance. Even TechRadar seems to agree, commenting "It might look a little stark at first, but add some of the optional toolbars and you'll soon have its most powerful and useful features your your fingertips."

I'm probably not the right audience for Shotcut. Video is just not my interest area. And it's okay for a project to target a particular audience, if they are well suited to that audience.

The best open source audio editor: Audacity


I used Audacity many years ago, probably when it was still a young project. But even then, I remember Audacity as being fairly straightforward to use. For someone (like me) who occasionally wanted to edit a sound file, Audacity was easy to learn on my own. And the next time I used Audacity, perhaps weeks later, I quickly remembered the path to the features I needed.

Those two features (Learnability and Memorability) are two important features of good usability. We learn about this topic when I teach my online class about usability. The five key characteristics of Usability are: Learnability, Efficiency, Memorability, Error Rates, and Satisfaction. Although that last one is getting close to "User eXperience" ("UX") which is not the same as Usability.

The best open source web browser: Firefox


Firefox is an old web browser, but still feels fresh. I use Firefox on an almost daily basis (when I don't use Firefox, I'm usually in Google Chrome.)

I did usability testing on Firefox a few years ago, and found it does well in several areas:

Familiarity: Firefox tries to blend well with other applications on the same operating system. If you're using Linux, Firefox looks like other Linux applications. When you're on a Mac, Firefox looks like a Mac application. This is important, because UI lessons that you learn in one application will carry over to Firefox on the same platform.

Consistency: Features within Firefox are accessed in a similar way and perform in a similar way, so you aren't left feeling like the program is a mash of different coders.

Obviousness: When an action produces an obvious result, or clearly indicated success, users feel comfortable because they understand what the program is doing. They can see the result of their actions.

The best open source email client: Thunderbird


Maybe I shouldn't say this, but I haven't used a desktop email client in several years. I now use Gmail exclusively.

However, the last desktop email client I used was definitely Thunderbird. And I remember it being very nice. Sometimes I explored other desktop email programs like GNOME Evolution or Balsa, but I always came back to Thunderbird.

Like Firefox, Thunderbird integrated well into whatever system you use. Its features are self-consistent, and actions produce obvious results. This shouldn't be surprising, though. Thunderbird is originally a Mozilla project.

The best open source password manager: KeePass


Passwords are the keys to our digital lives. So much of what we do today is done online, via a multitude of accounts. With all those accounts, it can be tempting to re-use passwords across websites, but that's really bad for security; if a hacker gets your password on one website, they can use it to get your private information from other websites. To practice good security, you should use a different password on every website you use. And for that, you need a way to store and manage those passwords.

KeePass is an outstanding password manager. There are several password managers to choose from, but KeePass has been around a long time and is really solid. With KeePass, it's really easy to create new entries in the database, group similar entries together (email, shopping, social, etc.) and assign icons to them. And a key feature is generating random passwords. KeePass lets you create passwords of different lengths and complexity, and provides a helpful visual color guide (red, yellow, green) to suggest how "secure" your password is likely to be.

Monday, February 20, 2017

More about DOS colors

In a followup to my discussion about the readability of DOS applications, I wrote an explanation on the FreeDOS blog about why DOS has sixteen colors. That discussion seemed too detailed to include on my Open Source Software & Usability blog, but it was a good fit for the FreeDOS blog.

It's an interesting overview of how color came to be encoded on PC-compatible computers. The brief overview is this:

CGA, the Color/Graphics Adapter from the earlier PC-compatible computers, could mix red (R), green (G) and blue (B) colors. So that's eight colors, from 000 Black to 111 White.

Add an "intensifier" bit, and you have sixteen colors, eight colors from 0000 Black to 0111 White, and another eight colors from 1000 Bright Black to 1111 Bright White.

There's a bit more about the background and the bit-pattern to represent colors. Read the full article for more: Why DOS has sixteen colors

The readability of DOS applications

My recent article about how web pages are becoming hard to read had me wondering: I grew up with DOS, and I still work with DOS, so what's the readability of DOS applications?

Web pages are mostly black-on-white or dark-gray-on-white, but anyone who has used DOS will remember that most DOS applications were white-on-blue. Sure, the DOS command line was white-on-black, but almost every popular DOS application used white-on-blue. (It wasn't really "white" but we'll get there.) Do an image search for any DOS application from the 1980s and early 1990s, and you're almost guaranteed to yield a forest of white-on-blue images like these:

FreeDOS 1.2 install program

As Easy As, the shareware DOS spreadsheet

Free Point of Sale for DOS, by Dale Harris

DosZip, the file manager for DOS

FreeDOS EDIT

DOS is an old operating system. DOS stands for "Disk Operating System" and was designed to let you run applications. People like to think of DOS as being a command-line operating system, and while you could do manipulate file contents at the command prompt with a limited set of tools, DOS really didn't have the rich set of command-line tools like Unix and Linux enjoy. You mostly used the DOS command line to run different applications.

As an operating system interface, DOS was entirely text-based. It used BIOS services on your computer to do most of its work, including displaying text. With DOS, you had a color palette of sixteen colors, enumerated 0 (black) to F (bright white). But most users didn't know the 0–F codes, only the sixteen ANSI escape codes, divided into "normal" and "bright" modes. I've also included the RGB color representation of each:
NormalBright
30Black0,0,0Gray85,85,85
31Red170,0,0Bright Red255,85,85
32Green0,170,0Bright Green85,255,85
33Brown170,85,0Yellow255,255,85
34Blue0,0,170Bright Blue85,85,255
35Magenta170,0,170Bright Magenta255,85,255
36Cyan0,170,170Bright Cyan85,255,255
37White170,170,170Bright White255,255,255
You used these codes by loading an ANSI driver (called ANSI.SYS on MS-DOS, or NANSI.SYS on FreeDOS) and entering an ANSI escape sequence. Most people I know used the ANSI escape codes to make their DOS prompt more colorful, which you could do by using $E to represent an ESC character. For example, you could set red text with $E[31m or bright red text with $E[31;1m. Similarly, the range 40–47 represented background colors.

You may wonder about the brown/yellow line. That's not a typo; it wasn't really "yellow" and "bright yellow" although some references did call them that.

The general trend in the RGB color representations is the "normal" mode colors use 0 or 170, but "bright" mode colors replace 0 with 85 and 170 with 255.

If you have any familiarity with DOS, you should remember most applications using white-on-blue text. But how readable was this text? Using a Bash script to calculate contrast ratios of text, we can compute the readability of a few common color configurations from popular DOS applications.

White text on a blue background was generally considered (at the time) as easier to read, and prettier to look at, than plain white-on-black. And if you've sprung for that expensive monitor that can display colors, you want color. So white-on-blue quickly became a de facto standard.

Remember that DOS didn't support styling of text. You couldn't do italics or bold. Instead, applications such as word processors used colors to represent styles. Most text would be displayed as white-on-blue. Bold text was bright-white-on-blue, italics text was often green-on-blue or cyan-on-blue, and headings were often yellow-on-blue. Error messages might appear in white-on-red or black-on-red with the title in bright-white-on-red. Warnings might be black-on-brown or white-on-brown with yellow-on-brown titles. Status lines were frequently black-on-cyan or black-on-white.

Let's examine the contrast ratios of these color combinations:
White on Blue5.71
Bright White on Blue13.29
Yellow on Blue12.45
Green on Blue4.26
Cyan on Blue4.63
Black on Red2.70
White on Red3.33
Bright White on Red7.75
Black on Brown4.00
White on Brown2.25
Yellow on Brown4.91
Black on Cyan7.32
Black on White9.03
The W3C definition of the contrast ratio falls in the range 1 to 21 (typically written 1:1 or 21:1). The higher the contrast ratio, the more the text will stand out against the background. For example, black text on a white background has a contrast ratio of 21:1.

The W3C says body text should have a contrast ratio of at least 4.5:1, with headings at least 3:1. But that seems to be the bare minimum. The W3C also recommends at least 7:1 for body text and at least 4.5:1 for headings.

But it's also important to remember that DOS text was quite large, compared to today's standards. By default, DOS used an 80-column, 25-line display. Even on a modest 15-inch display (not unreasonable for the time) each character is around .15" [3.81mm] wide and .36" [9.144mm] high. That's quite large compared to today's websites that may use 11pt text. (Assuming your DPI is set correctly for your display, if 72pt is an inch, 11pt is about .152" [3.86mm] high.)

With text at that scale, I think that means the minimum contrast ratio for DOS applications can be somewhere between the W3C's recommendations for body text and heading text. Let's assume a round number of about 4:1.

So how do DOS applications stack up? Notice that white-on-blue is a very comfortable 5.71. Actually, in the above examples, all text on the blue background is quite readable. Other colors are quite clear, as well. Only black-on-red (2.70), white-on-red (3.33) and white-on-brown (2.25) fall below the recommended minimum of 4:1.

Let's examine the DOS application screenshots. The FreeDOS 1.2 installer uses black-on-white (9.03) for its main text, with list selection in yellow-on-blue (12.75). The FreeDOS EDIT program uses white-on-blue (5.71) for its main text, with its menu in black-on-white (9.03) and status bar in black-on-cyan (7.32).

The As Easy As spreadsheet used white-on-blue (5.71) for its main text and data enty line, with comments in green-on-blue (4.26) column and row labels in black-on-white (9.03) and black-on-white (9.03) status bar and white-on-black (9.03) hint line.

These are all very easy to read colors, even by today's standards. I'm not suggesting that websites switch to a white-on-blue color scheme, but it is interesting to note that even with a simple color palette, DOS applications were doing okay for readability.

Saturday, February 18, 2017

Calculating contrast ratios of text

In a comment on my other article about how web pages are becoming hard to read, Shaun referenced the W3C Web Content Accessibility Guidelines. They provide an algorithm to determine if your text meets minimum accessibility guidelines.

The W3C definition of the contrast ratio requires several calculations: given two colors, you first compute the relative luminance of each (L1 and L2) then calculate the contrast ratio. The ratio will fall in the range 1 to 21 (typically written 1:1 or 21:1). The higher the contrast ratio, the more the text will stand out against the background. For example, black text on a white background has a contrast ratio of 21:1.

The W3C says body text should have a contrast ratio of at least 4.5:1, with headings at least 3:1. But that seems to be the bare minimum. The W3C also recommends at least 7:1 for body text and at least 4.5:1 for headings.

Calculating this can be a chore, so it's best to automate it. Shaum implemented the algorithm in XSLT so he could test the various colors in websites. I created a similar implementation using Bash. It's a little ugly, but I thought I'd share it here:

First, you need a way to input colors. I wanted something that could interpret different representations of colors: in html and css, black is the same as #000 or #000000 or rgb(0,0,0). When evaluating the readability of my text, I might want to use any of these.

Fortunately, there's a neat tool in GNOME to provide that input. GNOME Zenity is a scripting tool to display GTK+ dialogs. It supports many modes to read input and display results. One of the input modes is a color selector, which you use this way:
zenity --color-selection
You can give it other options to set the window title and provide a default color. Zenity returns the selected color on standard output. You can even set a default color. So to present two dialogs, one to read the text color and another to read the background color, you simply do this:
color=$( zenity --title 'Set text color' --color-selection --color='black' )
background=$( zenity --title 'Set background color' --color-selection --color='white' )
Zenity returns values like rgb(255,140,0) and rgb(255,255,255), which is fortunate because the W3C calculation for luminance requires values in the range 0 to 255. I wrote a simple function to pull apart the RGB values. There are probably simpler ways to parse RGB, but a quick and easy way is to let awk split the values at the comma. That means a value like rgb(255,140,0) gets split into rgb(255 and 140 and 0) so the R value is a substring starting at the fifth character, G is the second element, and B is a substring up to the last parenthesis.

Once I have the RGB values, then I calculate the luminance using bc. The funky math with e() and l() are to get around a limitation in bc. Specifically, the formula requires a fractional power, and bc can only do integer powers. But if you follow the math, you can get there using e() and l():
function luminance()
{
        R=$( echo $1 | awk -F, '{print substr($1,5)}' )
        G=$( echo $1 | awk -F, '{print $2}' )
        B=$( echo $1 | awk -F, '{n=length($3); print substr($3,1,n-1)}' )

        echo "scale=4
rsrgb=$R/255
gsrgb=$G/255
bsrgb=$B/255
if ( rsrgb <= 0.03928 ) r = rsrgb/12.92 else r = e( 2.4 * l((rsrgb+0.055)/1.055) )
if ( gsrgb <= 0.03928 ) g = gsrgb/12.92 else g = e( 2.4 * l((gsrgb+0.055)/1.055) )
if ( bsrgb <= 0.03928 ) b = bsrgb/12.92 else b = e( 2.4 * l((bsrgb+0.055)/1.055) )
0.2126 * r + 0.7152 * g + 0.0722 * b" | bc -l
}
Once you have the luminance value of the text color and background color, you can compute the contrast ratio. The W3C formula to do this is quite simple, but requires knowing which is the lighter and darker colors. This is an extra step in bc. I wrote this Bash function to calculate the ratio based on two colors:
function contrast()
{
        echo "scale=2
if ( $1 > $2 ) { l1=$1; l2=$2 } else { l1=$2; l2=$1 }
(l1 + 0.05) / (l2 + 0.05)" | bc
}
With those functions, it's fairly straightforward to write a Bash script that reads two colors, then computes the contrast ratio. My script also uses Zenity to output the data:
#!/bin/sh

# read color and background color:

color=$( zenity --title 'Set text color' --color-selection --color='black' )
if [ $? -ne 0 ] ; then
        echo '** color canceled - assume black'
        color='rgb(0,0,0)'
fi

background=$( zenity --title 'Set background color' --color-selection --color='white' )
if [ $? -ne 0 ] ; then
        echo '** background canceled - assume white'
        background='rgb(255,255,255)'
fi

# compute luminance:

function luminance()
{

}

lum1=$( luminance $color )
lum2=$( luminance $background )

# compute contrast

function contrast()
{

}

rel=$( contrast $lum1 $lum2 )

# print results

( echo "Color is $color on $background"
echo "Contrast ratio is $rel"

if [ ${rel%.*} -ge 4 ] ; then
        echo "Ok for body text"
else
        echo "Not good for body text"
fi
if [ ${rel%.*} -ge 3 ] ; then
        echo "Ok for title text"
else
        echo "Not good for title text"
fi) | zenity --text-info --title='Contrast Ratio'
With this script, I have a handy way to calculate the contrast ratio of two colors: text color vs background color. For black text on a white background, the contrast ratio is 21.00, the most visible. The #333 dark gray on white has a contrast ratio of 12.66, which is fine. And the lighter #808080 gray on white has a contrast ratio of 3.95, too low for normal text but acceptable for large text like headings. Very light #ccc gray on white has a contrast ratio of 1.60, which is way too low.

Wednesday, February 15, 2017

I can't read your website

An article at Backchannel discusses an interesting trend in website design, and how the web became unreadable. It's a good read, but I'll summarize briefly:

Web pages are becoming too hard to read.

Put another way, a popular trend in web design is to use low-contrast text. Maybe that looks really cool, but it is also really hard to read. From the article: "I thought my eyesight was beginning to go. It turns out, I’m suffering from design."

I've noticed this trend too, and I do find it hard to read certain websites. Even this blog used to use a #333 dark grey text on white, just because I thought it looked better that way. And to be honest, others were doing it, so I did it too. But when I changed the text to black on white, I find my blog easier to read. I hope you do too.

The colors you choose for your text can affect the readability of your site. This is directly connected to usability.

Don't believe me? Here is a sample paragraph, repeated using different colors.

White on black:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Black on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
White on dark gray:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Dark grey on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
White on gray:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Gray on white:
Space: the final frontier. These are the voyages of the starship Enterprise. Its continuing mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
Which one do you find easiest to read?

Saturday, February 11, 2017

Experimenting with LibreOffice 5.3

I finally installed LibreOffice 5.3 to try it out. (This is actually version 5.3.0.3.) This version comes with a new interface called MUFFIN, which I wrote about as LibreOffice updating its user interface.

MUFFIN stands for My User Friendly Flexible INterface. Because someone clearly wanted that acronym to spell "MUFFIN." The new interface is still experimental, so you'll need to activate it through Settings→Advanced. When you restart LibreOffice, you can use the View menu to change modes. The new interface has several modes:
  1. Default
  2. Single Toolbar
  3. Sidebar
  4. Notebookbar
You can probably guess what the first three modes are about. These just tweak the interface in different ways, but I'd say it's still very "LibreOffice-y."

The last mode, Notebookbar, is interesting. 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 Notebookbar setting.

And in Notebookbar, you have a few options:
  1. Contextual groups
  2. Contextual single
  3. Tabbed
For me, "Tabbed" was the default when I activated Notebookbar. LibreOffice functions are divided into different tabs, which are clearly labelled. New tabs appear and disappear as suits the context of what you are working on. For example, if you insert a table, then when you go into the table, you get a "Table" tab, with different table-oriented actions like adding a new row or column.

Here are a few quick screenshots of the different tabs in Notebookbar. The "Home" tab is the default, so that's my first screenshot:








I haven't experimented too much with the other modes in Notebookbar, but "Contextual single" gives you a single action bar loaded with icons. I find it too busy, even though there's a lot of empty space in it. The single bar just "feels" too busy.

"Contextual groups" is closer to what you might think of as the "Microsoft Office Ribbon." Rather than adding new tabs to expose new functionality, the Notebookbar changes the content of the bar to add features as they are needed. If you insert a new table, then a table style menu appears. Exit the table, and the Notebookbar removes the table style menu in favor of other actions.

I'll need more time to explore and experiment with Notebookbar. My first impression is that I like it, and that I prefer tabs to contextual groups. I may share more on this blog as I continue to learn the new interface.

Friday, February 10, 2017

Microsoft's next Windows RT

Apologies for the brief diversion while I discuss Windows.

The Inquirer recently wrote about a future version of "Windows Cloud" that Microsoft will (one day) push its users to, probably whether or not you want it, just as they pushed their Windows 7 users to Windows 10. The difference is that the new operating system isn't really what you think of as "Windows." Instead, it's more like a Chromebook.

Now, I have no problem with the Google Chromebook. The Chromebook has a lot of great use-applications. The platform becomes irrelevant. Instead of a traditional operating system, you get a desktop and a web browser. All your applications are in "the Cloud," so Google's G Suite for your word processor, spreadsheet, and presentation software (think Word, Excel, and Powerpoint). Your email is in Gmail. And anything else you want to do is on a website somewhere. It's a great platform for a highly mobile world.

My wife has a Chromebook, and she loves it! In fact, she's thinking it's time to upgrade to the new Chromebook that's coming out soon.

I used to run a Chromebook when I was the campus CIO at a small university; I ran Linux on my desktop, but for meetings I usually brought my Chromebook.

At that same university, I envisioned that we would someday replace our meeting room PCs with Chromeboxes (the desktop version of a Chromebook) or Chromebits (a "micro" version of a Chromebox that plugs directly into an HDMI slot on a display). And we probably could have replaced many of our classroom PCs and general lab PCs with Chromeboxes or Chromebits; as a Google campus, all our apps were in Google's Cloud, so G Suite and Gmail.

Chromebooks ($200) and Chromeboxes ($150) and Chromebits ($100) are great Cloud-integrated systems at a low price. But that's the trick: the core assumption is that everything is in the Cloud. You don't run local applications on a Chromebook. You can't install applications on a Chromebook.

And now Microsoft seems set to move into this space, as well. The difference is that "Windows Cloud" (as they call it) will be a Cloud-integrated system with the "Windows" label on it. And people expect to install applications on "Windows."

The Inquirer article makes a great point here, both acknowledging why Microsoft would want to move to Windows Cloud, while questioning the wisdom of doing so:
There is a logic to Microsoft's entry into this market. Google's Chromebooks do well in certain markets, thanks to their low cost and zippy speeds on even low power processors, and Microsoft would naturally want to swipe some of that market.

However, despite improvements to Windows Universal Apps, explaining to the average consumer that they can't run their existing programs on their new computer is going to be as problematic as ever, and calling it "Windows 10" is going to mess with people's heads, as quite clearly, it isn't.

It feels like Microsoft are missing the point. If you buy a Chromebook, you know what you are getting. But if you buy a Windows machine, you have 30 years of heritage and expectation attached to the brand and people aren't going to be happy if you deliver a new version with less.
That last paragraph says it all. I think if Microsoft wanted to do a "Cloud-integrated" system like this, it would be better to avoid the "Windows" name. Maybe adopt the "Surface" name, like "Surface Cloud." Or leverage the "Edge" web browser name, and call it the "Edgebook" or something along those lines. At least then, users would carry different expectations to the new product.

Maybe this is a signal that it's time for Microsoft to retire the "Windows" label. Sure, Microsoft probably does want to shift it's operating system into the Cloud (whether or not that's a good thing, I'll leave that to you) but keeping the "Windows" label will hold them back. Learn from the disaster of "Windows RT" where users quickly discovered that while it looked like Windows and felt like Windows, you couldn't install "Windows" applications on it. With a new name, Microsoft can shift user expectations.