Monday, June 27, 2016

Can't make it to GUADEC this year

I loved attending the GNOME Users And Developers European Conference (GUADEC). I want to go back, but it's hard to get away for such a long trip.

This year is especially tough. I started a new job in late December, as CIO in government. The new position comes with new responsibilities. I occasionally present in front of our Board, or to the County Manager, or to the Senior Leadership Team.

This year, I have a Board presentation at work immediately before GUADEC, and a vacation with family planned immediately after. So I'm unable to attend GUADEC this year. Sorry.

But I am looking forward to LAS GNOME. I even submitted a conference presentation about our usability testing for Outreachy. I hope to see you there!

Moving to the project phase in Outreachy

I want to start this week by taking a step back in review.

When we worked together during Ciarrai's, Diana's, and Renata's applications to Outreachy, I would have provided the same schedule to everyone. This is the schedule template we used in previous cycles​:
original timeline, OPW
What is usability
Scenarios and tasks
Design patterns
Review usability test
How to display results
Perform usability test
Write results
​That was a 14 week schedule, transitioning out of the "research" phase at the end of week 3, although some research in week 4 as we prepared the usability test.

I recently drafted an updated schedule for our work, so we can plan the weeks ahead. Our internship period is May 23–August 23, so that's 14 weeks. This updated schedule includes the dates for each topic:
updated timeline, Outreachy
What is usability
Scenario tasks
Decide project focus
Design patterns
Review usability test
Perform usability test
Write results
I've coded the research phase in blue, and the usability testing phase in red.

As you can see, we moved pretty quickly through the research phase, learning about "What is usability," different ways to test usability, personas, scenarios, and scenario tasks. And Ciarrai, Diana, and Renata have done very well here.

We've taken the last week to settle into a project focus, and figure out who wants to do what. And today, we are officially starting the usability testing phase!

We are planing three usability testing projects for GNOME:

1. Paper prototype test of the new Settings app (Ciarrai)
This test will require using a paper mock-up of the new Settings app. The usability test with a paper prototype can be very similar to a traditional usability test with a final product. With the paper prototype test, you'll need to be careful about the test design. We can go over this in more detail individually. Collecting data and performing analysis (heat map) will likely be similar to a traditional usability test, although we'll probably modify the analysis somewhat so we can uncover themes.
2. Traditional usability test of other ongoing work in GNOME (Renata)
This is basically the same usability test you performed as your initial contribution. Not much new to learn here. Similar to the paper prototype test, you'll build up your test design by starting with an analysis of design patterns and features, matching the patterns/features of interest to your scenario tasks. Data and analysis (heat map) is just as you exercised during your initial contribution, so this should be fairly straightforward.
3. A "user experience" of a user's first exposure to GNOME (Diana)
This is a bit different from what the above usability tests. As you learned in our first week, "usability" is different from "user experience," although they are related ideas. The "first experience" test will involve observing testers as they boot a computer running Linux, and login using a fresh account, so they go through the whole "welcome" GNOME experience. The testers will have some time to explore the desktop and applications, using scenarios and scenario tasks you provide them as a guide. The data will come from your observations and a brief interview with testers. Analysis will be identification of themes uncovered in the test, and the testers' self-reported engagement, connection and response to GNOME.

We plan to take the next two weeks to figure out the details on each of the usability tests. For a traditional usability test, this will include comparing the design patterns and other areas of GNOME that we wish to investigate. For the first experience, this may include considering the areas of GNOME that impress an experience on the user. In all tests, we'll also use the next two weeks to start building usability tests. I encourage you to follow Ciarrai's, Diana's, and Renata's blogs for more updates.

image: Outreachy

Monday, June 20, 2016

Wrapping up scenario tasks

Great work from Renata, Diana and Ciarrai on scenario tasks this week! Scenario tasks are an important part of any formal usability test. A well written scenario task sets a brief context, then asks the tester to do something specific. The goal of the scenario task should be clear enough that the tester will know when they have completed the task.

There's definitely an "art" to creating good scenario tasks. As Renata, Diana and Ciarrai wrote in their blogs this week, you need to be careful not to (accidentally) provide hints for how to complete the task. You need to balance enough information to make the scenario task clear, but not so much that the tester can only complete the task in one particular way. There are often multiple ways to do things in software. Let your testers find the way that works for them.
Diana wrote: "Phrase your scenario tasks without uncommon or unique words that appear on the screen. If you do, you turn the tasks into a simple game of word-finding."

Ciarrai wrote: "Language that doesn’t just mimic that which is used in the program will help avoid leading the user in performing the tasks. Testing whether the user can achieve the goal without direct word association can make a usability test more fruitful."

Renata wrote: "Avoid statements that may end up giving too much information. Instead of saying click“this”, you should leave the participant finish the task in order to see if that feature is intuitive. Also do not force the user to execute that task in a certain way, there are many ways to accomplish a task so let the user’s choose their way to use the interface."

In their research, Renata, Diana and Ciarrai also talked about how scenario tasks need to be realistic. There's no point in asking a tester to do something that a real person wouldn't do. That's why it was important to understand scenarios before we researched scenario tasks. Understanding how and why a real person would use the software to do real tasks is invaluable in creating realistic scenario tasks.

And scenario tasks need to be written using the language that your testers would normally use. Avoid using very technical words if your users wouldn't be technical. You might use technical words and phrases if you were building a usability test for a programmer's IDE and Debugger, but you wouldn't use technical words and phrases for a general desktop environment like GNOME. It's all about finding the right balance and "voice" in your scenario tasks.

If you haven't read their blog posts this week, you should read Diana's post for the Dilbert cartoon she included. This one reminds me of a quote from The Hitchhiker’s Guide to the Galaxy (radio program, TV mini-series, then books). One of the characters says this after stealing a spaceship that has a rather monochromatic color scheme:
‘It’s the wild colour scheme that freaks me out,’ said Zaphod, whose love affair with the ship had lasted almost three minutes into the flight. ‘Every time you try and operate these weird black controls that are labeled in black on a black background, a little black light lights up in black to let you know you’ve done it.’
~Zaphod Beeblebrox, The Restaurant at the End of the Universe
While the black-on-black color scheme might look impressive, the interface will be invisible in normal light (from Dilbert).
This week wraps up our "research" phase for the usability testing project. We will now transition to applying our new knowledge to an actual usability test. I'll talk more about that in my next update, probably in a few days.
image: Outreachy

Thursday, June 16, 2016

Making pie charts

This isn't related to "open source software and usability" but I thought this was neat so I wanted to share it here.

On my Coaching Buttons blog, I'm planning a new article about how we divide our time between Lead, Manage and Do tasks. For example, "Lead" is about setting a direction, getting people on board with a vision, and generally providing leadership. You can lead at all levels in an organization. "Manage" is the day-to-day of keeping things running, coordinating people and processes, and allocating resources and budgets. And "Do" are the hands-on tasks like coding, analyzing data, or responding to issues. Email and writing reports can also be "Do" tasks.

The goal of the "Lead-Manage-Do" project is to focus your time appropriately. Think of your available time as a "pie," and how you divide your time as "slices" of the pie. That's your time for the week. You can't make the pie any bigger, unless you want to work through the weekend. How do you spend this available time? I'm looking to build on my Lead-Manage-Do since I've moved to my new role.

My new post will require pie charts to illustrate how I spend my time. I could generate a few quick pie charts in a spreadsheet and post them to my blog. That's what I did in my previous blog posts on this topic. But lately, I have tried to use more SVG graphics on my personal websites, due to the reduced size and greater flexibility. So I wondered if I could create a pie chart using SVG.

When I searched for examples in creating pie charts in SVG, many sources pointed me to Designing Flexible, Maintainable Pie Charts With CSS And SVG by Lea Verou. It's an interesting article. But I found the article's method limiting, using one slice in a larger pie. My "Lead-Manage-Do" charts need a balance of three pie slices. There's a section at the end using a conical gradient method that might do the job, but I knew there had to be a cleaner way to do it.

And there is: SVG arcs.

Mozilla Developer Network has a great article on SVG Paths. Skip to the end where they talk about arcs. The general syntax for an arc is:
A rx ry x_axis_rotation large_arc_flag sweep_flag x y
Arcs are tricky because the arc can take different paths (clockwise or counterclockwise) and they can go "in" or "out." And if your arc is based on an oval, you can rotate the oval. Hence the additional arguments. The MDN article explains the large arc flag and the sweep flag:
The first argument is the large-arc-flag. It simply determines if the arc should be greater than or less than 180 degrees; in the end, this flag determines which direction the arc will travel around a given circle. The second argument is the sweep-flag. It determines if the arc should begin moving at negative angles or positive ones, which essentially picks which of the two circles you will travel around.
You can use the SVG arc to create a neat pie wedge.

If you haven't used SVG before, think of SVG as a form of Turtle graphics (I suppose this analogy only helps if you have used Turtle graphics). You define a shape by moving to (M) a starting x,y position, then you can draw lines (L) or arcs (A) or other elements as needed. The "Close Path" command (Z) automatically closes the shape by connecting a "line" from the ending position back to the starting position.

And with that, we can define a pie wedge! Let's define a box 400×400. A circle in this box would be centered at 200,200. Since it's a circle, I don't need an x axis rotation, so I'll set that to zero. By default, the SVG will have 0,0 in the upper-left corner.

To draw a pie wedge, move (M) to a starting point on the circle's edge, then draw an arc defined by that circle. To close the pie wedge, create a line back to the circle's center at 200,200. Since I'm using absolute coordinates, use uppercase M, A, and L. Here's the code:
<path d="M 400 200 A 200 200 0 0 0 200 0 L 200 200 Z" style="fill: green;">
A simple example:

That defines a green wedge from 400,200 to 200,0 (0 degrees to 90 degrees) and a line back to the center of the circle at 200,200. The Z command automatically closes the shape by projecting a line from the end (200,200) to the start (400,200). The above drawing also provides a pink circle with red center dot and a red outline so you can see the circle that defines the arc. The arc has x radius 200 and y radius 200.

To help me create multiple pie wedges that can start and stop at any angle, I needed a little extra help. To run the math, I created a simple spreadsheet where I define the starting θ and ending θ, both in degrees, and the spreadsheet converts that to radians and calculates appropriate x,y values based on the size of the pie chart I want to make. For a circle this size, two decimal places is more than enough precision. (For a larger SVG image, you might use only integer coordinates. For a smaller SVG image, you might need another decimal place.)

You can easily work the math out on your own. An x,y coordinate on the edge of a circle is defined by rcosθ and rsinθ. With that, it's trivial to work out the start and stop coordinates for the arc. Just remember 0,0 is at the top left and positive values are right and down. Here's some pseudo-code for the x,y of any point on a circle of radius r, given an angle θ:
x = xcenter + r cosθ
y = ycenter - r sinθ

Also remember that the large arc flag "determines if the arc should be greater than or less than 180 degrees" (from the MDN article). So the limitation here is that my wedges need to be less than 180 degrees if I use a zero large arc flag.

And you can take a shortcut. If you first define a circle behind the wedges, you really only need to create n–1 wedges. This is especially helpful if you know one of the wedges will be larger than 180 degrees.

Putting it all together, you have a 2D pie chart in SVG:

The SVG code first draws a background circle (orange), then defines a red wedge from 30 to 110 degrees, and a blue wedge from 110 to 280 degrees. Visually, this leaves an orange wedge from 280 to 30 degrees.
<svg height="400" width="400">
<circle cx="200" cy="200" fill="orange" r="200"></circle>
<path d="M 373.21 100.02 A 200 200 0 0 0 131.66 12.04 L 200 200 Z" style="fill: firebrick;"></path>
<path d="M 131.66 12.04 A 200 200 0 0 0 234.55 396.99 L 200 200 Z" style="fill: royalblue;"></path>
You can also apply other styles to create outlines, etc. on the pie chart. But I'll leave that to you.

Wednesday, June 15, 2016

Learning about scenario tasks

For the internship, we have been following a schedule where we research topics about usability testing. After that "research" phase, we'll start building our usability tests. And we are almost finished with that "research" phase.

Please follow along as we start our new research topic: scenario tasks!

In this segment, we will examine scenario tasks. We started to explore this topic somewhat during last week's research on scenarios. Scenarios are similar to scenario tasks, but they are not the same. A scenario describes how a real person would use the software. By contrast, a scenario task is given to a tester during a usability test to have them perform a task representative of how real people use the software.

The scenario task must represent what users would actually need to do with the software, what users are looking for in the software (therefore, they follow from personas and scenarios). A well-crafted scenario task will help you to uncover usability issues more effectively.

I've shared a few resources that should help in this week's research:
  1. Usability testing: how do we design effective tasks (Zhao, 2013)
  2. Seven Tips For Writing Usability Task Scenarios (Sauro, 2013)
  3. Turn User Goals into Task Scenarios for Usability Testing (Nielsen Norman Group, 2014)
Before Renata, Diana and Ciarrai were accepted to the Outreachy internship, they each had to present a "first contribution" in usability testing. For this first contribution, I asked them to find ten scenario tasks used in other GNOME usability tests, and perform their own usability tests with a few testers.

As part of this week's research on scenario tasks, Renata, Diana and Ciarrai will also reflect on their first contributions, and write about using these scenario tasks. Which scenario tasks worked well? Were there any scenario tasks that you would choose to improve?

Starting next week, we will transition to building our usability tests!
image: Outreachy

Tuesday, June 14, 2016

Are you planning to attend LAS GNOME?

I loved attending the GNOME Users And Developers European Conference (GUADEC). I want to go back, but travel to Europe is a bit expensive. And it's hard to get away for such a long trip. So I'm not to make it for this year's GUADEC.

That's why I was excited to see a similar US-based conference this year: the Libre Application Summit—hosted by GNOME (LAS GNOME). The conference will be held from September 19–23 in Portland, Oregon.

They just posted a call for presentations. I'm not affiliated with LAS GNOME, but I know this is a new conference and I want to see it succeed. So I'm sharing this news to raise awareness. Consider submitting a presentation on your favorite topic: ecosystem, platforms, distributions, development, or whatever else you are working on. Proposals are due July 15th.

I submitted a presentation on usability testing. I am looking forward to our GNOME usability testing this summer as part of Outreachy, and I plan to share our usability test results. I'll also talk about usability testing in general, and how developers can apply usability testing to their own programs.

I hope to see you at LAS GNOME in Septemeber!
image: LAS GNOME

Sunday, June 12, 2016

Learning about scenarios

Ciarrai, Diana and Renata have been writing about their research on scenarios!

Scenarios follow from personas (see week 2). If personas tell us who uses the software, the scenarios tell us how and why they use the software. So a sample scenario is a short description (usually a paragraph) of why this persona is using the software.

Renata said, “Scenarios describe how users accomplish their tasks in a specific context and also provide examples of usage. Scenario is a description of one or more users interacting with with the system under specified conditions.”

Ciarrrai found this great quote from InfoDesign about scenarios: “A scenario is a description of a person’s interaction with a system. Scenarios help focus design efforts on the user’s requirements, which are distinct from technical or business requirements.”

GNOME is a desktop system, so the scenario is likely going to be about how they launch applications and open files from within GNOME. And that’s a good scenario for a desktop system. That’s how people use GNOME.

Or if you’re writing a scenario that involves some GNOME applications, such as Notes to jot down a few reminders or gedit to edit a file, those applications are certainly part of the GNOME system. So you might have a scenario about how your persona needs to make a reminder using the Notes application.

Renata, Ciarrai and Diana are now writing some sample scenarios about GNOME.

We also got a preview of scenario tasks. Scenarios are similar to scenario tasks, but they are not the same. We’ll learn more about scenario tasks next week.

There’s an important distinction between scenarios and scenario tasks. A scenario describes how a real person would use the software. A scenario task is something you give a tester during a usability test, and the scenario task is representative of what real people would actually do in the software. So we’re learning about scenarios this week to make it easier to create scenario tasks next week.

Scenarios help you to understand the goals for using the software. Diana commented about scenario tasks: “Once you’ve figured out what the users’ goals are, you need to formulate task scenarios that are appropriate for usability testing. Scenarios specify how users carry out their tasks by providing some context and supplying information the user needs to know, but doesn’t.”

Renata added this about scenario tasks: “A scenario task is a set of steps that the participant needs to perform to accomplish a goal. Once you’ve figured out what tasks you want to test, you’ll need to formulate some realistic task scenarios for participants to accomplish. In short, a task scenario is the action that you ask the participant to take by providing the necessary details to accomplish that task.”
image: Outreachy

Wednesday, June 8, 2016

Let's start week 3

Having learned about personas and written some sample personas, the next step toward usability testing is to document the scenarios under which these personas typically use the program.

Scenarios are key to performing a good usability test. The success of your usability test depends on how well you understand how, where, and why the program will be used. And in turn, this depends on how well you understand this depends on the completeness of your personas.

This week, let's examine scenarios. What are scenarios? I've linked to a few resources that should help in this week's research:
  1. > Scenarios []
  2. > Task Analysis []
  3. Scenarios of use (Use cases) [UsabilityNet 2006]
  4. Scenario of Use [Bevan 2011]
  5. Information & Design > Scenarios [Gaffney 2000]
Similar to week 2, I've asked Diana, Ciarrai and Renata to write a few sample scenarios, just as a practice exercise. Writing these sample scenarios will help us next week when we research scenario tasks.
Interested in what's coming up? Week 4 will be scenario tasks. Then in week 5, we'll finally take what we've learned and compare it to how GNOME gets used, doing some additional analysis to understand the design patterns and the aspects of GNOME that we want to include in the usability test. That should be a really engaging week!
image: Outreachy

Wrapping up week 2

Diana, Renata and Ciarrai have posted some great work on personas, and recently wrote some sample GNOME personas. They did a very complete job here. I feel like I have a good understanding of all these sample personas.

Personas are an important part of any design process. Whether you are trying to figure out the user interface or deciding what new functionality to add, personas can help you connect to the users.

Diana wrote this about personas: Personas focus on user goals, current behavior, and pain points. They are based on field research and real people. They describe why people do what they do in attempt to help everyone involved in designing and building a product understand and remember the end user throughout the entire product development process.

And Renata added: Personas concentrate on what a user does, what frustrates the user, and what gives the user satisfaction, they bring the “user” to life by providing a specific target for designing a final product and creating software with a specific, not generic, user in mind. Some teams use them as a reminder throughout the development life cycle about what’s important to users.

Personas allow you to talk about changes to the interface based on how those changes benefit users. Rather than saying “I want to add X feature because that would be cool” you can say “I want to add X feature because that helps users like the ‘Mark’ and ‘Sophia’ personas.”

Ciarrai also reminded us: With well researched personas in place, development will run much smoother. Designers will have a better sense of goals for the look and feel of the program. Developers will build better interfaces. Many questions get answered earlier and more efficiently when we have personas to help motivate and focus development work.

We took a few extra days to write the sample personas, since that was added later. As we get further into the internship, we'll see if that adjusts the overall schedule very much.

I'll post the week 3 research topic very soon.
image: Outreachy

Sunday, June 5, 2016

Week 2 in usability testing continues

I just wanted to say Diana, Renata, and Ciarrai have done a great job in summarizing personas and why they are important in usability testing. I encourage you to follow their blogs, especially if you are interested in how "usability testing" works and what goes into it.

Personas are an important part of any design process. Whether you are trying to figure out the user interface or deciding what new functionality to add, personas can help you connect to the users.

Personas allow you to talk about changes to the interface based on how those changes benefit users. Rather than saying “I want to add X feature because that would be cool” you can say “I want to add X feature because that helps users like the ‘Mark’ and ‘Sophia’ personas.”

As part of the Outreachy project, we are working with the GNOME Design team (Allan and Jakub). It's really great to have this connection with GNOME. They also share comments with us about GNOME design, which was very helpful in week 2 when we learned about who uses GNOME.

Allan said to us in his email: “GNOME is currently used by a wide range of people. There are people who set up computers for their families with GNOME, where family members are really beginners and will often not know what GNOME is. At the other end of the spectrum, there are technicians using GNOME in big companies, and of course software developers who are very technical and expert." So the potential users spans a wide range. And "When one of our designers set out to design GNOME 3, he stated that the goal was to design ‘a self-teaching interface for beginners, and an efficient interface for advanced users, but optimize for intermediates’.”

We're taking a few extra days to write some sample personas for GNOME. Ciarrai has written one sample persona, here. This is written in the more common “​Table” format, although formatted a little differently (tables are awkward in blogs). suggests the “​Table” format is “Best for designers who need an easy way to compare designs to user needs” and I agree. If you need to compare a set of sample personas, the table makes it easy to scan the list. If you don’t need much detail, you can “sketch out” a few sample personas for what they call a “Quick and Dirty” approach, and I’ve used that method too. has a similar “table” formatted sample persona, here.

You can also find sample personas written by two previous usability testing interns for Outreachy & GNOME Outreach Program for Women, here:

Writing the sample personas might slip the internship schedule by a few days, but I think it's good to be flexible. Internships are supposed to be flexible anyway.

Expect “week 3” to start later this week. Our topic will be Scenarios.
image: Outreachy