Tuesday, April 9, 2019

March Madness brackets this year

I used to work in higher ed, and folks in my office followed the NCAA (National Collegiate Athletic Association) basketball games every year. If you aren't in the US, this is called "March Madness" because the games start in March.

To some, it's a big deal to follow the teams and predict how the playoffs will run. NCAA uses a single-elimination playoff series, called an NCAA "bracket." You can fill in your favorite teams to complete a bracket, to predict how you think the games will run.

I don't follow basketball, but I liked to participate in the brackets every year. Typically, you'd put down some small amount of cash in an office pool and the person with the best-performing bracket would "win."

Because I don't follow the teams, I can't predict how each might do in the playoffs. I'd like to take part in the fun, maybe put my five dollars into the office pool, 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 program to do it for me. Over time, I've improved the script.

The basic idea is to use the "seed" values as an estimate for performance. March Madness covers four regions, each with sixteen teams with seed values 1–16 that are initially assigned based on some calculation of performance that year. While each of the sixteen teams are excellent (hey, they made it to the playoffs) my script makes the simple assumption that a "rank 1" team will usually outperform a "rank 16" team, but a "rank 7" team will be about evenly matched against a "rank 8" team.

Read the articles for details. The short version is you build an n-sided virtual "die" and "roll" it to predict each game's outcome. Each run of the script is essentially random, but there's a definite preference towards the higher-ranked teams.

I ran my March Madness script when the NCAA posted this year's brackets, and have been tracking the results. And I was surprised to see that one of my teams made it all the way to the final playoff. Go Texas Tech! But alas, my script didn't predict the correct ultimate winner.

In the first round of the NCAA March Madness, you start with teams 1–16 in four regions, so that's 64 teams that compete in 32 games. My script correctly guessed 4 contests in the Midwest region (NC, Aub, OH St, and Woff), 6 contests in the East region (Duke, VA Tech, Maryl, LSU, Minn, and Mich St), 5 in the West region (Gon, FL St, Texas Tech, Fla, and Mich), and 3 in the South region (Virg, Purd, and Tenn). So that's 4+6+5+3=18 for me in round one.

In the second round, my script carried only 1 team in the Midwest (Aub), 1 team in the East region (LSU), 4 teams in the West region (Gon, FL St, Texas Tech, and Mich), and 1 team in the South region (Purd). That means 1+1+4+1=7 for me in round two.

At the third round, things really fell apart. My script correctly guessed none in the Midwest and East regions, 1 in the West region (Texas Tech), and none in the South region. A total of 1 in round three ("Sweet Sixteen").

My script predicted that Texas Tech would go all the way in the West region. I had to make my own guesses for the Final Four (I guessed that rank 3 Texas Tech would win over rank 8 UT St, and rank 7 Cin would win over rank 8 VCU) and the national championship (again, using simple comparison to guess that rank 3 Texas Tech would defeat rank 7 Cin) to complete my NCAA bracket. That left me to follow Texas Tech throughout the rest of March Madness. And they did very well, succeeding in every contest except the final game, where Texas Tech lost to Virginia 85 to 77 in overtime. But that means my script correctly predicted 1 game in each of round four ("Elite Eight") and round five ("Final Four").

Following the standard method for how to score March Madness brackets, each round has 320 possible points. In round one, assign 10 points for each correctly selected outcome. In round two, assign 20 points for each correct outcome. And so on, double the possible points at each round. From that, the math is pretty simple.
round one:18 ×10 =180
round two:7 ×20 =140
round three:1 ×40 =40
round four:1 ×80 =80
round five:1 ×160 =160
round six:0 ×320 =0
That's a pretty good run! I've been tracking my scores over the last few years, and my total score last year was 390 points, but there were a lot of upsets last year so no one's brackets did very well anyway. The previous year's script (with a bug) scored 530 in one instance, and 490 in another instance. So 600 points this year is excellent compared to the previous years.

I should add that I don't consider my script a replacement for a human in filling out NCAA brackets. My script just makes guesses, so each run is different. This run happened to do well. But it is enough that I get invested in the March Madness games. And that's fun for me.

Did you track March Madness this year? How did you do with your bracket?

Saturday, April 6, 2019

Dropping out of usability testing for a while

Hi everyone. I wanted to let you know that I'm dropping out of usability testing for a while. I think we did great work as part of the Outreachy internship, and I'm glad of the opportunity to mentor usability testing—but I have an update:

I've started my own company! IT Mentor Group is an IT Executive Consulting company to help Chief Information Officers and other IT Leaders with strategic planning, turnaround situations, and organizational development. I also provide "IT Leadership Development" training to help grow emerging IT Leaders, and "Essential IT Management" training to help current managers hone their skills.

As you can imagine, starting my own company takes a lot of time. So I need to focus on that for a while. I've dropped off the Outreachy email lists. I would like to mentor usability testing again but I expect to be busy for at least a year while I grow my new business. I just won't have time to commit to usability testing during that time.

In the meantime, I'm always happy to answer questions and offer advice about usability testing. Feel free to email me, but please understand if it takes a little while to get back to you.

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.