Fedora Design Team Planet

Flock Cod Registration Form Design

Posted by Máirín Duffy on April 25, 2017 10:00 PM

Flock logo (plain)

We’re prepping the regcfp site for Flock to open up registrations and CFP for Flock. As a number of changes are underfoot for this year’s Flock compared to previous Flocks, we’ve needed to change up the registration form accordingly. (For those interested, the discussion has been taking place on the flock-planning list).

This is a second draft of those screens after the first round of feedback. The first screen is going to spoil the surprises herein, hopefully.

First screen – change announcements, basic details

On the first screen, we announce a few changes that will be taking place at this year’s Flock. The most notable one is that we’ll now have partial Flock funding available, in an attempt to fund as many Fedora volunteers as possible to enable them to come to Flock. Another change is the addition of a nominal (~$25 USD) registration fee. We had an unusually high number of no-shows at the last Flock, which cost us funding that could have been used to bring more people to Flock. This registration fee is meant to discourage no-shows and enable more folks to come.

Flock registration mockup.

Second screen – social details, personal requirements

This is the screen where you can fill out your badge details as well as indicate your personal requirements (T-shirt size, dietary preferences/restrictions, etc.)

Second Flock registration screen - personal details for badge and prefs (dietary, etc.)

Third screen – no funding needed

So depending, the next section may be split into a separate form or be a conditional based on whether or not the registrant is requesting funding. The reason we would want to split funding requests into a separate form is that applicants will need to do some research into cost estimates for their travel, and that could take some time, and we don’t want the form to time out while that’s going on.

Anyhow, this is what this page of the form looks like if you don’t need funding. We offer an opportunity to help out other attendees to those folks who don’t need funding here.

Third screen – travel details

This is the travel details page for those seeking financial assistance; it’s rather long, as we’ve many travel options, domestic and international.

Fourth screen – funding request review

This is a summary of the total funding request cost as well as the breakdown of partial funding options. I’d really like to hear your feedback on this, if it’s confusing or if it makes sense. Are there too many partial options?

mockup providing partial funding options

Final screen – summary

This screen is just a summary of everything submitted as well as information about next steps.

final screen - registration summary and next steps

What do you think?

Do these seem to make sense? Any confusion or issues come up as you were reading through them? Please let me know. You can drop a comment or join the convo on flock-planning.


(Update: Changed the language of the first questions in both of the 3rd screens; there were confusing double-negatives pointed out by Rebecca Fernandez. Thanks for the help!)

Flock Cod Logo Ideas

Posted by Máirín Duffy on April 18, 2017 09:58 PM

Flock logo (plain)

Ryan Lerch put together an initial cut at a Flock 2017 logo and website design (flock2017-WIP branch of fedora-websites). It was an initial cut he offered for me to play with; in trying to work on some logistics for Flock to make sure things happen on time I felt locking in on a final logo design would be helpful at this point.

Here is the initial cut of the top part of the website with the first draft logo:

Overall, this is very Cape Cod. Ryan created a beautiful piece of work in the landscape illustration and the overall palette. Honestly, this would work fine as-is, but there were a few points of critique for the logo specifically that I decided to explore –

  • There weren’t any standard Fedora fonts in it; I considered at least the date text could be in one of the standard Fedora fonts to tie back to Fedora / Flock. The standard ‘Flock’ logotype wasn’t used either; generally we try to keep stuff with logotypes in that logotype (if anything, so it seems more official.)
  • The color palette is excellent and evocative of Cape Cod, but maybe some Fedora accent colors could tie it into the broader Fedora look and feel and make it seem more like part of the family.
  • The hierarchy of the logo is very “Cape Cod”-centric and my gut told me that “Flock” should be primary and “Cape Cod” should be subordinate to that.
  • Some helpful nautically-experienced folks in the broader community (particularly Pat David) pointed out the knot wasn’t tied quite correctly.

So here were the first couple of iterations I played with (B,C) based on Ryan’s design (A), but trying to take into account the critique / ideas above, with an illustration I created of the Lewis Bay lighthouse (the closest to the conference site):

I posted this to Twitter and Mastodon, and got a ton of very useful feedback. The main points I took away:

  • The seagulls probably complicate things too much – ditch ’em.
  • The Fedora logo was liked.
  • There seemed to be a preference for having the full dates for the conference in the logo.
  • The lighthouse beams in C were sloppily / badly aligned… 🙂 I knew this and was lazy and posted it anyway.
  • Some folks liked the dark blue ones because it was a Fedora color, some folks felt A’s color palette was more “Cape Cod” like.
  • At least a couple folks felt C was reminiscent of a nuclear symbol.
  • The simplicity / cleanness of A was admired.

So here’s the next round; things I tried:

  • Took a position on the hierarchy and placed ‘Flock’ above ‘Cape Cod’ in the general hierarchy in the logo.
  • Standardized all non-Flock logotype fonts on Montserrat, which is a standard Fedora brand font.
  • Shifted to original color palette from A.
  • Properly aligned lighthosue lights.
  • Added full dates to every mockup.
  • Corrected knot tie.

One more round, based on further helpful Mastodon feedback. You can see some play with fonts and mashing up elements from other iterations together based on folks’ suggestions:

I have a few favorites. Maybe you do too. I’m not sure which to go with yet – I have been staring at these too long for today. I did some quick mockups of how they look in the website:

I’ll probably sit on this and come back with fresh eyes later. I’m happy for any / all feedback in the comments here!

Website redesign is hard!

Posted by Suzanne Hillman (Outreachy) on April 15, 2017 10:26 PM

Some bits are easy enough: I’ve got a photo now, and there’s a section about me in which one can take a look at my medium, what I like to do in my free time, and how I got to UX (this is too long and I need to cut stuff).

<figure><figcaption>My main page</figcaption></figure>

Tabs, though. Tabs are _hard_.

Why are Tabs hard?

As I mentioned in my last post, I’m using Pelican to generate my site. I’m using restructured text plus CSS to write most of my content.


I first tried to use responsive tabbed navigation from Codyhouse because it looks really nice. Unfortunately, CSS is _extremely_ picky about order and I don’t even entirely follow what’s happening. Between the responsive Pelican theme pelican-blue I’ve modified (and which apparently is no longer… responsive? I broke something somewhere), and the figures and button code bits that I added, I get really confused as to what’s going on.

I pulled the CSS and HTML into notepad++ to get things lined up nicely and in a larger visible space than in the relevant codepen, which meant that I was more able to figure out what was going on and learned a whole lot about CSS. Unfortunately, although in that instance I got the base theme’s responsiveness working again, it collides with the responsive tabbed navigation.

In addition to this, I cannot figure out how to make the tabs actually _change_ what I’m seeing. I strongly suspect something is broken in the javascript that goes along with that code, but I have a lot of trouble understanding javascript at least thus far. This is not helped by trying to learn responsive text, css, pelican (and random bits of python) at the same time. I’m also not entirely sure that I managed to make the links in the tabs go to the right place: I tried using ids to label the content, and have the references go to those places, but ¯\_(ツ)_/¯.

I’m wondering if I can do something with Pelican’s jinja2 template engine to get tabs to work, as I strongly suspect that my problem is something to do with javascript and it looks like a lot of the plugins in Pelican that use javascript also use these templates. But, that does mean learning jinja2 as well!

Can I not use javascript?

Right, so the pretty but frustrating responsive tabs took up most of my time yesterday. I looked a few other links which talked about pure CSS tabs, but they looked like they would break if I breathed at them wrong. I did try one of them, and my suspicion seemed accurate in that case, which meant that when I tried to add it to my existing site it basically did nothing at all.

I was trying to figure out how to use bootstrap today, as I noticed that it was somewhat implemented in pelican through restructured text. Unfortunately, tabs are not yet supported by the bootstrap-rst plugin (which does support buttons, but I like my button and I did it already). I then decided to poke around the bootstrap tab code, which then proceeded to say that I needed to use javascript. As far as I could tell, not using javascript meant they wouldn’t actually work: why would you have tabs that don’t work? I stopped because I was no longer able to figure out what they were talking about anymore.

No, I need javascript!

Seems like tabs (and pills) require javascript, and I do not really understand javascript well enough to be sure why it might not be working when it fails to work.


In the meantime, I’ll just make separate pages for my “Completed Projects”, “Design Artifacts”, and “Current Projects” portfolio views. I think I may be able to nest them under ‘portfolio’ in my navigation menu, but I’ll have to poke at Pelican and how it works again to be sure about that one.

After all this, though, I think I know how to make a horizontal TOC for my regional hubs portfolio. Which I need to do.

Website redesign

Posted by Suzanne Hillman (Outreachy) on April 05, 2017 07:12 PM

During a recent conversation during a recruiter technical interview, the interviewer commented that my website wasn’t very welcoming or likely to encourage people to look further.

Now, one of the things she said was that I had no photo of myself. This is actually something I’ve been reluctant to put up, in part because I want it to not matter. But, perhaps, it does matter.

Upon reflection, there really isn’t much there about me as a person, rather than as a QE person turned UX designer. Even that part isn’t especially well described, so someone looking at my site has no real sense of how my background informs my UX skills and processes.

Let me show you what I mean:

<figure><figcaption>My home page</figcaption></figure>

This is everything currently on my home page. It’s functional enough, but it can be difficult to decide what to click on and why. And there’s really only professional stuff: contact info, resume, portfolio, and a little bit on accessibility.


My former mentor through Outreachy commented that this page, my resume, and my portfolio don’t really communicate my enthusiasm about UX. This is true, in part because I was trying to be professional, which rarely goes along with enthusiasm. She pointed out that my enthusiasm is clear on this blog, and that I need some way to encourage people to go here and read about my internship.

She also pointed out that I need an obvious link from here to my professional side: my portfolio, and LinkedIn. (Mind you, the description of my internship on LinkedIn needs some work.)

So, task one: decide how best to get people on my website interested in looking at this blog. Perhaps also decide which entry point to offer: maybe there’s an especially good post I’ve got up that I want people to look at?

What about me?

Right, so getting people aware of my enthusiasm is great. But what’s going to get them connected enough with me to bother exploring further?

Well, I need a photo of myself. Selecting a photo might be simple (use what I’ve got elseweb), or maybe I want to have it _say_ something about me. What it should say, I’m less sure about.

Maybe I want banner images on the approachable pages: my main page, and something about me and my background.

Task two: I need to talk about myself. I likely won’t talk about my relationship structure or anything, since that’s more personal than I want to get. But I could talk about my garden and pond; the cats, plants, and people I live with; my interest in wandering around wooded areas and kayaking. I could mention that I play World of Warcraft. I could probably talk about my general liking of people. And living things, really — if you’re alive, I’m probably interested in learning more about you.

Also, pictures of things. People like pictures of things!

From my professional background to UX

Task three: I need to talk about my background. Starting with a computer science undergrad degree, meeting fellow computer scientists and Linux enthusiasts. Those enthusiasts helped get me into an internship in QE at a Linux company, and from there I continued on to do QE at two other Linux companies. I’ve tested a wide range of things, from drivers to databases to desktop software to wireless networking. I tend to do a lot of writing: it makes it easier for me to have references for things and it makes it easier for other people to be able to read what I’ve written. I eventually left QE in part because of my frustration with usability bugs not being addressed, and the amount of struggle involved in getting people to listen. I was doing QE on Linux software for nearly 10 years, and using it for a few years before that: I’ve got pretty good open source technical skills.

I was interested in psychology research, and after some initial online classwork, I realized that I was never going to get into graduate school without some research experience. Volunteer work at a lab near my home meant that I got into a Master’s program at that school the following year. That Master’s degree involved a great deal of running research studies, collecting data from those, and analyzing that data. As a result of that time, I got a lot more comfortable interacting with participants, and figuring out what to do with the data — often involving other people’s ideas and perspectives on the best approach. After the master’s degree, with a great deal more work and time, I got into a psychology/human-robot interaction Ph.D. program. This was fascinating stuff, and meant that I had even more practice creating a research plan; running a research study; and collecting, processing, and analyzing the data. Unfortunately, I did not complete that program, and had to reorient my career plans.

During that reorientation period, I considered the many people I knew in UX. I recalled how frustrated I’d been when usability issues were closed because “they weren’t bugs”. I thought about how much I enjoy doing research, learning about people, and what they are doing and why. I had a lot of discussions with current UX professionals, and they generally agreed with my feeling that UX was the right way forward for me. At that point, the task was to figure out how to make the transition.

A year and a half later, I’ve attended multiple UX meetups, went to the UXPA conference, read a bunch of books and websites and blog posts. I’ve done a couple of UX projects to help focus my learning, a hackathon, and the recent internship. This is amazing stuff, and it’s clearly taking off.

How do I focus all this stuff?

So great, that’s a lot of stuff up there, even after trying to trim it down. How do I focus my background in a way that helps people see a) my open source, linux, technical background, b) how I got to UX, and c) is interesting enough to keep them reading.

Do I mention that the way I got online in the first place was by constantly asking questions of the local sysadmin at the college I was in at the time? I’d never seen UNIX before, but I wanted to understand it. And he was willing to answer my questions. These were UNIX boxes in the campus library, where I spent much of my time.

This was handy later on, because it meant that Linux wasn’t that foreign an OS to me when people mentioned it and the possibility of using it. Sure, the install process at the time was really confusing, and it was wonderful that friends of mine helped me through it the first time or two.

Do I even mention all the research that I did and am doing on UX, or is that something that belongs in the porfolio section? How does one “show your work” without showing too much work?

What about the fact that my website is itself technical? I’m using the Pelican static website generator, with a theme that I’ve been modifying. This has meant trying to figure out how to do things like make images have captions (the better images and figures plugin plus some modification so that I can set the width in the restructured text syntax rather than having it default to the actual image size), figuring out how I might have my images be expanded inline to full-size on click (still working on that one), and figuring out how to make images be links (“target” apparently). I’m also going to need to figure out tabs (or pills) and buttons, if I want those.

I don’t write code, but that doesn’t mean I can’t modify existing code to do what I want.

What else?

So, I’ve mostly talked about content so far. That isn’t all that is involved with being a welcoming website, however.

I’m considering adding buttons to make the bits that I want people to click on more obvious. Everything is currently links, except the overly cryptic social media section on the side which are instead icons.

What about the portfolio itself?

I’ve not yet shown you the portfolio page, so let’s get to that:

<figure><figcaption>Portfolio main page</figcaption></figure>

At least the portfolio has pictures, right?

My mentor suggested adding an alternative view or section at the top in which there are thumbnails of particular design artifacts. She was worried that people might not want to go through an entire project, and might therefore miss the variety of different design methods I have used.

Great. I see how this might be useful. How do I make it not overwhelming, though? There’s already a lot of stuff on this page…

Maybe tabs? Or pills (which term I used when looking up how to do tabs in CSS)? Have the first, default, section be the portfolio organized by project. Have another one which is organized by artifact. Maybe a third for current projects like this redesign?

What about reference statements? My mentor said she’d be happy to provide one, and I can definitely see how those’d be useful. But where do I put it so that it’s visible without being too crowded?

Internship portfolio

Another reviewer of my portfolio suggested the possibility of a table of contents for my internship portfolio:

<figure><figcaption>There’s 11 sections on this page!</figcaption></figure>

This seems like a perfectly reasonable suggestion, given there’s 11 sections on the page, all of which have images and a brief description.

I can’t figure out how best to do it without taking up a ridiculous amount of space, or making it hard to interpret. ToC tend to be a list of items top to bottom. That seems ill-advised.

I was considering trying to create a box in which I have an invisible table that holds the links to the rest of the portfolio. I can’t decide if that’s a terrible idea, though. I probably need to see what other people do for table of contents-like things!


I’m also working on presentations for the work I’ve done, and for About Me. I’m not sure if that’s the right kind of thing to include on my website. Will have to consider on that one.


I’m currently working on my website redesign and presentations, getting involved with Patternfly Design, and was impanelled on the grand jury for my county for the next three months.

Oh, and job hunting. Which is a bit complicated by the grand jury part!

Portfolio feedback needed!

Posted by Suzanne Hillman (Outreachy) on March 29, 2017 08:02 PM

It’s not done, but it’s very close. Certainly close enough for feedback.

If anyone is interested or willing, please check out the Regional Hubs piece of my portfolio at https://suzannehillman.com/pages/fedora-regional-hubs.html

Thank you!

Sneak Peak into F26 Supplemental Wallpaper

Posted by Sirko Kemter on March 20, 2017 06:38 AM

There are just few days left, then the submission period for the Fedora 26 Supplemental Wallpaper ends and the voting will be open. Time for looking a bit behind the scenes. So far we had 94 submissions, that is again the average we had over the last contests.
The quality is also again average, compared to the time we started Nuancier its much lower. I have a strong feeling we have a lot of people just submitting something to get the badge. We have to get to a stage with an higher quality again and I started this time also to reject for quality reasons, from the 94 submissions stay after 83, so 11 rejections. I think thats record, but its not for quality reasons most I had to reject for copyright violations. Its a bit hard for me that some Ambassadors have no idea about licensing, and that they are not the author/creator of a picture even the real creator has licensed it CC0. So this time all this things was direct rejected, no second chance and I think I will keep it that way. Why sould I invest more work as necessary especially it doesnt get honored and I get insulted later on for it.
It cost me an average of 6 minutes just to moderate a submission and award the badge, not to mention that I have to do a legal research for them which costs an average of 2 hours a submission. Not to mention that there is also time needed for the creation of the election, for the article in Fedora Magazine which anounces the start of the contest, the article in the Community Blog which reminds you to go for the vote and and and…. Its more as a full month work just for that.

So for the next election there will be some changes more according to the submitters who submit work of others. I definitely will deny submissions from other wallpaper services/pages. Some other things will follow but require some technical changes in Nuancier, back to quality back to honor the people who create things for Fedora and work for doing it. Not the ones who search for 10 minutes in the internet for a free licensed picture and submit it but later on are the loudest ones, that they have submitted.

Thats all for now and now my usual 5 favorites amongst the submissions

Huh, fascinating. Didn’t occur to me that rectangles had the option to be links. Thanks!

Posted by Suzanne Hillman (Outreachy) on March 16, 2017 03:02 PM

Huh, fascinating. Didn’t occur to me that rectangles had the option to be links. Thanks!

Working on the portfolio

Posted by Suzanne Hillman (Outreachy) on March 15, 2017 08:50 PM

I’ve been working on making a portfolio of what I did for the Fedora Regional Hubs project. Did you know I did a _lot_ of stuff?

I mean, I was definitely busy getting things done throughout. I knew this. Summarizing what I did in a way that someone else can follow is surprisingly complicated. There’s a lot of information scattered around my email, pagure tickets, throughout this blog, and on my latop.

I’m really glad that I was blogging the whole time, because it makes it a lot easier to reconstruct what I did. But boy. This is very time-consuming!

I am glad that I decided to try starting with a presentation outline: while the presentation isn’t done, it’s started, and it helped give me focus for the summarizing I have been doing.

I’m also glad that I am able to ask Alex Feinman for feedback, as it has been very helpful to be able to talk to him about it. And that I could ask a million questions of Mo both during and after the internship.

Even just the high level outline I wrote last night in a fit of comprehension looks like a lot:

Preliminary research

  • Competitors
  • Fedora Hubs
  • Contextual interviews


  • Processing raw data (transcribe, summarize, top 5 pains, problems, workflows)
  • Brainstorming with others (whiteboards, notes on brainstorming session, sketches to start with)
  • Questions
  • Affinity mapping
  • Prioritization
  • Deep dive/brainstorm on top questions (don’t forget survey!)


  • General sketches & wireframes & tickets (invitation page, login, etc) — after general brainstorming session
  • Specific sketches & initial wireframes & tickets (search/filter pages for people, events, Hubs. Notifications/widgets)
  • Find holes, enter tickets.
  • Additional discussion as needed/follow-ups in weekly meetings/blog posts

Feedback and iteration

  • Feedback from Mo on wireframes, discuss, adjust
  • Feedback from sayan on feasibility
  • Locations!
  • From participants?

Usability Sessions

  • Prepare for usability sessions.
  • Prototypes need connections among themselves.
  • Identify tasks
  • Prioritize tasks
  • Identify and contact participants (who, why?)
  • Usability script
  • Usability sessions

Analyze feedback

  • Transcription, summary, highlight important
  • Spreadsheet!
  • Discuss with Mo

I appreciate this!

Posted by Suzanne Hillman (Outreachy) on March 14, 2017 06:09 PM

I appreciate this! At the moment, I’m still not sure if it’s possible to have an entire line in a table be clickable. I did figure out how to tell people to turn on ‘clickable’, although sadly after my last usability session. Next time, clearly.

Getting stuck in the details

Posted by Suzanne Hillman (Outreachy) on March 09, 2017 04:08 PM

My entire life, I have been prone to getting stuck in the details of a thing. It’s one thing to know this, and another to continuously find ways in which it affects me and for which I have developed workarounds.

I’ve learned to recognize that sudden exhaustion means that I’m stuck in the details and need to take a break.

Whether it’s my surroundings, a particular task, or a website, details are likely to distract and overwhelm me. This may or may not tie in with my ability to notice details that others overlook.

I suspect it’s much of why I have trouble with clutter in my surroundings, whether at home or in stores and restaurants. I suspect it may also relate to my difficulty with noisy surroundings.

I was reminded of this tendancy of mine during the recent outreachy project. Of course, I was also reminded of the many workarounds I’ve developed to handle it.

CSS and Coding

When working on CSS, I started to wonder if the difficulty that I have with writing code is purely about the number of details involved. I understand coding fairly well, and have no problem talking about it with those who do it for a living. At the same time, trying to write code usually results in me being exhausted and frustrated, and not actually successful at creating the code. Modifying code is always much easier, I suspect because there’s simply less to deal with and I am less likely to get stuck.

Using CodePen helped, I suspect in large part because I could see the immediate effects of what I was doing. My strong tendency to break problems into smaller pieces also came into play, as when I was stuck on a particular aspect of the CSS, I’d just clone my Pen and take out the bits that weren’t currently relevant.

Transcription, summarizing, and brainstorming

Transcription and other detail-oriented tasks

Transcribing from audio or video means I’m faced with a wealth of information that needs to be expressed in a written way. For the first in a set of items that need transcription, I always find myself getting stuck and writing down _way_ too much stuff.

I tend to need frequent breaks when transcribing, simply due to the sheer amount of information and the fact that I will start to forget what’s actually important. After I’ve done the first in a set, it is usually much easier for me to identify what’s important and what’s not, so the rest will go more quickly.

Similarly, when working on a task that is part of a larger project — as most tasks are — I can easily get stuck in the nitty-gritty of the task and forget why I’m doing it. This makes it harder to actually perform the task due to being stuck and to not remembering the purpose.


One of my most effective workarounds, in addition to frequent breaks, is to summarize what I’m doing and what I’m learning. Whether it’s in a blog post, as with the Regional Hubs project, or in talking to others involved in the project, summarizing and explaining what I’m doing never fails to get me back out of the details. Of course, it’s also typically useful for the people with whom I am conversing and for my own later use.

It is typically easier for me to write than talk my way out of being stuck, as long as I write as if I have an audience. And Medium’s interface is _fabulous_ for this. It doesn’t get in the way of what I’m trying to say, and is minimal enough to not itself act as a source of distracting details.

It’s also helpful to have written logs of conversation, which can be harder to get with people I’m speaking to in person. I retain what I read much more easily than what I hear. For this reason, having a remote job can be useful, because most conversations are written and often easily logged. This is also why I tend to try to take notes during conversation, or ask people to send me written reminders. Similarly, I’m trying to add the habit of sending a written summary of what I understood from spoken conversations when I am concerned that I missed something.

I strongly suspect this need to summarize and explain to get out of the details is why I am good at explaining things. Lots and lots of practice, plus that being how I understand things better.

I also strongly suspect this is why I so badly want other people to work with or near: other people and the need to explain what I’m doing help me stay grounded in the overall purpose of what we are doing.


Like discussing what I’m doing with other people, brainstorming with others is fabulously useful, especially if they know something different about the topic than I do. While I might get stuck in the details when investigating something on my own, having someone else there means that they might not get stuck, or at least we can work together to pull ourselves out of rat holes.

Of course, brainstorming also brings in the wonderful thing called ‘other people’s perspectives’. No one can think of everything, no matter how hard they try. Involving other people means that together you have a good chance of coming up with things that work better than what either of you would come up with alone. People are very good at building on each other’s ideas, and often find it enjoyable, as well.

Data Analysis

Analyzing data typically involves a great deal of detail work. There is usually a great deal of data, and it’s all too easy to lose track of the big picture of why the data was collected in the first place and what the goal actually is.

I _love_ that analyzing data in the UX world is often a group experience, whether through affinity mapping, brainstorming, various methods of prioritizing, and other things that aren’t currently coming to mind. It means that I don’t get stuck as often.

In grad school, analyzing data was often an exercise in figuring out ways to not get stuck in the data and remembering what I was there for. Analyzing data alone is not good for my mental health, as I’ve not yet found useful ways to keep myself on track for long periods of time. Statistics are hard for me, not because of the math, but because I have trouble remembering what to do when or why.

I also love that in UX there are often diagrams to remind you what research methods are most useful when. I’m sure that’ll come more easily to me with practice, mind you.

Speaking of research methods…

Learning UX is full of details

I think the biggest problem that I had when trying to learn UX on my own was the sheer amount of information. Having an internship and people to work with means that I had a way to focus.

Pre-internship, having had projects that I was working on didn’t help enough in terms of focus, because there were so many options.

I tried to write blog posts about what I was learning, as you can see early in this blog. Much of the time, writing the blog posts meant that I kept finding out how much I didn’t know yet, and how much trouble I was having figuring out what to learn first.

There is a _lot_ to UX. I have the skills to do it, I know for certain. It can be daunting navigating the sea of possibilities to identify what I should focus on.

Visual Design is full of details

I suspect the trouble I have with figuring out visual design is that it’s full of details. At least when I was trying to do things in Inkscape, the sheer quantity of things that you can do meant that I often had no idea where to start. Even once I understood that there were sample style patterns in the hubs design github, there were still a lot of possibilities.

I have no idea what’s important to pay attention to in visual design. I don’t know how to tell what’s a thing that needs to be the same always (nor do I know how to make sure that’s true), and what the range of ‘reasonable’ is. And the number of tools in professional drawing programs is absurd. If I don’t know what I need, how would I possibly know what tools to use, when?

I’m sure this is a tractable problem to solve. At the moment, though, it’s an especially daunting one. It is probably not aided by my lack of visual imagination or memory.

I think this is why I’m so happy that Balsamiq exists. The number of tools available is much more limited, and rather than trying to guess what something should look like, there are a number of items that already have a template for you to use. Indeed, working in Balsamiq is kind of like having a lot of small templates that one can use as building blocks, rather than making it up as you go.

I worry that Sketch will be too flexible. I won a license for it, and I should have access to macs in my household that I can play with it on. Indeed, after this internship, I am somewhat more comfortable with the idea of playing with it. I have some visual design knowledge just by frequently referring to the protoypes that Máirín Duffy made.

Portfolios are full of details

At the moment, I am trying to distill what I did in this internship into a portfolio format. I keep finding myself stuck in details, so I’m thinking that perhaps it makes more sense to create a presentation, first. I’ll need one regardless, and those force you to stay big picture.

In closing…

The world is full of details!

Getting the in-person stuff to work was crazy complex.

Posted by Suzanne Hillman (Outreachy) on March 08, 2017 08:25 PM

Getting the in-person stuff to work was crazy complex. One thing for remote testing: it’s a lot easier to organize!

Thanks for being willing!

So, how was Outreachy for me?

Posted by Suzanne Hillman (Outreachy) on March 08, 2017 06:57 PM

Overall, I loved it. Sure, there were annoying bits, but there are always annoying bits no matter what the job is.

Good things

There were lots of good things!

First, I had the best mentor. It helps that I already knew her, and that she offered to be my mentor when she suggested Outreachy to me. She’s been unfailingly helpful and kind, and very supportive.

At the very start, she offered me the choice of working on small scale existing UX tickets in Fedora, or doing a full-fledged project. The former would have been easier, in some ways, but not nearly as useful for progressing my career. The former would probably have been easier, if less useful, for her as well.

Second, the fedora-hubs team is a good group of people. Welcoming, helpful, and unfailingly polite. I may have only been there for a few months, but I will miss them.

Fedora people as a whole were similarly helpful; I had nothing to offer my interviewees and participants but my goodwill, and everyone I asked was happy to help out when they were able.

Third, the task was an interesting one. I think at this point I’d probably describe Fedora Hubs as a whole as an interface that consolidates and filters information about and from many different places so that an individual can find what’s important or interesting to them within Fedora. I probably need to throw something about making it easier for new Fedora users to get involved, although it’s hard to say if that’s Hubs as a whole or specific to the Regional Hubs that I was working on. Or both! Probably both.

I’d say the overarching goal for Regional Hubs was to encourage and support community within Fedora. Some of the problems that we were trying to solve were as simple — but not easy — as helping new users more easily get involved with the Fedora community, encouraging in-person social interaction to help people become and remain connected, and helping people find each other and events. Some of these we knew were problems ahead of time (like new users getting and staying involved), and some came up during the interviews (finding people and events).

As some of you likely saw while reading along, locations are hard. This made for a very interesting discussion to figure out how we wanted to handle that, and there are still aspects of it that I suspect need more attention. However, if we want people to be able to find people and events near them, locations are also really important.

I most enjoyed the discussions in which we were exploring the bounds of what we needed to know or do. This included brainstorming in general, the aforementioned complications around locations, and the conversation around the feasibility of the mockups in which we touched on how Hubs might suggest new regional hubs.

Neutral things

I didn’t really get a chance to learn more about visual design and how to translate from a mockup to a higher fidelity design. This was as much about available time as the difficulty of explaining it. I do have an example of the before and after versions of this for one of my mockups, and Mo has sent a screencap of creating mockups in inkscape. Hopefully these will be useful!

I didn’t finish creating the CSS for the high fidelity visual design that Mo had already created. I got stuck on translating from table to div, and needed to focus my attention elsewhere.

Less good things

First, I really don’t like working remotely. I like people, and having people around is good for me. I also like being able to talk to people about what I’m working on and have them already have the context and knowledge to have productive conversations. This is still possible remotely, but there’s something missing from it in that context.

Second, and relatedly, I feel like remote usability tests and interviews are not as good. They do the job, for sure, but I feel like I missed out on stuff by not being _there_ with the participants. This is likely not helped by the connection to some of the locations participants were in being slow or intermittent.

Unfortunately, I was not able to do any local, in-person usability tests due to snow and other troubles.

This may actually be showing my bias from having done psychology graduate work: all our participants were in-person.

Third, transcription of interviews and usability tests are _annoying_ and really time and brain-power consuming. I knew this already, from my work with video and audio of people’s interactions with robots and with each other.

On the plus side, interviews and usability tests have less content to deal with, since I don’t need to identify and describe every gesture and every word spoken. Nor do I need to parse through 32 different recordings to try to find and appropriately label the right data to plug into statistical software to find patterns.

Fourth, Git and github and pagure have a higher learning curve than I’d like. This is not helped by the need for ssh keys in all sorts of places. I still wish it were possible to put my public key in _one_ place and have all the tools needed in Hubs work use it. A lack of communication between tools is a very common problem in all sorts of industries, and not just around ssh keys.

Fifth, having my internship include Xmas and New Years early on meant that I was rather less productive than I’d have liked around then. I needed a fair bit of guidance at a time when people weren’t around. Annoying, but not awful.

In summary

Good program, A+++!

Seriously, I’m glad Outreachy exists in both a theoretical ‘getting more diversity into open source’ sense, and in a practical ‘this was fabulously useful to me’ sense.

I do wish I could see this project through to fruition. But alas, that is not how Outreachy — and many other internships — works.

Now, to put this project into and otherwise update my portfolio!

(As a reminder to myself and others: the ‘story’ that people talk about when creating portfolios is a combination of providing context for the photos and graphics and screenshots you include, and showing what you have done vs what others did, what you were trying to accomplish, and your thinking about it.)

Previous, usability testing and analysis wrap-up.

Usability testing and analysis wrapup

Posted by Suzanne Hillman (Outreachy) on March 07, 2017 09:14 PM

Outreachy ended yesterday, so I’m working on cleaning things up for others to use.

I have completed my summaries of the initial interviews for event creation/planning and ambassadors as resources. I did not manage to translate the CSS from table to div, as things were behaving very oddly when I tried. However, I did pass along the CSS/HTML work I had done to Máirín Duffy.

Mo also has access to all the recordings of my interviews and usability sessions, the survey which ended up with 140 responses, and the MyBalsamiq instance for the Fedora Design team in which I put my mockups. I have put the anonymized transcripts and spreadsheet for the usability testing into the User Research and Analysis ticket shortly.

I hope to use the travel expenses for Outreachy to attend FLOCK in Cape Cod this summer.

Usability Testing

Here, I’ll summarize how the usability testing went overall, what sorts of things I found, and some of the things that Mo and I discussed in our analysis. Due to time restrictions, we did not make it through everything I found for analysis purposes, but I will be available for questions and clarification as needed.

As I said in my last post, I ran remote usability sessions on my prototypes with 5 people. The major time sink for this was creating transcripts, although mostly not word-for-word. As I went, I highlighted the things that seemed relevant so that they would be easier to find when I was summarizing the findings. I ended up using a spreadsheet to organize the findings, first by prototype, and then by content to make reviewing it easier. For more on this, please see the attachments to the research and analysis ticket.

I then met with Mo to discuss my findings and to start preliminary analysis of them. We initially focused on the things that multiple people reported, with some side conversations around related problems when necessary. In many cases, the decision on what to do was pretty simple (often because it was effectively a paper prototype and thus not as interactive as it could be). However, some of the problems my participants ran into were not simple fixes and required a lot of discussion.

One of these related to the problem of deciding who to contact first in a filtered list of people. As it was, the prototype did not show anything about your relationship with those people. Even when you clicked on someone, it was not obvious that the hubs and friends listed started with the ones you had in common:

<figure><figcaption>Do I know Jen Smith better than John Holsberg? Who knows?</figcaption></figure>

When I asked people to find someone to contact, whether because they were visiting an area and wanted to find local Fedorans to meet up with, or because they needed more information about an upcoming event, they had trouble deciding who to talk to. In this prototype, only one person was clickable (Jorge), but my participants had no idea if that was who they actually wanted to talk to.

Affinity Mapping?

Some suggestions people made included having something signalling if they have an existing relationship with the people in the list. In talking with Mo, however, that can get very complicated, very quickly.

We can decide that people who are following each other are friends. However, what if you think someone is fabulous, but don’t need to know about their activity within Fedora, or don’t have the time to add that to what you are paying attention to. At the moment, following someone means that you see what they are doing in your stream, so perhaps mutual following is insufficient information.

Maybe you’re on a team with someone so you’re theoretically interacting with them regularly. This is more likely to be useful information about how you are connected to that person, except possibly if you’re on a huge, geographically disperse team.

Maybe you talk to someone on IRC regularly. That probably means you know them, right? Maybe work with them? Sure, but that may not mean you want to meet up with them.

It absolutely would be helpful to Fedora members to know their relationship, if any, with people they are considering contacting. Precisely how to do this remains to be seen.

Supposing we use team affiliation, following, and conversation frequency. How do we signal this kind of information at a glance without making the information too overwhelming and difficult to process? Icons can be good _if_ they are some of the very few that are quickly understood. Text can get unwieldy. This will have to go unanswered for now, but requires more thought.

Online Status

It’s helpful to know if someone is online right now. It’s probably not as helpful to know precisely when someone was last online when you’re looking at a long list of people.

Lots of applications show that someone is online using a simple blue (or green) dot near their picture or name. This may be the best way for us to do the same, and will also free up some space in the search results for affinity signalling. At the same time, we probably want to make it clear who hasn’t logged in recently. Since this will be pulled from a list of people with FAS account, there may be people in the results who have never logged into Hubs, and we need to show that somehow. We can easily show more precise information about when someone was last online in the dropdown, and from the perspective of too much information, that definitely makes the most sense.

Who wants to meet strangers?

Another frequent problem was that my participants didn’t especially want to be contacting random Fedora people out of the blue. Most said that if they knew someone liked meeting strangers, or were interested in helping others out in some way, this would reduce that barrier to contact.

So, instead of having the ability to select only ambassadors — who may or may not actually want to be contacted right now — make it possible to select people who are interested in meeting new people or answering questions or otherwise welcome random contact. Of course, what this needs to be called is an entirely different question. It might be as easy as an ‘Open/Closed’ sign like some businesses have, but that may be too easily misinterpreted or daunting for other reasons. More research is definitely needed here!

What do the search boxes accept?

In looking at the major search and filter areas of the list of people and events, it can be difficult to determine what is valid.

<figure><figcaption>People search and filter</figcaption></figure><figure><figcaption>Events search and filter</figcaption></figure>


When asked to search for people in Berlin, many tried to use the ‘all people’ search to look for Berlin. The actual intent is that they can change ‘you’ to a specific location other than where the system knows they are. The ‘all people’ search box is for searching by people’s names, nicknames, IRC nicks, and email addresses.

Similarly, when asked to find events in Las Angeles, the ‘all events’ search box was very tempting. Again, the ‘you’ box is there to allow you to change the location away from your own location.

So how does one make this clearer?

We had a few thoughts on how to best handle this one. Mo pointed out that a common pattern is that searches are along the top, and filters are along the left side. In that case, why not let people search by location in the search box?

We also considered that this might be a lot clearer if it were possible to actually type into those fields: once you start typing, type-ahead would quickly make clear the sorts of things the search box was expecting.


Another, similar, problem was that the contents of ‘10’ miles and ‘you’ (different for events and people) were somewhat unclear on what they were able to take as inputs. My mockup had dropdowns for these, since we wanted to not only allow people to start typing in those boxes, but also to make clear the kinds of things that were possible in there. However, in no case did people realize that they could simply start typing, rather than only selecting from the dropdown options.

<figure><figcaption>events near [place] or in [place]</figcaption></figure>

You can pick near ‘you’, near a specific location, or within an area. The latter case wouldn’t need the ’10 miles of’ piece, though.

<figure><figcaption>People near [somewhere], including everyone</figcaption></figure>

I wanted to have the option of everywhere because otherwise actually specifying something in ‘all people’ makes no sense. At the same time, perhaps you _do_ care where. This one confused me and I failed to explain my reasoning to Mo.

<figure><figcaption>Events or people within [miles of somewhere] or [a place]</figcaption></figure>

How far from the place you specified? Or, maybe you just want to say within a place?

This is likely an even more complicated problem than I suspected, but hopefully it was largely due to the fidelity of my prototype.

But what do we do?

We did not come to an agreement on the best way to handle either of these cases, in part because we suspected that this was a problem with the fidelity of the prototype.


Some of the problems I ran into were fairly easy to solve. Others need additional investigation and consideration. There are findings from the testing that have not been reviewed, and I hope that Mo will be able to find the time to go through them and contact me as needed.

I have no question that the usability testing was valuable, and hope that the existing team will be able to continue the work that I started. I wish that I were able to continue to work on this project, and shall see if there is any time available while I apply for jobs and hopefully start a full-time job soon.

I found this to be a fabulously useful experience, and want to thank Máirín Duffy and the Fedora Hubs team for being helpful, approachable, and friendly. And of course, to thank Mo again for having mentioned the possibility of Outreachy to me.

Previous, usability testing.

Next, how was outreachy for me?

I have not disappeared!

Posted by Suzanne Hillman (Outreachy) on February 23, 2017 10:27 PM

I promise. Got a nasty cold, so wasn’t making as much progress, but still here.

Brief catchup, since I’m in the middle of trying to get a bunch of wrap-up stuff done.

Usability tests with mockups

As I said a few posts ago before I dove into CSS, I needed to do some usability tests with my mockups. I was unable to get any of my original set of interviewees to do this, and due to sickness on my own and Mo’s part and weather interfering, was unable to do any in-person usability testing.

I did get 5 people using my prototype, with a good spread among the tasks I had available.

As mentioned previously, my tasks included what we identified as the most immediately relevant aspects of the project, and the mockups I made for those.

The first page of each of my prototypes and their associated tasks are shown below, with a link to the prototypes themselves in the short description below each mockup.

Prototypes and tasks

<figure><figcaption>The People Prototype</figcaption></figure>
  • You heard that there were going to be events in your local region (Southern California) in the next few months. Using this interface, find one of those upcoming events and show me how you would interact with the interface to find out when the event is, where it’s located, and who to contact about it, and tell me what you are thinking as you do it.
  • You recently attended an event, and are wondering if anyone has put anything interesting on the event page. Using the prototype, find a past event and visit the page, and tell me what you are thinking as you do it.
<figure><figcaption>The Events Prototype</figcaption></figure>
  • You are going to be traveling to Berlin, Germany on a business trip and have a couple of extra days on the tail end of your journey to explore. You wonder if there is a Fedora community of locals that you could meet up with during the trip. Use the prototype to find Fedora folks near Berlin, and tell me what you are thinking as you do it.
  • FLOCK Los Angeles is tomorrow, but you cannot find the address of the venue or directions on how to get there. You need to figure it out before tomorrow so that you can arrange for a ride there. Find a Fedora community member in the Los Angeles area who is online right now to help, and tell me what you are thinking as you do it.
<figure><figcaption>Join us or Sign Up</figcaption></figure>
  • You live near Boston, MA, USA, and someone sent you a link to the Greater Boston Hub. You’ve never used Fedora Hubs before. You want to join the group to keep up to date with what they are doing. Using this prototype, join the group and tell me what you are thinking as you do it.
  • Create a new account on Fedora Hubs using the prototype, and tell me what you are thinking as you do it.
<figure><figcaption>Event Notifications</figcaption></figure>
  • We have a few different notifications relating to regional hubs and events. These would appear in your stream of information called “My Stream”. I would like you to take a look at these and tell me know what you think of them. What do you think you can do here, what do you think they are for; Just look around and do a little narrative.
  • Now, please respond to the first event in the list, either ‘going’ or ‘maybe’. Talk to me about what you expect to be happening here and what you are doing.
  • Please return to the first page using the back button, and select the other option from the first event.

Initial reactions

After two usability sessions, it became pretty clear that any one individual should do one, not both, of the two tasks in people, events, and join or create. Those were much too similar and were causing confusion to be done in a single session.

Similarly, in the initial prototypes, the top-most bar was too realistic-looking, having been from a screenshot of a more visually designed page. As such, to better determine the source of confusion with multiple search bars on the same page, I replaced the search bar with one from Balsamiq.

Some small issues with Balsamiq came up. First, MyBalsamiq did not show what items were linked on the prototypes my users saw. If I looked at them myself, I saw the appropriate markings.

Second, I was unable to have an entire line be clickable, which added some unnecessary confusion. As far as I could tell, this is simply not supported.

I suspect strongly that this experience would have been greatly improved by a note-taker. It’s taking a lot of time to go through the sessions after the fact, identify and gather the relevant information, and come up with a good way to summarize what I found. I do also appreciate the experience and viewpoints of others when collecting and interpreting information.

Once I’m finished collecting together the information from the usability sessions, I will be discussing what I found with Mo, likely doing more affinity analysis, and creating some sort of summary of the results and of the entire experience. I’m not yet clear on what that all will involve, and sort of suspect it’s not likely to be complete by the 6th. Frustrating, but that does happen.

Closing Activities

My internship will be coming to a close on March 6th. I would like to leave things in as clear a state as I can, both to allow others to continue my work, and to make it easier for me to pick it back up when I’m no longer able to work full-time on it.

In addition to the collating, analysis, and summary of the usability testing, I will be finishing up a number of other things. This includes summarizing what events/event planning needs to include, what ambassadors tend to be doing as resources), and making sure all the raw data (transcripts and recordings) are available to Mo.

I’m still pushing people to take the survey, and it looks like some work that Mo and I recently did improved our numbers significantly (from 28 responces to 121!). I’m not sure that I’ll have time, but I’m hoping to do some analysis of that, as well.

I’ve not really had much chance to really understand how one goes from prototype to visual design, which is unfortunate. That is one area that I definitely need more experience with! I may see about working more on that post-Outreachy.

A logo for cri-o

Posted by Máirín Duffy on February 22, 2017 08:09 PM

Dan Walsh recently asked me if I could come up with a logo for a project he is involved with – cri-o.

The “cri” of cri-o stands for Container Runtime Interface. The CRI is a different project – the CRI is an API between Kubernetes (container orchestration) and various container runtimes. cri-o is a runtime – like rkt or Docker – that can run containers that are compliant with OCI (Open Containers Initiative) specification. (Some more info on this is here.)

Dan and Antonio suggested a couple of ideas at the outset:

  • Since the project means to connect to Kubernetes via the CRI, it might be neat to have some kind of nod to Kubernetes. Kubernetes’ logo is a nautical one (the wheel of a ship, with 7 spokes.)
  • If you say cri-o out loud, it kind of sounds like cyro, e.g., icy-cool like Mr. Freeze from Batman!
  • If we want to go for a mascot, a mammoth might be a neat one (from an icy time.)

So I had two initial ideas, riffing off of those:

  1. I tried to think of something nautical and frozen that might relate to Kubernetes in a reasonable way given what cri-o actually does. I kept coming back to icebergs, but they don’t relate to ships’ steering in the same way, and worse, I think they could have a bad connotation whether it’s around stranding polar bears, melting and drowning us all, or the Titanic.
  2. Better idea – not nautical, yet it related to the Kubernetes logo in a way. I was thinking a snowflake might be an interesting representation – it could have 7 spokes like the Kubernetes wheel. It relates a bit in that snowflakes are a composition of a lot of little ice crystals (containers), and kubernetes would place them on the runtime (cri-o) in a formation that made the most sense, forming something beautiful 🙂 (the snowflake.)

I abandoned the iceberg idea and went through a lot of iterations of different snowflake shapes – there are so many ways to make a snowflake! I used the cloning feature in Inkscape to set up the first spoke, then cloned it to the other 6 spokes. I was able to tweak the shapes in the first spoke and have it affect all spokes simultaneously. (It’s a neat trick I should video blog one of these days.)

This is what I came up with:

3 versions of the crio logo with different color treatments - one on a white background, one on a flat blue background, one on a blue gradient background. on the left is a 7-spoke snowflake constructed from thin lines and surrounded by a 7-sided polygon, on the right is the logotype 'cri-o'

I ended up on a pretty simple snowflake – I think it needs to be readable at small sizes, and while you can come up with some beautiful snowflake compositions in Inkscape, it’s easy to make snowflakes that are too elaborate and detailed to work well at a small size. The challenge was clarity at a small size as well as readability as a snowflake. The narrow-line drawing style seems to be pretty popular these days too.

The snowflake shape is encased in a 7-sided polygon (similar to the Kubernetes logo) – my thinking being the shape and narrowness of the line kind of make it looked like the snowflake is encased in ice (along the cryo initial idea.)

The dark blue color is a nod to the nautical theme; the bright blue highlight color is a nod to the cyro idea.

Completely symbolic, and maybe not in a clear / rational way, but I colored a little piece of each snowflake spoke using a blue highlight color, trying to make it look like those are individual pieces of the snowflake structure (eg the crystals == containers idea) getting deployed to create the larger snowflake.

Anyway! That is an idea for the cri-o logo. What do you think? Does it work for you? Do you have other, better ideas?

Help Fedora Hubs by taking this survey

Posted by Máirín Duffy on February 21, 2017 10:10 PM

Here’s a quick and easy way to help Fedora Hubs!

Our Outreachy intern, Suzanne Hillman, has put together a survey about Fedora contributors’ usage of social media to help us prioritize potential future integration with various social media platforms with Fedora Hubs. If you’d like your social media hangouts of choice to be considered for integration, please take the survey!

Take the survey now!

Running amdgpu driver on AMD hybrid laptop

Posted by Luya Tshimbalanga on February 20, 2017 08:18 PM
Running the ASUS X550ZE laptop on latest Linux kernel 4.9 series from Mystro256 Copr repository based on AMD contributor Alexander Deucher's freedesktop branch within Fedora Design Suite 25.

The hybrid support has improved now that the dedicated graphic card AMD R5 M230 Jet Pro (aka Hainan) is functional with enabled amdgpu module for both Sea Island (CIK) and South Island (SI) videocards thanks to the hard work from AMD developers. The latter was important in order to fully support all GCN (Graphics Core Next) chipsets as possible to allow future run on open source version of Vulkan, RADV (short for Radeon Vulkan).

The power manager is functional and further optimization will be required in term on parity with Microsoft Windows version. According to Freedesktop Radeon list almost all features are implemented into the driver, hybrid graphic cards run fine, only OpenGL needs more work. As the desktop ecosystem in the freedesktop environment modernize to support Wayland protocole, applications remain the issues.

I thank Mystro256 and the AMD contributors for their hard work in both Linux kernel and Mesa.


Posted by Nicu Buculei on February 14, 2017 07:08 AM
For the Valentine's Day, a thematic selection from my pictures at the on-going protests in Bucharest (the events are covered more in-depth in my photography blog)

For the curious, the images are processed with darktable, GIMP and now PhotoCollage.

PS: It looks like a bunch of other Linux geeks were there
linux protest

Not quite, actually: you’ll notice the extra line in the expanded one.

Posted by Suzanne Hillman (Outreachy) on February 10, 2017 03:50 PM

Not quite, actually: you’ll notice the extra line in the expanded one. I haven’t yet done the translation to div from table. I’m actually not sure how to make lines when not in a table!

Helping new users get on IRC, Part 2

Posted by Máirín Duffy on February 08, 2017 11:49 PM

Fedora Hubs

Where our story began…

You may first want to check out the first part of this blog post, Helping new users get on IRC. We’ll wait for you here. 🙂

A simpler way to choose a nick

(Relevant ticket: https://pagure.io/fedora-hubs/issue/283)

So Sayan kindly reviewed the ticket with the irc registration mockups in it and had some points of feedback about the nick selection process (original mockup shown below:)

Critical Feedback on Original Mockup

  • The layout of a grid of nicks to choose from invited the user to click on all of them, even if that wasn’t in their best interest. It drove their attention to a multiplicity of choices rather than focused them towards one they could use to move forward.
  • If the user clicked even on just one nick, they would have to wait for us to check if it was available. If they clicked on multiple, it could take a long time to get through the dialog. They might give up and not register. (We want them to join and chat, though!)
  • To make it clear which nick they wanted to register, we had the user click on a “Register” button next to every available nick. This meant, necessarily, that the button wasn’t in the lower right corner, the obvious place to look to continue. Users might be confused as to the correct next step.
  • Overall, the screen is more cluttered than it could be.

mockup showing 9 up nick suggestion display

We thought through a couple of alternatives that would meet the goals I had with the initial design, yet still address Sayan’s concerns listed above. Those goals are:

Mo’s goals for the mockup

  • Provide the user clues as to the standard format of the nicknames (providing an acceptable example can do this.)
  • Giving the user ideas in case they just can’t think of any nickname (generating suggestions based on heuristics can help.)
  • Making it very clear which nickname the user is going to continue with and register (in the first mockup, this was achieved through having the register button right next to each nick.)
  • Making it clear to the user that we needed to check if the nick was available after they came up with one. This is important becauae many websites do this as you type – we can’t because our availability check is much more expensive (parsing /info in irc!)

New solution

We decided to instead make the screen a simple form field for nick with a button to check availability, as well as a button the user could optionally click on to generate suggested nicks that would populate the field for them. Based on whether or not an available nick was populated in the field, the “Register” button in the lower right corner would be greyed out or active.

Initial view

Nickname field is blank.

mockup of screen with a single form field for nickname input

Nickname suggestion

If you click on the suggest button, it’ll fill the form field with a suggestion for you:

mockup of screen showing the suggest nickname button populating the nickname field

Checking nick availability

Click on the “Check availability” button, and it’ll fade out and a spinner will appear letting you know that we’re checking whether or not the nick is available (in the backend, querying Freenode nickserv or doing a /info on the nick.)

mockup showing nickname availability checking spinner

Nickname not available

If the nickname’s not available, we let you know. Edit the form field or click on the suggest button to try again and have the “Check availability” button appear.

mockup showing a not available message if a nickname fails the availability check

Nickname available

Hey, your nick’s not taken! The “Register” button in the lower right lights up and you’re ready to move forward if you want.

mockup showing the register button activating when the user's input nickname is in fact available

Taking a verification code instead

I learned a lesson I already knew – I should have known better but didn’t! 🙂 I assumed that when you provide your email address to freenode, the email they send back havs a link to click on to verify your email. I knew I should go through the process myself to be sure what the email said, what it looked like, etc., but I didn’t before I designed the original screen based on a faulty assumption. Here is the faulty assumption screen:

Original version of the email confirmation mockup which tells users to click a link in the email that doesn't exist.

I knew I should go through the process to verify some things about my understanding of it, though (hey, it’s been years and years since I registered my own nick and email with freenode NickServ.) I got around to it, and here’s what I got (with some details redacted for privacy, irc nick is $IRCNICK below:)

From "freenode" <noreply.support@freenode.net>
To "$IRCNICK" <email@example.com>
Date Mon, 06 Feb 2017 19:35:35 +0000
Subject freenode Account Registration


In order to complete your account registration, you must type the following
command on IRC:

/msg NickServ VERIFY REGISTER $IRCNICK qbgcldnjztbn

Thank you for registering your account on the freenode IRC network!

Whoopsie! You’ll note the email has no link to click. See! Assumptions that have not been verified == bad! Burned Mo, burned!

So here’s what it looks like now. I added a field for the user to provide the verification code, as well as some hints to help them identify the code from the email. In the process, I also cut down the original text significantly since there is a lot more that has to go on the screen now. I should have cut the text down without this excuse (more text, less read):

new mockp for email verification showing a field for entering the verification code


I still need to write up the error cases here – what happens if the verification code gets rejected by NickServ or if it’s too long, has invalid characters, etc.

Handling edge cases

(Relevant ticket: https://pagure.io/fedora-hubs/issue/318)

Both in Twitter comments and IRC messages you sent me after I blogged the first design, I realized I needed to gather some data about the nickname registration process on Freenode. (Thank you!) I was super concerned about the fragility of the approach of slapping a UI on top of a process we don’t own or control. For example, the email verification email freenode sends that a user must act on within 24 hours to keep their nick – we can’t re-send that mail, so how do we handle this in a way that doesn’t break?

Even though I was a little intimidated (I forget that freenode isn’t like EFnet,) I popped into the #freenode admin channel and asked a bunch of questions to clear things up. The admins are super-helpful and nice, and they cleared everything up. I learned a few things:

  • A user is considered active or not based on the amount of time that has passed since they have been authenticated / identified with freenode NickServ.
  • After the user initially registers with NickServ, they are sent an email from “freenode Account Registration” <noreply.support@freenode.net> with a message that contains a verification code they need to send to NickServ to verify their email address.
  • If you don’t receive the email from freenode, you can drop the nick, take it again and try again with another email address.
  • While there is no formal freenode privacy policy for the email address collection, they confirmed they are only used for password recovery purposes and are not transmitted to third parties for any purpose.
  • If a nickname hasn’t been actively identified with NickServ for 10 weeks, it is considered “expired.” Identifying to NickServ with that nick and password will still work indefinitely until either the DB is purged (a regular maintenance task) or if another user requested the nick and took it over:
    • The DB purges don’t happen right away, so an expired nick won’t be removed on day 1 of week 11, but it’s vulnerable to purge from that point forward. Purges happen a couple times a year or so.
    • If another user wants to take over an expired nick that has not been purged, they can message an admin to have the nick freed for them to claim.

This was mostly good news, because being identified to NickServ means you’re active. Since we have an IRC bouncer (ircb) under the covers keeping users identified, the likelihood of their sitting around inactive for 10 weeks is far less. The possibility that they actually lose their nick is limited to an opportunist requesting it and taking it over or bad timing with a DB purge. This is a mercifully narrow case.

So here’s the edge cases we have to worry about from this:

Lost nickname

These cases result in the user needing to register a new nickname.

  • User hasn’t logged into Hubs for > 10 weeks, and circumstances (netsplit?) kept them from being identified. Their nick was taken by another user.
  • User didn’t verify email address, and their nick was taken by another user.

Need to re-register nickname

These cases result in the user needing to re-register their nickname.

  • User hasn’t logged into Hubs for > 10 weeks, circumstances kept them from being identified. Their nick was purged from the DB but is still available.
  • User didn’t verify email address, and their nick was purged from DB but is still available.

Handling lost nicks

If we can’t authenticate the user and their nickname, we’ll disable chat hubs-wide. IRC widgets on hubs will appear like so, to prompt the user to re-register:

IRC widget with re-register nag

If the user happens to visit the user settings panel, they’ll also see a prompt to re-register with the IRC feature disabled:

mockup of the user settings panel showing irc disabled with a nag to re-register nickname

Re-registration process

The registration process should appear the same as in the initial user registration flow, with a message at the top indicating which state the user is in (if their nick was db purged and is now available, let them know so they can re-register the same nick; if someone else grabbed it, let them know so they know to make a new one.) Here’s what this will look like:

nickname registration screen with a message showing the expired nickname is still available


The cases I forgot

What if the user already had a registered nickname before Hubs?  (This will be the vast majority of Hubs users when we launch!) I kind of thought about this, and assumed we’d slurp the user’s nickname in from FAS and prompt them for their password at some point, and forgot about it until Sayan mentioned it in our meeting this morning. There’s two cases here, actually:

  • User has a nickname registered with Nickserv already that they’ve provided to FAS. We need to provide them a way to enter in their password so we can authenticate them using Hubs.
  • User has a nickname registered with Nickserv already that is not in FAS. We need to let them provide their nickname/password so we can authenticate them.

I haven’t mocked this up yet. Next time! 🙂

Initial set of mockups for this.

Feedback Welcome!

So there you have it in today’s installation of Hubs’ IRC feature – a pretty major iteration on a design based on feedback, some research into how freenode handles registration, some mistakes (not verifying the email registration process first-hand, forgetting some cases), and additional mockups.

Keep the feedback coming – as you can see here, it’s super-helpful and gets applied directly to the design. 🙂

Social Media and photo sharing platform survey

Posted by Suzanne Hillman (Outreachy) on February 08, 2017 09:14 PM

Hey, you remember how I said I was working on a survey to figure out what social media and photo sharing platforms to integrate with Hubs?

It’s finally ready for people to fill out!

So. If you use Fedora, anywhere in the world, please fill out my survey! This will help us prioritize the platforms to integrate with Hubs. Thank you so much!


Please, spread the word! The more responses, the better, and as many different places around the world as possible.

The CSS is getting closer.

Posted by Suzanne Hillman (Outreachy) on February 07, 2017 10:15 PM

I’ve been working more with the Mockup-to-CSS project, and I’m certainly closer.

For one thing, the progress bars are divs, which don’t really like going into tables nicely. However, with much investigation (and playing with the code using CodePen), I found an explanation of the problem. Took me a little while to figure out how to adjust the code appropriately, but I did succeed on that point.

The next bit of complication was deciding the best way to handle the “view all team badges” link, in terms of placement. I ended up deciding to have blank space for the first half of the space, and the view link in the second half of the space. In other words:

<div class=”row”>
<div class=”col-xs-6">
<div class=”col-xs-6">
<p class=”viewall”><span class=”callout”><a href=#”>View All Team Badges></a></span>

And yes, the links are all invisible. I’m ignoring that for now, because it was true for the stuff that Mo did, as well.

<figure></figure><figure><figcaption>Left, Mockup. Right, web screenshot. Closer!</figcaption></figure>

I need lines between some, but not all of the rows in the table. I was already starting to think that I should just drop tables and do it all in divs, because it got messy. Mo confirms this need, so that’s next to play with.

I also still need to figure out the excessive space between the badge images and the text, make the badges in the design mission area smaller so they fit on a row, make the trophy icon larger, and make “of 15 team members” stay where it belongs.

But! This is much closer than my last attempt. Codepen helped a _lot_ with being overwhelmed, since I could see immediate changes. Not all the relevant CSS was there, but it was good enough for investigation purposes.

Refugee Hope Box

Posted by Máirín Duffy on February 07, 2017 07:55 PM

I’m not sure that I’ve ever posted anything non-Fedora / Linux / tech in this blog since I started it over 10 years ago.

My daughter’s school is running a refugee hope box drive. The boxes are packed full of toiletries and other supplies for refugee children. We will drop our box off at school and it will get shipped to the Operation Refugee Child program, where its contents will be packed into a backpack and delivered to a child in the refugee camps. We decided to pack a box for a teenage girl. It includes everything from personal toiletries, to non-perishable snacks, to some fun things like gel pens, markers, a journal, and Lip Smackers.

We explained to our daughter that there are kids like her who got kicked out of their home by bad guys (“Like the Joker?” she asked. Yep, bad guys like him.) There’s one girl we are going to try to help – since she is far away from home and has almost nothing, we are going to help by sending some supplies for her. My daughter loved the idea and was really into it. We spent most of our Saturday this past weekend getting supplies out and about with the kids, until the kids kind of melted down (nap, shopping cart fatigue, etc.) and we had to head back home.

We were so close to being finished but needed a few more items to finish it up, so I set up an Amazon wishlist for the items remaining and posted it to Twitter. I figured other folks might want to go in on it with us and help, and I could always pick up anything else remaining later this week.

It seriously took 22 minutes to get all of the items left to order purchased. I’m totally floored by everyone’s generosity. Our community is awesome. Thank you.

If you would like to help, you can start your own box or buy an item off of the central organization’s Amazon wishlist.

CSS Part two

Posted by Suzanne Hillman (Outreachy) on February 06, 2017 05:47 PM

This post is a continuation of my CSS journey. In this one, we finish identifying what we do and do not know about team badges, make note of aspects of the mockup that are confusing, Mo explains our use of Bootstrap for responsive design and her best practices in mockup-to-CSS tasks, and I take a shot at writing some CSS.


Our goal is to get me practice with using CSS by translating the Inkscape mockup in ticket #17 into CSS.


Last time, we got me set up with a clone of the relevant pagure developer repository, learned more about the syntax and structure of the HTML, PY, and CSS files, and explored the content of the sample JSON infomation.


We reviewed what we had learned the previous session, and identified necessary information that we did not yet have access to, including:

  • information about non-series badges for a team
  • the most recent badge earner
  • the most recently earned badge earned by the most recent badge earner.
  • the number of badges ranking of a particular user compared to the rest of the team

We had reason to believe that information about the non-series badges for a team would be enough to allow us to identify the most recent team badge a user earned. However, that is another requirement for the mockup that was not yet available.

We also identified some confusing aspects of the mockup as it is:

  • The number of team badges listed should also show the number that user has, so they know how many remain to get
  • “Open and non-mission badges” needs to be rephrased. It almost certainly is supposed to refer to badges that are not part of a series that the user does not yet have.
  • “Team Badge Rank” is unclear, and should be something like “Your Team Badge Rank” to be clearer.

Into the code

To start, Mo suggested creating the CSS/HTML such that it is hard-coded to reflect the mockup. Once it looks right, we can add in appropriate calls to actual data.

She reminded me of the ticket for individual badge mockup that she’d already done the CSS/HTML for.


Mo also explained more about Bootstrap to me. I’d heard of it, but had very little knowledge of it. Hubs is using the responsive aspect of Bootstrap (see the Responsive Breakpoints section), which is also explained here, specifically the row and col classes. The col class includes pieces which are specific to each device size (xs, sm, md, lg, xl), with xs being the default if nothing is specified.

Each piece of the page (in our case, our widget) is split into 12 columns, such that one can determine how much of the space available to that piece any individual component will take up. This is very useful when doing responsive design, since you want to be able to say approximately how the page behaves when page sizes change.

To get an understanding of this, we used Mo’s individual badge widget code with the Developer Tools->Responsive Design Mode in Firefox. This meant that I could see what was happening when we changed screen sizes. For example, when we started moving down from the largest size screen my monitor could handle, at around 988 width the description of a badge went from next to it to below it.

The relevant code says that the badge should take up 4 columns at large size, 12 at medium, and 2 at small:

<figure><figcaption>Large size, badge 4/12 and text 8/12 of the space</figcaption></figure>
<div class=”col-lg-4 col-md-12 col-sm-2">

The description of the badge should take up the remaining 8 (of 12) columns at large size, all 12 (an entire column, thus forcing it below the previous piece) at medium, and the remaining 10 at small.

<figure><figcaption>Medium size, badge and text both 12/12 of the space</figcaption></figure>
<div class=”col-lg-8 col-md-12 col-sm-10">

What would Mo do?

After explaining bootstrap and responsive design, Mo explained that she usually codes the laptop/desktop-sized version, first, and then plays with the responsive design mode in Firefox to see what needs adjustment in other modes (according to the code we found, in Hubs, those breakpoints are lg = 1200, md = 992, sm = 768, xs = 544). She also noted that Bootstrap will apply smaller sized col attributes to larger ones, such that if you have a xs version, that will apply to everything larger that isn’t specified. But, if you only have xl, the smaller sizes will probably break.

She described the ‘row’ classes as being hard line breaks, with the col settings allowing different line breaks for different size screen based on how much of the width of 12 any particular piece uses.

She also mentioned that she tries to avoid overusing classes, and usually uses the ones in bootstrap (col, row), and descriptive classes. The latter includes things which you might want to reuse, like color codes to be consistent across Fedora, badge styles, or the style of the detail that goes with a badge.

Similarly, she mentioned the need to use header tags rather than “<strong>” or specifying text sizes, so that people using screen-readers can more easily skim the document and get where they want to go. I already know a bit about accessibility (a11y), but a reminder is always good.

My turn to try

At this point, I started changing the code in our shared etherpad, as I wanted her eyes on what I was doing. I’m sure that it’ll be a little easier in an actual IDE, but harder for her to see what I was doing.

One thing that I had trouble with is actually hard-coding things. For example, the missions in the team badge widget look like they should be expandable:

<figure><figcaption>This looks like you should be able to expand it!</figcaption></figure>

However, at least initially, I was to be trying to hard-code everything, including the expansion-appearance. This was possibly more confusing than it might otherwise have been, since the code I was editing from (the individual badges widget) actually had expansion capability because there were two separate mockups.

I also needed to figure out how to make progress bars. Mo found some in bootstrap, which were easy enough to use. She found the relevant CSS that actually made them display the bars in the upstream Bootstrap code, as it was missing from our version of it. Unfortunately, and I haven’t yet figured out why, they don’t seem to want to be where I thought I put them in the code. Neither do the badges:

<figure></figure><figure><figcaption>Mockup vs current CSS — Still learning!</figcaption></figure>

It’s a decent start, but I definitely found it much too easy to get lost in the details and forget what I was trying to do and why. I’m very glad that I had code to change, rather than needing to create new code, however. I also still need to add the percentages at the end of the incomplete progress bars, and the trophy icon in green to the complete one.

And the spacing is weird between the badges and their details, I’m missing the link to ‘view all badges’ (Actually… all of the user’s badges? All of the team badges?), and the mission titles need a different look.

Still, though. I have started, and I can and will certainly play with this more. Still not a huge fan of writing code, and I wonder how much of this is how distracted I get by all the details. Getting lost in excess information is a known difficulty for me, which is why I try so hard to make my surroundings organized.

Helping new users get on IRC

Posted by Máirín Duffy on January 31, 2017 11:04 PM

Fedora Hubs

Hubs and Chat Integration Basics

Hubs uses Freenode IRC for its chat feature. I talked quite a bit about the basics of how we think this could work (see “Fedora Hubs and Meetbot: A Recursive Tale” for all of the details.)

One case that we have to account for is users who are new Fedora contributors who don’t already have an IRC nick or even experience with IRC. A tricky thing is that we have to get them identified with NickServ, and continue to identify them with Nickserv seamlessly and automatically, after netsplits and other events that would cause them to lose their authentication to Nickserv, without their needing to be necessarily aware that the identification process was going on. Nickserv auth is kind of an implementation detail of IRC that I don’t think users, particularly those new to and unfamiliar with IRC, need to be concerned with.


“Nickserv? What’s Nickserv?” you ask. Well. Different IRC networks have a nickserv or something similar to it.

On IRC, people chat using the same nickname and come to be known by their nickname. For example, I’ve been mizmo on freenode IRC for well over a decade and am known by that name, similarly to how people know me by my email address or phone number. IRC is from the old and trusting days of the internet, however, so there’s nothing in IRC to guarantee that I could keep the nick mizmo if I logged out and someone else logged in using ‘mizmo’ as their nickname! In fact, this is/was a common way to attack or annoy people in IRC – steal their nick.

In comes Nickserv to save the day – it’s a bot of sorts that Freenode runs on its IRC network that registers nicknames and provides an authentication system to password protect those names. Someone can still take your nick if you’re offline, but if you’ve registered it, you can use your password and Nickserv to knock them off so you can reclaim your nick.

Yes, IRC definitely has a kind of a weird and rather quaint authentication system. Our challenge is getting people through it to be able to participate without having to worry about it!

Configuration Questions

“Well, wait,” you ask. “If they aren’t even aware of it, how do they set their nickserv password? What if they want to ‘graduate’ to a non-hubs IRC client and need their nickserv password? What is they want to change their password?”

I considered having Hubs silently auto-generate a nickserv password and managing that on its own, potentially with a way of viewing / changing this password in user settings. I opted to provide a way to create their own password, ultimately deciding that silently generating it, they wouldn’t be aware it existed, and may end up confused if they tried a different client and might post their FAS password over non-SSL plaintext IRC…

(Some other config we should allow eventually that we’ve discussed in the weekly hubs meetings – allowing users to use a different IRC bouncer than Hubs’ for IRC, and offering the connection details for our bouncer so they could use Hubs as a client as well as a third party client without issue.)

The Mockups

So here is an attempt to mock up the workflow of setting up IRC for a Hubs user who has never used IRC before, either on Hubs or ever. Note these do not address the case of someone new to Hubs who hasn’t enabled the RC feature but who does have a registered nick already that they have not entered into FAS – these will need modification to address that case. (Namely a link on the first screen to fill out their Nickserv auth details in settings.)

Widget in Context

This is what the as-of-yet unactivated IRC widget would look like for a user in context. The user is visiting a team hub, and the admin of that hub configured an IRC widget to be present by default for that hub. To join the chat, the user needs to enable IRC as a feature for their account on hubs so the widget offers to do that for them.

mockup of a fedora hubs screen showing a widget on the right hand side for enabling IRC chat

Chatter thumbnails

The top of the widget has a section that has small thumbnails of the avatars of people currently in the room (my thought is in order of who spoke most recently) with a headcount for the total number of people in the room. The main idea behind this is to try to encourage people to join the conversation – maybe they will see a friend’s avatar and feel like the room could be more approachable, maybe we tap into some primal FOMO (Fear Of Missing Out) by alluding to the activity that is happening without revealing it.

Call to action

Next we have a direct call to action, “Enable chat in Hubs to chat with other people in this hub” with an action-oriented button label, “Enable Hubs Chat.” This, I hope, clearly lets the user know what would happen if they clicked the button.

Hiding control

At the bottom, a small link: “Hide this notification.” Sometimes ‘upsell’ nags can be irritating if you have no intention of participating. If someone is sure they do not want to enable IRC in Hubs (perhaps they just want to use their own client and not bother with Hubs for this,) this will let them hide it and will ‘roll up’ the IRC widget to take up less space.

Here’s a close-up of the widget:

closeup of the IRC activation widget

Registration Wizard

So once you’ve decided to enable IRC in Hubs, then what?

Since selecting and registering a nick I think needs to be a multi-step process (in part because Freenode makes it one), I thought a wizard might be the best approach so this is how I mocked it up. A rough outline of the wizard steps is as follows:

  • Figure out a nickname you want to use and make sure it’s available
  • Provide email address and password for registration
  • Register nickname
  • Verify email

Choosing a nickname

This is a little weird, because of how IRC works. Let me explain how I would like it to work, and how I think it probably will end up working because of how IRC & nickserv work.

I would like to present the user with a bunch of options to pick from for their nickname. I want to do this because I think coming up with a clever nickname involves a high cognitive load they may not be up for, and at the very least offering suggestions could be good brain food for them making up their own (we offer a way to do that on the bottom of this screen, as well.)

Ideally, you wouldn’t offer something to someone and then tell them it’s not available. Unfortunately, I don’t think there’s an easy way to check whether or not a suggested nick is available without actually trying to use it on Freenode and seeing if you’re able to use it or if Nickserv scolds you for trying to use someone else’s registered nick. I don’t know if it’s possible to check nick availability in a less expensive way? These designs are based on the assumption that this is the only way to check nick availability:

mockup: irc nick selection

The model here is that we’d use some heuristics based on your name and FAS username to suggest potential nick, with a freeform option if you have one in mind. If you click on a name, we then check it for availability, displaying a spinner and a short message while we check. This way, we only check the nicks that you’re actually interested in and not waste cycles on nicks you have no interest in.

If a nick is available, it turns green and we display a “Register” button. If not, a message to let them know it’s not available:

IRC nick availability mockup

Once it’s finished checking on all of the nicks, it might look like this:

IRC nick availability mockup - all lookups complete

Provide email and password for registration

Freenode Nickserv registration requires providing an email address and a password. This screen is where we collect that.

We offer to submit their FAS account email address, but also allow them to freeform the email address they’d prefer to be assocaited with Freenode. We provide the rationale for why the email address is needed (account recovery) and should probably refer to Freenode’s privacy policy if it has one for their usage. There’s also fields for setting the password.

Verify Email Address

This is the most fragile component of this workflow. Freenode will allow you to keep a registration for 24 hours; if you do not confirm your email address in that time, you will lose your registration. Rather than explain all of this, we just ask that users check their email (supplying them the address the gave us so they know which account to check) and verify the email address using the link provided.

Problem: We don’t control these emails, freenode does. What if the user doesn’t receive the verification email? We can’t resend the email because we didn’t send it in the first place. No easy answer here. We might need some language to talk about checking your spam folder, and how long it might take (it seems to be pretty quick in testing.) We could let them go ahead and start chatting while they wait for the email, but what would we do if it never gets verified and they lose the registration? Messy. But here’s the mockup:

Screen for user to confirm email address for freenode registration


This is just a screen to let them know they’re all set. After clicking through this screen, they should be logged into the IRC channel for the hub they initiated the registration flow from.

IRC registration finish screen


This is a first-cut at mocking up this particular flow. I’m actively working on other ones (including post-set up configuration, and turning IRC on/off on individual hubs which is the same as joining or leaving a channel.) If you have any ideas for solving some of the issues I brought up or any feedback at all, I’d love to hear it!

CSS and mockups

Posted by Suzanne Hillman (Outreachy) on January 31, 2017 07:37 PM

I want to get a better feel for CSS, so Máirín Duffy (Mo) and I spent three hours last week figuring out how to moving a pixel perfect mockup to CSS. This was made up almost entirely of background stuff, but we got a lot of useful information in the process. We will continue working on this sometime this week.

Git and Pagure

The first hour or so was spent fighting with git and making me a fork of a fork of the main repo.

In short, I had to:

  1. make sure my SSH key was in pagure,
  2. tell local git about the fork using “git remote add -f sayan ssh://git@pagure.io/forks/sayanchowdhury/fedora-hubs.git”,
  3. grab the fork with “git checkout badge-path-support”,
  4. use the webui for pagure to tell it to create me a fork, and
  5. finally “git remote add -f wispfox ssh://git@pagure.io/forks/wispfox/fedora-hubs.git” to push my fork.

There were many other complicated aspects that I will figure out later.

What are we trying to do?

She gave links to the ticket we were planning to work on (https://pagure.io/fedora-hubs/issue/17), and pointed me at the specific mockup we were going to try translating (the team badge widget):


She also pointed me at one she had already done (the individual badge widget, https://pagure.io/fedora-hubs/issue/85):


Mo pointed me to the HTML that she’d done for this widget, and pointed me to where that HTML was injected into other HTML.

Exploration and Explanation

Mo explained that hubs is built with python, using a platform called flask, which uses a templating system called jinga. As a result, the templates in question are written in jinga.

The entire site is written in fragments which are then combined together appropriately to create the page. She then mentioned that in flask, each widget has a .py file, and a corresponding template in HTML, and CSS pulled from the main CSS file.

We started looking for the team badges (badgespath.py) file so that we could start working, and figured out that it was actually in a developer fork. Once that was done, she suggested I use the IDE geany to open the py file and the badgespath.html file. She opened an etherpad and pasted what she had in her html file into it, as she’d already started working on this task.

To see what was going on with what she’d been playing with, I saved her changes to the file, and started a local Hubs instance. I logged into it, and added the team badges widget to my profile page (since I didn’t have permissions to the design hub). This resulted in a great deal of messy-looking output, which Mo explained was JSON output. After a brief divergence to explain what that was and fight with IRC, she explained the code she’d had me paste into the file.

Because we can have multiple of the same widgets in a page, she uses “class” instead of “ID” to label each widget in CSS. Then there’s jinga logic, which is python syntax surrounded by {% %}. The badge and series_info variables were referring to things defined in the badgespath.py file.

She then explained the py file contents, including that import and from relate to libraries, argument says what information the widget requires from the user, def defines a function (in this case, one called data which takes in session, widget, and username as arguments). The function data had a username and team_id hardcoded for testing purposes; the team_id will be found by looking at which hub the widget is being added to in the real code, no need to ask the user for that information.

The data function is grabbing a bunch of JSON info, and splitting it into useful pieces, including badges_count and series_info. This information is then stored in a dict, returned, and available to anything requests it; in this case, our original badgespath.html file.

What Mo was trying to do in the html file was get a sense of the JSON info. So she added some debugging info (commenting out the stuff in the for loop, adding labels to badges count, series info, and badges), and we restarted the server to see what we got. We then tried taking a look at the JSON output in a JSON parser, and found out from a developer in channel that our output was in need of running through a dictionary.

After a great deal of investigation and confusion and talking to the developer who made the fork, it turned out that the JSON information we were getting was a local file because the information we needed about teams badges per user was not in the production environment.

What we learned

As a result of this session, we learned that:

  • The series_info file contains information about badges that are in series’ for a particular team.
For example, a series in the infrastructure team has a badge for having a FAS account for a year, having one for two years, having one for three years, having one for five, for seven, and finally for ten.
  • “is_awarded” in the series_info data identifies the badges a particular user has in that series,
  • badges_count is the total number of series badges for that team (but it doesn’t yet tell us how many non-series badges that team has), and
  • ‘series badges’ is a set of badges that are related to Missions in the mockup.

Sometimes it’s good to stop worrying about the world and just work on my internship

Posted by Suzanne Hillman (Outreachy) on January 31, 2017 07:15 PM

As I’m sure many of you know, living in the US is worrying right now. It’s been a bit difficult to focus on the internship as a result!

However, organizing my thoughts to describe what I’m currently working on and have been working on since my last post is always a good idea. Let’s get to it!

What Have I Been Doing?

A lot, as it turns out. It can be a little difficult keeping track of it all, which is clearly why I should be blogging more. Asana (a task list) to the rescue!

Lots of mockups

The first thing I did was actually part of what I did two posts ago: lots and lots of mockups. I’d had some experience creating mockups, which made this quicker than it might otherwise have been. I’d also attended the Inkscape Workshop last summer, which gave me some useful keystrokes and tips that made it quicker to use. Still, though, mockups are not fast. But, faster using Balsamiq than if I tried to do mockups using inkscape.

The affinity mapping and brainstorming post contained a bunch of initial mockups which I basically threw together to try to cover the things we came up with during brainstorming. Máirín Duffy (Mo) reviewed and commented on each of those, both in the ticket and sometimes in IRC, email, and other such places.

Each of the tickets in question has more detailed information: master list of Fedora people, master list of events, notifications, joining regional hubs.

Location information turned into an unexpectedly complicated problem as per my previous post, and spawned a new ticket to figure out how Hubs would suggest new regional hubs.

I also created a number of tickets that I do not expect to be able to get to during this internship, but which were clearly necessary to keep in mind around this project: public-facing pages, event creation (for which I am trying to brainstorm some general thoughts on fields from my interview notes), bringing people back to hubs, master list of regional hubs.

Restructure of schedule

Around halfway through the internship, I began to wonder if we’d be able to get through the entire set of tasks we had put into the preliminary schedule. As a result, I asked Mo if we could talk about the schedule and how feasible it actually was. I was feeling a little behind, and was having trouble determining if in fact we had been too optimistic, or if I was simply not getting enough done.

As a result of this discussion, we identified tasks that we definitely wanted to get done by the end of the internship. We also listed some that I’d like to at least touch on. We retained the major goals of: prototype usability testing, feasibility discussion with the lead developer, analysis of the usability testing and feasibility discussion, and an overall summary of what was found through these. In addition, we decided to do some work to give me experience with visual design and CSS.

Mockup Feasibility

I scheduled time to talk with the lead developer over IRC, having sent him links to the tickets with mockup that I wanted to discuss. As is apparently the norm for me, I was very nervous about this discussion. I blame impostor syndrome, as everyone in Fedora Hubs has been very welcoming and approachable.

For the most part, his response to the mockups was that they were feasible. There were a couple of instances where more research was needed.

In one case, he wanted to do make sure that he could show who was online in a lightweight and reasonable fast way, given that one could change the search or the map dynamically.


In another, he needed to figure out how to dynamically do searches/filters that listed only people (or events) within x miles/km of a person or location.


As with the locations information discussion with Mo, talking about the locations mockup with our lead developer turned out to be a bigger thing than I was expecting. Indeed, I created a new ticket (as mentioned in the mockups section) to remind us that we needed to figure out how Hubs would handle suggesting new regional hubs. That conversation still needs to happen, and I’m not completely sure that it will before my internship is done. However, without that ability, regional hubs will become much less useful.

My takeaway so far is that location stuff is really hard. Which, had I thought about it, would have made a lot of sense! I just somehow… didn’t consider it in great detail. This would be why UX isn’t done in a vacuum!

Social Media and Photo sharing

We are hoping to identify which social media and photo sharing platforms Fedora members use to discuss Fedora and Fedora events. This information would allow the prioritization of plugins to pull info from and maybe push info to various types of social media and photo sharing platforms.

If we can do this, it would make it a lot easier to keep information about an event in one place, whether because attendees want to share with each other, or because organizers need to create event reports. As below, having the option to have the media in one place would be really useful.


I am nearly finished with a survey about social media and photo sharing platforms that I intend to post to this blog and ask people within Fedora to share widely. The more information we have, the more easily we can identify the key platforms to incorporate. My initial interviews suggest that location will affect which platforms are in use, especially given countries in which the norm is phone use, not computer use. As such, having that survey spread around will help a great deal.


A very important part of the UX process is user feedback. Once I had a reasonable number of mockups that Mo had taken a look at and provided some initial feedback on, I needed to get those in front of some users.

I originally tried to get in touch with my first interviewees, but they were largely unresponsive. Instead, after discussing with Mo, we identified people who might be good candidates, and I got in touch with them. Three of the four I contacted have gotten back to me, and I did the first usability study last night. Went well, but given my lack of experience in doing usability testing, I was nervous. I need to go through the video and take notes, as I found it impossible to pay attention to my participant and take notes during the usability session.

I found it challenging to identify tasks for my mockups, so I listed out a general idea of what was possible for each. This was based on my experience in quality engineering, and I found myself too easily getting into irrelevant details. Annoying, but still a good way to start.

From that list, I created a basic list of possible tasks, and sent those to Mo for feedback. Unsurprisingly, most of my tasks were not concrete enough and were likely to confuse people. She made suggestions for the kinds of things she would have done. For example, instead of:

Task: You are new to the area, and hoping to find an event nearby to go to. Please use this prototype and explain to me what you will be doing while trying to find this event.

She suggested:

Task: You’ve just moved to the Los Angeles, California area. You’re hoping to find a Fedora event nearby to go to, to find new local Fedora friends. Please use this prototype…. (same text as orig)

These kinds of concrete examples made it much easier to finish creating tasks.

I found myself stuck identifying which tasks were higher priority than others. With a bit of prompting from Mo, I used the same box diagram thing that we’d used after our affinity mapping. I listed numbers of people affected on one axis, and how often people would run into the interface on another. This helped me organize the mockups themselves, and then the tasks, and made it much easier to see which were more important to get eyes on. I discussed my thoughts on this briefly with Mo again, who provided useful feedback.


While planning the task list, I was also considering how to do the prototyping remotely. Originally, to avoid bandwidth problems, we were considering trying to send prototypes to people and have them walk through it and talk to me through IRC. The more I thought about this, the more concerned I got. First, having to change between a prototype and IRC to communicate seemed very disruptive. Second, not being able to see what they were doing with the prototype seemed like a huge problem.

After additional discussion with Mo, she pointed out the existence of MyBalsamiq. I hadn’t really thought about the fact that there must be a web-based interface, and that it might support web-based prototyping. After some investigation, Mo got a free web license for Fedora, and I moved my relevant prototypes to that platform. Between MyBalsamiq’s prototyping methods and google hangouts, remote prototyping became much more plausible.

I will also get some in-person prototyping experience with people who are at Mo’s office, although I am still working on scheduling those people.

Visual Design

I do not have a lot of experience with visual design, and sometimes find it baffling. I suspect that having the Designing Interfaces by Tidwell book that Mo suggested will help with this, as well as with mockups.

To get me a feel for how it might work, Mo has converted one of my Balsamiq mockups to the existing visual design. I have not yet had a chance to take a look at this, but am hopeful it will help give me a better sense of how that might work. I will then try my hand at doing the same thing with a different mockup.

My initial forays into CSS will be in another post, simply because this post is long enough.

Locations are hard

Posted by Suzanne Hillman (Outreachy) on January 20, 2017 05:17 PM

Turns out that figuring out people’s locations is hard, especially if you want to try to reduce the amount of work someone has to do or if they are likely to be using a mobile phone.

For some reason, I’d thought that this was already a solved problem, so was somewhat surprised when feedback on a mockup made me question that assumption. After pinging Máirín Duffy to find out if we had access to a database of countries, and how they break down into cities/states/provinces/etc, she realized that we needed a longer discussion.

One thing she wondered was if we actually need street addresses. Given that the goal is to be help people find each other nearby, city was almost certainly sufficient for that purpose.

In many cases, especially on mobile, we would have access to GPS information. So, in that case, we can just show them where we think they are — with a map on which we overlay the city and country information and in which we will make sure that that information is appropriately accessible — and they can adjust as necessary.


On computers, we may have access to the information provided by the web browser, and from that we can similarly show them a map with their city and country information. In this case, we may end up being wildly inaccurate due to people using VPN connections.

In both mobile and computer cases, people may not want to share that level of detail. So, for this case, we would use their IP address information to guess, and display the same thing.


Finally, it is entirely possible that a connection error would prevent us from actually having location information. In that case, we would show a zoomed out map on a computer, with empty city and country fields. On mobile or if we cannot tell where they are, a blank map, with empty city and country fields.


In all cases, people can edit the country and city information to make it more accurate. The ‘city’ field will offer type-ahead suggestions which will include any division between city and country that is relevant. For example, if someone is detected as being in Buffalo, NY, but is actually in Boston, MA, we would offer then Boston, NY first, due to proximity, but also show Boston, MA. And anyone can continue typing to get more specificity, or select from a list of visible options. If, however, the country field is incorrect, they will need to change that before the city suggestions will be correct. As with the map location information, type-ahead suggestions need to be appropriately accessible to people who cannot use a mouse or cannot see the suggestions.

The problem with the type-ahead suggestions is that we still need access to a database which contains that information for each country. There are a couple of options, but that problem remains to be solved, and is a large part of making location information actually workable.

This was an unexpectedly complicated discussion, but I’m very glad we had it. For more information, please see issue #286.

Affinity Mapping and brainstorming

Posted by Suzanne Hillman (Outreachy) on January 10, 2017 09:15 PM

First, Affinity Mapping

On Tuesday Mo (Máirín Duffy) and I did affinity mapping using realtimeboard.com (this is a well-designed tool for remote whiteboarding), the end results of you can see here. We started with sticky notes each of which contained a problem I identified from my research.

We then started trying to sort the stickies into groups. I initially found it difficult to stop thinking in terms of the categories I had already been noticing during earlier analyses of the data. This is almost certainly why it’s useful to have other people to do this task with! Mo jumped right in and started moving things around. Once we had figured out any groups at all, things started falling into place and becoming easier to sort. She ended up labeling most of the groups, which probably makes sense given that this was my first time doing this task. We were not discussing our choices at this point, which I suspect is an important part of this task. Just do the sorting, and figure out what it means later!

Next, Prioritization

After we’d created our groups, making sure that no group was obviously absurdly larger than the others, our next goal was to prioritize those groups by severity and number of people affected.

During the prioritization, Mo and I were doing a lot of talking (which you can see in the log file I linked on the pagure issue). She first described our task, and then made a simple box chart into which to put the group names, with one axis being severity and the other being affected numbers of people.

We then discussed our feeling on how severe each group was, and how many people were affected. It was not necessarily obvious in the box chart, but there was some gradation within each category (we have ‘low’ and ‘high’ severity, and ‘many’ and ‘few’ people). Some things that were high severity were less high than others, for example.

At the end of this task, we determined that Budget Stuff and Local Resource Finding and Scalability were our priority for this release. We also decided that the next release should include Localization and User Onboarding, plus whatever came up between now and then.

Deep Dive/Brainstorming

On Wednesday, we took a close look at our two high priority groups for this release. The end goal here was to figure out what was actually possible to do, what the goals for those were, how success would be measured, and the specific tasks I would need to do to address those goals.

We took two hours to do brainstorming in the IRC channel, and Mo thought to turn on the meetbot logging tool (Summary is here, Chat log is here) shortly after we had decided that the budget stuff had too many unknowns for us to be tackling in this release.

While budgeting will not be a priority during this release, we intend to keep it in mind during the design process to offer some basic support. For example, events created through Hubs should provide fields in events for budgetary data like allocation, actual costs, and investment returns.

Local Resources

We then looked at the other prioritized group for this release: Visibility, scalability, and findability of local resources. Or, as Mo put it, it’s currently difficult to find or know about many Fedora resources, including people and events. This really seems to be the core of what hubs is about.

Getting our minds around this was a _huge_ task, and needed a lot of breaking down into smaller pieces. Happily, that group had existing sticky notes referring to the problems that I’d found in my research.

So, we started going through those notes, one by one.

Note 1:

“There are a lot of different places that have information about Fedora-related events. This can make it difficult to know if you can’t find any nearby because they don’t exist, or because you haven’t looked in the right place. This makes it difficult to prioritize event attendance. There are also many different places to find non-Fedora-related but relevant events, which makes it difficult to prioritize Fedora sponsorship.”

We discussed the need for making the system attractive, useful, and inviting so that people actually use it. Otherwise, it’d end up being yet another place data is scattered to.

We considered the idea of pulling in Fedora events from other places, to make it more canonical in the short term. Unfortunately, most of the event information is in blog posts and mailing lists and wiki pages. None of these are especially easy to scrape those events from. Given that hubs will integrate blog posts and mailing lists into its notifications, it is theoretically possible that we’d be able to scrape event information from those, and then suggest adding them to the Fedora event calendar. However, as this is not an easy task, we are not focusing on it right now.

Mo suggested that our goal for the local resources topic as a whole should be:

if someone is looking for fedora-related stuff local to them, they will log into hubs, do a search or browse, and find the info they are looking for in regional hubs

And that a measurement of success in this goal would be that regional hubs would provide a canonical list of local resources — people and events.

This suggests the need for a filterable, sortable master list of all regional hubs, members, and events.

Task: This means I need to make mockups of and tickets for the interfaces for the lists for hubs, members, and events.

The rest of the brainstorming session resulted in a clearer understanding of the interfaces for the members and events lists.

Note 2:

"It would be useful for us to tie Hubs into social media so that people can access the types of social media that is popular in their countries if they want to do so (not everyone uses IRC natively). Eg Twitter, facebook, telegram, Eventbrite, instagram"

We discussed the use of the feed widget to support this. We already plan to have it support blog posts and mailing lists, as stated earlier, and this would be a perfect place to include social media posts.

My task for this note is to compile a list of regions and their social media preferences. I will need to connect with my interviewees (and perhaps others?) to confirm my existing information on this topic and check if I’ve missed anything. After that point, I plan to create tickets for the integration of both reading from and posting to those social media outlets.

Note 3:

"Many ambassadors are local resources for their local Fedora community. It may be useful to make as many as possible of those resources easily available without having to go through an overworked ambassador."

We discussed the various ways in which the ambassadors that I spoke to acted as resources for their communities. We came up with a lot of ideas on how to handle the various types of resources that were relevant, as per the following:

  • A FAQ per each regional hub, where local ambassadors can list the questions and answers they get asked repeatedly and point to those to potentially save time and reduce burnout.
  • each regional hub could have a library widget with commonly asked-for resources (forms, design assets, etc)
  • a widget that points to release-specific assets of interest to regional folks (release party posters, media art, etc)
  • event widget that creates an event on fedocal and also gets added to the master events list to enable regional people to create local events
  • volunteer recruitment / sign up / tracking built into local events
  • work with commops to develop general best practices / training for regional ambassadors, and enable local organizers to fork their own version of those guidelines with local details
  • some kind of way to store a list of local external resources: local vendors + venues

This list of ideas never really got to a resolved state, possibly because this was a very large topic area. We may need to revisit this note and these ideas to come up with actual tasks.

Note 4:

It is difficult to find Fedora members who are in a specific location, especially if they are not ambassadors.

This was largely covered by the master list of people, but it did get us thinking in more detail about how that should work.

We need both a list view and a map view for this search, as identified during the discussion of Note 5 below.

We decided that the list should show everyone with a FAS (Fedora Account System) account, even if they have never logged into Hubs. However, if they’d never logged in, they should be near the end of results as it’s difficult to tell how active they are. We similarly concluded that we should put people who haven’t recently logged into Hubs near the end of the Fedora members master list. We also plan to include ways to visually differentiate between people who are actively involved in Hubs, people who haven’t logged in in a while, and people who never logged in.

Finally, from a conversation we had about note 5, we need to make sure that filtered results are very obviously filtered. That way no one gets distracted, comes back, and wonders why there are so few results.

The following is a quick mockup of what the master people list search page might look like:


The next part is a quick visual for what search might look like for that list.


See ticket #279 to follow along.

We agreed that part of making people be findable was have them be part of regional hubs. As such, we would suggest that they join local regional hubs, and that local regional hubs get suggestions to directly invite people who are nearby and not already members. This would need to be in the notifications area or a widget, rather than in the master list.

We would like to have a way to tell when a Fedora person isn’t active (is cobwebbed, if it were a website instead of a person).

This harkens back to an earlier conversation: there is no way to differentiate between ‘temporarily inactive’, ‘inactive but wants to know what’s going on’, ‘actively doing things in the Fedora community’, ‘interested in doing things in the Fedora community but needs guidance’, ‘no longer part of the Fedora community but available for questions’, and ‘I’m done, don’t contact me’. And right now, setting yourself to inactive in FAS has to be done manually. This currently means that there may be, and likely are, many accounts that are inactive but don’t show as such. **enter ticket?**

Note 5:

It is not easy to identify events by proximity to one’s self in time or space. This makes attendance, and prioritization, difficult.


For this, the master list of events should help. This note prompted us to look more at how the interface should act.

We thought that the list should start out by showing you 20 upcoming events that are nearest to you. You could then filter it by number, time, and location to adjust the range of what it shows you.

We need to make it _really obvious_ that it is filtered, so that people who don’t forget that it is filtered and wonder why there are so few results.

We agreed that it should show big events like FLOCKs and FUDCONs to anyone who is in the appropriate region. We also thought that those events should show up in the events list as soon as a bid has been accepted, even if there’s not much concrete detail yet. Given that many people travel long distances for those, we wanted to give as much forewarning as possible. We also decided that people in affected regions should get notifications as soon as those show up, and that people in other regions can set a flag to be notified as well.

We would also want to include past events in the search, since people might want to find out what happened (because they couldn’t go, because it was too large to see all of it, because they got there late or had to leave early, because they were curious). Relatedly, we should collate the blog posts, IRC convos, meetbot logs, video recordings, discussion about an event, photos (Task: find out where interviewees store photos), tweets. Maybe notify people who went or who were maybes with followup materials (polls, etc).

Events should allow you to say if you plan to go to an event (yes/no/maybe), and if you’d be interested in volunteering or organizing it.

To get around the problem where some people want to see things by proximity in time, and others in space, we thought we should include both a list/calendar view and a map view. We are not yet sure about the calendar view, since it can be really handy for a quick understanding of things, but only if it’s not too crowded. Perhaps a certain number of events in a certain time periods can be a calendar, and otherwise a list format.

First, the default view:


Then, the month view:


The list view:


Now, what happens when you do things? In the default view, it seems helpful to suggest possible areas to filter by, and not just have people use ranges from specific places.


And show stuff about an event if you hover over it (and then click it), default view:


Month view, event more than a week out:


Month view, event has passed (I’m struggling with this one!):


Finally, clicking on things in the list view (I have no idea if one needs to register for FLOCK, but I’m sure there’s _something_ that needs registering, so I included it):


See ticket #281 to follow along!


Since people often don’t know about events happening nearby, and may not think to (or want to) do a search, we thought we’d suggest events to people. First, we’d suggest events when they are coming up in their region if they haven’t already responded to them.

We’d also suggest events in team hubs when lots of people are going (“10 design team members are going to __”), and let people who are usually far apart know when they and their friends will be co-located due to an event (but perhaps not during large events, due to spam potential).

We thought it would be good to make it easy for people to suggest a meetup around an event when they are notified that their friends or teammates would be co-located at it.

We decided, based on note #6, that we should show notifications about local, global, and regional meetups to everyone based on their location data, in their main feed. Regional hub members will find out about meetups local to that hub as well, regardless of their location.

Mockups of these:


To follow along, see issue #282.

In creating this, I found out that I am entirely uncertain if we need to be pointing out that people will be co-located. If it’s FLOCK or FUDcon it might be useful, but might also be spammy. Otherwise, I feel like people would already know about being co-located because they’d have planned it that way (eg fedora activity days).

Note #6:

It is difficult to learn about local meetups, whether or not they are Fedora-specific, and identify if they are active. This can make Fedora outreach (hackfest/workshop, table/booth, speaking/presenting) difficult to do.

We need a ‘fedora-specific’ data-field for events, because some events are Linux-wide, or open source-wide, and some are fedora-specific. We expect that ambassadors are the ones most likely to put non-fedora events into Hubs, since they may be attending/sponsoring, and don’t expect there to be non-fedora events listed without ambassador presence.

“Meetups” are most easily defined as recurring events, so we need to allow events to be recurring. However, to avoid the problem of an event having no one showing up (or worse, someone new showing up alone), we need to make sure that a recurring event isn’t publicized outside the group until someone takes ownership of that instance. We also need a notification to remind the last instance’s organizer and the hub’s leadership that the next one needs an organizer.

If not enough other people will be attending, the owner should cancel that meeting. To enable this, we need a notification to remind the organizer a day or two before the event to check in and make a call if there are enough attendees, the weather will permit, etc. If an event is cancelled, people who are signed up need to be sent a message about it (and perhaps remove it from the event calendar?).

Guest presenters may not have accounts on Hubs, but will also need to be notified if the event is cancelled. Event creation should support putting in an email address for a guest presenter, so that they can be notified.

Mockup for this is pending; I wanted to get this blog post out!

Next Plans and Uncertainties

Immediate tasks

So, in summary, I need to create mockups for the master lists of people, events, and regional hubs. I need to contact my interviewees to confirm my understanding of the social media outlets that are used in their countries and regions. I also need to ask them where they typically store photos.

All mockups, both to be created and those I’ve been working on need tickets in pagure. This will allow both a place for people to keep track of specific aspects of what I’m doing and for me to store the documents and links relating to each task and subtask.

Identify which bits of information need notifications, widgets, or both. Identify which should be on a hub, on a personal profile, or in someone’s stream.


There were some pieces of the brainstorming session which feel unfinished, and which may need revisiting later in this cycle:

We didn’t really delve into what filtering and searching in the regional hubs list should look like.

We didn’t decide on what to do with the problem relating to offloading some of the work from ambassadors who are a resource to their communities. See Note 3.

Post-Holiday Update

Posted by Suzanne Hillman (Outreachy) on January 03, 2017 03:54 PM

The past couple weeks were all crazy due to holidays, so I feel like I was less productive than I would have preferred to be. That said, I apparently did a fair bit!

I created the list of problems that I mentioned in my last post, and will be doing affinity mapping on them with Mo later this afternoon using https://realtimeboard.com/app/board/o9J_k0yF_VU=/. The main goals here will be to identify which problems we actually plan to solve, and prioritize those.

I also did a bunch of flowcharts, sketches, and Balsamiq mockups on a number of things that we are pretty sure that we’ll need even before we do the affinity mapping. At the moment, these include:

  • The ‘invitation’ page that the general public will be able to see for a regional hub. This will allow people the option of attending a meeting to decide if they want to join Hubs/FAS, talking to someone on the page itself before joining, and getting a general idea of the hub’s purpose.
  • The interface around locations. This will include accounts that already exist in FAS with and without location information, creating a new Hubs account, and updates to the location information both manual and prompted when their GPS suggests that they haven’t been where their location says for over 6 months. I’m not sure yet how we will handle making sure that we can access their GPS location, for the latter case.
  • The interface around joining a regional hub. I’m not yet sure how we should handle people whose location does not overlap a regional hub; I’m currently thinking that they should be able to subscribe, but not join. I’m also not sure how we want to differentiate subscription and join memberships, nor if we want have people who want to help out with a group be ‘join’ and people who just want to follow what’s going on be ‘subscribe’. Lots of uncertainty around this one!

Pending mockups/discussions, which may change after we do the affinity mapping:

  • How will people interact with regional hubs? This relates to the widgets that ought to be on a regional hub’s page, as well as what shows up on someone’s feed. It also relates to any email we might want to send people.
  • What will bring people back to Hubs? No one will use it if they don’t come back to it repeatedly.
  • What can we do to make one-offs (or at least rare) actions worth doing? Gameification? Like some websites (linkedin) which have a bar showing how complete your profile is. How do we avoid making encouragement to finish a thing polite and non-intrusive?

For more specifics, you can see my most recent update to the pagure issue on the user research and analysis ticket: https://pagure.io/fedora-hubs/issue/279

I did not include my sketches, as I largely used them to help myself think and they aren’t especially legible to people who aren’t me.

Until next time!

Initial analysis session

Posted by Suzanne Hillman (Outreachy) on December 20, 2016 12:30 AM

Last Thursday Mo Duffy and Matthew Miller and I did some initial analysis of the data I collected in my interviews.

I originally thought that we’d be doing some affinity mapping analysis, but that turned out to be less relevant with the data I brought. Instead, we discussed the patterns that I’d noticed in my interviews, most notably the difficulty of finding Fedora contributors and Fedora-related events in specific locations.


These patterns broke down into a number of pieces, whether it was about finding someone who might be interested in helping organize an event or a sponsorship, finding people who might want to attend an event, or identifying Fedora contributors who are still actively involved in the community.

Finding people, finding events

It can be quite difficult to find Fedora contributors who are interested in helping organize or potentially attend an event, or determining if the people who you have found are still active contributors. This is especially difficult if you are hoping to recruit contributors who are not ambassadors.

The problem with finding events was that it’s hard to tell if you’re failing to find anything because nothing exists, or because you haven’t yet found the right places to look. Somewhat tangential to Hubs, it can also be difficult to find out about events that aren’t specific to Fedora, but at which sponsorship, or having a presentation or workshop, might be good.

Too much information!

Less common, but still a definite problem, was the difficulty in finding information that others may already have found. There is no common place to keep information about venues, hotels, or swag vendors for future event planners to refer to. There is also no way to access information that previous event planners have learned through experience, such as general budget expectations for events such as FLOCK, or how much swag one might need to bring to an event.

Somewhat similar, in that it involves a great deal of information, is the problem of having too much information to easily keep track of. Depending on the complexity of an event, they minimally include a wiki page and email, IRC, or social media communication. Some of the more complicated events may also include documents, spreadsheets, and PDF files. It can be quite a lot of effort to keep track of all these disparate sources of information, even if any particular individual doesn’t find it taxing.


In addition to the general patterns I found among the interviews, Mo also suggested that I identify and describe the general workflows of the interviewees. There are two major categories into which the workflows fell: that of ambassadors and that of event planners.

Overall, ambassadors are typically doing two things: getting Fedora sponsorship into existing events, and acting as resources for the population they serve. The first requires the ability to find events for which Fedora sponsorship would be worthwhile and a great deal of organization, and the second typically involves a great deal of information to store and sort through.

Event planners all involve organizing a lot of information, including timing, costs, and locations. They often also include budgeting, travel, publicity, and topic selection.

What are the problems?

Now that the initial group analysis is complete, I am collating a list of problems that need solving so we can identify which are relevant to this project, and what the priorities are. That will be in my next post! For more information on the research I have done, see https://pagure.io/fedora-hubs/issue/279

The aforementioned pagure issue also includes the documents that I created for our analysis: summaries of the interviews, patterns and workflows, and a spreadsheet of the major points from each interview.

Until next time!

Fedora Design Interns Update

Posted by Máirín Duffy on December 08, 2016 08:15 PM

Fedora Design Team Logo

I wanted to give you an update on the status of the Fedora Design team’s interns. We currently have two interns on our team:

Flock 2016 Logo

Mary Shakshober – (IRC: mshakshober) Mary started her internship full time this summer and amongst other things designed the beautiful, Polish folk art-inspired Flock 2016 logo. She’s currently working limited hours as the school year is back in swing at UNH, but she is still working on design team tickets, including new Fedora booth material designs and a template for Fedora’s logic model.

Suzanne Hillman – (IRC: shillman) Suzanne just started her Outreachy internship with us two days ago. She has been working on UX design research for a new Fedora Hubs feature – Regional Hubs. She’s already had some interviews with Fedora folks who’ve been involved in organizing regional Fedora events, and we’ll be using an affinity mapping exercise along with Matthew Miller to analyze the data she’s collected.

If you see Mary or Suzanne around, please say hi! 🙂

Thanks! I will definitely keep you in mind.

Posted by Suzanne Hillman (Outreachy) on December 07, 2016 09:20 PM

Thanks! I will definitely keep you in mind. Also, I’m totally going to get back to you when it’s time to get feedback and suggestions on possible design directions. ;)

Analysis is confusing

Posted by Suzanne Hillman (Outreachy) on December 07, 2016 09:18 PM

I’ve often found myself stumped when confronted with a bunch of data, whether quantitative or qualitative. I might know what I was hoping to find out (but not always!), but that doesn’t always translate easily into knowing what I need to do with the information I’ve collected.

This seems like a fairly common problem, and yet I’ve struggled with it for as long as I’ve done research. So, at least officially, since sometime in 2008 or so, when I took my first research methods class before applying to psychology graduate schools.


Quantitative data at least seems like it should be more tractable than qualitative data. The first one’s a bunch of numbers, right? That seems like it should be easier to understand than a bunch of fuzzy words and descriptions and ideas. That being so, I’ve taken numerous psychological statistics classes. Indeed, I my mom has stories of me helping adult students in my mother’s stats class when I was 8. Math makes sense to me. Figuring out what to _do_, what’s relevant, what’s useful? Much less clear. This is often true, I find: knowing how to use the information I have can be a daunting task.

One of the things I find fascinating about UX is that this is known to be confusing and hard and also a really important aspect of what we _do_. Rather than trying to look for statistical significance, however, we’re looking for ideas and guidance and places that are obviously painful and places that are working well. Statistical significance is somewhat… irrelevant to the questions we are trying to answer. Not ‘how much’ or ‘how fast’, but ‘what is happening’ and ‘why’.

Statistics always felt like it was supposed to be a thing that could be done on one’s own. Like I should just know what the best approach is. This is likely not helped by the fact that I have trouble verbalizing math; it’s not at all the same language in my head, and translating is difficult. Having trouble verbalizing math makes it difficult to discuss it, and to consult with others to figure out the right sorts of statistical methods to use beyond the basic stuff that pretty much always has to happen. It’s not even just about which methods to use, but how to correctly interpret things. Statistics is a lot more fuzzy than practitioners like to admit to, at least in the psychological sciences. It’s all ‘is this significant _enough_’?, ‘is there enough of an effect for this to actually matter?’, ‘Have I gone down a rabbit hole and wasted all this effort?’. This is _not_ helped by the fact that non-significant results rarely get published.

Affinity Mapping?

I’ve known of affinity mapping, and even tried to use sticky notes to figure out some of my data in the first UX project I did. Unfortunately, as I found out at the time, analysis of the data I get in UX research doesn’t really lend itself to being done alone. Much like statistics, I suspect. I’m not at all sure how UX consultants do their analyses, given this!

Thankfully, I now have a mentor and an internship! When I flailed at Mo earlier today during our meeting, she suggested that I obtain Gamestorming as a useful reference book, and that we should go ahead and do some affinity mapping on my data. I need a bit more data first, but this means I finally get some of the guidance I’ve desperately been looking for.

I’ve been reading Gamestorming today, taking frequent breaks so I have time to let things settle in before I continue reading. I’ve also been reading a Paper Prototyping book that I got at the suggestion of another helpful person in the Boston area UX community, Jen McGinn. Given that I sort of guessed at paper prototyping for the same project in which I tried to analyse my data using sticky notes, this book should be helpful.

I’m really looking forward to getting a chance to do affinity mapping on this project. I think it’ll make a huge difference for my confidence!

Outreachy Starts Today!

Posted by Suzanne Hillman (Outreachy) on December 06, 2016 08:59 PM

This blog should now be showing up on various planets (Fedora, Outreachy, Fedora Design), which means I need to do an introduction.

Hi, I’m Suzanne. I’ve been working on getting myself into User Experience (UX) for about a year now, although I’ve been interested in smoothing the interface between people and technology for longer than that. Most recently, I spent a few years in a PhD program working with robots and investigating the kind of gestures that robots will most need to understand when conversing with people. When that turned out to not be a good program for me, I figured out that UX was the most interesting and relevant path forward.

My outreachy project is the UX of Fedora hubs, specifically that of regional hubs [1]. I’ve been working on it for a few months now with my mentor Mo Duffy. I’ve already done the competitive analysis, done initial research planning, and started interviewing Fedora ambassadors and community members. Some interviews remain, and I continue to try to schedule with and get in touch with the remaining 4 people.

I’m hoping to get those last few interviews done in the next two weeks, to stay on track for the original plan provided in the application. We shall see, since I’m having trouble getting replies back to my emails.

I’ve looked for patterns in the existing interviews, and there are definitely some emerging. I’d definitely prefer more interviews before I do much with those results, though. Three interviews isn’t really very much.

This seems like a decent introduction for now. Until later!

[1] https://pagure.io/fedora-hubs/issue/47

Initial research has started

Posted by Suzanne Hillman (Outreachy) on December 02, 2016 09:12 PM

As I mentioned in my last post, I did a pilot test of both the research script and figuring out how to get google to allow for the recording of someone’s screenshot and speech.

Some investigation and suggestions from Mo resulted in checking out Google Hangouts On Air and its interaction with Youtube’s live streaming of events. We tried it out, and after some slightly confusing set up which we modified to have our events be private to me (since I didn’t want other people to see my interviews), it worked perfectly.

Pilot Testing

The pilot of the script itself showed a glaring assumption that I had made while writing the script. Given that the point of the pilot was to find precisely these kinds of things before I interviewed people who weren’t Mo, that was a success. It was a little frustrating in the middle of things to run into it, but given that it’s basically impossible to get anything right the first time, wasn’t too bad. I had assumed that everyone that I spoke to would be planning local events, which is most certainly not always the case. I had also forgotten to be sure to include the things that they had talked about in the initial conversation when it came time for them to share their screen and show me specifics.

I found it amazingly difficult to take notes while doing the pilot test. I’m not sure how much of that is how rapidly Mo talks, and how much was unfamiliarity which the pilot test was meant to help with. Regardless, I didn’t take nearly as many notes during that first interview as I was hoping, and ended up having to go back through the entire interview to write down important points and make comments to myself. I decided to highlight those comments in color-coded ways to make it clear the kind of comment it was: a pain, a followup question, or a note for myself when it came time to use the information.

Later Interviews

The second and third interviews that I’ve done thus far were much easier to take notes during. I will probably still go review the recordings for things that I missed the first time through, but it’s much less vital than it was with the pilot.

Unfortunately, the second interview ended up having to be postponed a day because google on air was refusing to talk with youtube. Or possibly be on air. It really wasn’t clear. I hadn’t set up any sort of backup option at that point, either. Thankfully, the interviewee had an open schedule around Thanksgiving and could easily reschedule.

Mo has since set up a backup recording option through Red Hat’s Bluejeans tool, which I’ve not needed to use yet. Backup options are important, however!

I’ve not yet heard back from two of the people I asked about interviewing, and will followup with Mo about who else to use shortly. Two others were potentially interested, but I haven’t yet been able to schedule interviews with them. Indeed, one of them sort of vanished on me. As always, getting people’s time can be complicated!


I’m not entirely clear, yet, what I should be doing with my analyses of these interviews. I suspect that as I do more interviews, I shall gain a better sense of the patterns among the people I talk to.

At the moment, people want somewhere to easily store, search, and access information. This includes documents, graphics, and information about vendors of swag or about hotels or venues at the minimum.

They also seem to want a way to find people who might be interested in an event or in Fedora or open source in general. This seems to break down into fellow ambassadors and Fedora community members (or potential members) who are nearby, and local groups at which people who are involved with Fedora might give talks (linux user groups, for example).

The two previous ideas may benefit from including information about people who have sponsored or been sponsored by Fedora. There should also be a way to indicate how up-to-date the information is.

It’d be good if it were easier to find and learn about events nearby, perhaps using a calendar format.

Another thing I noticed during my interviews is the potential need to restrict topics. For example, avoiding political discussion in places where that may risk one’s well-being. I don’t know what precisely this would need to involve, yet, but it seems important.

Going forward

Outreachy officially starts on Tuesday. I will then be attending the weekly fedora-hubs meeting, and having a check-in meeting with Mo every other week.

I need to get more of the interviewees to get back to me about scheduling or find someone else to include.

I’ll be blogging here at least every two weeks starting Tuesday. I’m not entirely clear on what sort of introductory post to write, given I’ve been talking about this project for months now!

Scribus in copr scribus-unstable repository now supports spellcheck

Posted by Luya Tshimbalanga on December 01, 2016 09:58 PM
Scribus 1.5.3svn snasphot with spellcheck running on Gnome Shell 3.22 Wayland

Starting from 1.5.3-0.19 snapshot, Scribus now has spell check enabled, one of requested features for free and open source desktop publishing software. Additionally, this version includes appstream by default allowing visibility in both Gnome Software and Apper.
The ability to read Microsoft Visio, Pagemaker and even Adobe InDesign files is a welcome addition to see the migration. More changelog available

Users looking to try this snapshot can access COPR repository and install it alongside the stable version.

On a side note, Scribus Generator is an excellent utility for mail-merge alternative.

Running Fedora 25 Design Suite on ASUS X550ZE laptop

Posted by Luya Tshimbalanga on November 25, 2016 07:08 AM
This blog is written on Fedora 25 Design Suite running on ASUS X550ZE.The upgrade from Design Suite 24 to 25 using Gnome Software went smooth with very little impact to the entire system.

Fedora 25 Design Suite with supported Dedicated Graphic card on a hybrid laptop

Inheriting the features from Fedora 25 Workstation, Design Suite now gained further support of hybrid hardware notably laptops (see above feature). Following the release cycle, supplemental wallpapers from Fedora 23 are replaced by their 25th version to mark the end of life of the 23rd release next month.

Design received new applications like Gnome Books useful for e-books and Calendar to easily manage the schedule.

  To enable full support of hotkeys and optimal power management due to the boot scheme bug in Linux kernel, 4.9.0rc4 or above (currently residing in Rawhide nodebug repository at the time of writing) is required and will soon reach availability via update. The case applied to some hybrid laptops (ASUS X550ZE in this example).

Looking for Design Suite 26 with further improvement of Gnome Shell environment. A special thanks to Makeuseof for selecting Fedora Design Suite as Best of The Basics.

Fedora Hubs and Meetbot: A Recursive Tale

Posted by Máirín Duffy on November 15, 2016 08:25 PM

Fedora Hubs

Hubs and Chat Integration Basics

One of the planned features of Fedora Hubs that I am most excited about is chat integration with Fedora development chat rooms. As a mentor and onboarder of designers and other creatives into the Fedora project, I’ve witnessed IRC causing a lot of unnecessary pain and delay in the onboarding experience. The idea we have for Hubs is to integrate Fedora’s IRC channels into the Hubs web UI, requiring no IRC client installation and configuration on the part of users in order to be able to participate. The model is meant to be something like this:

Diagram showing individual hubs mapping to individual IRC channels / privmsgs.

By default, any given hub won’t have an IRC chat window. And whether or not a chat window appears on the hub is configurable by the hub admin (they can choose to not display the chat widget.) However, the hub admin may map their hub to a specific channel – whatever is appropriate for their team / project / self – and the chat widget on their hub will give visitors the possibility to interact with that team via chat, right in the web interface. Early mockups depict this feature looking something like this, for inclusion on a team or project hub (a PM window for user hubs):

mockup showing an irc widget for #fedora-design on the design team hub

Note this follows our general principle of enabling new contributors while not uprooting our existing ones. We followed this with HyperKitty – if you prefer to interact with mailing lists on the web, you can, but if you’ve got your own email-based workflow and client that you don’t want to change at all, HyperKitty doesn’t affect you. Same principle here: if you’ve got an IRC client you like, no change for you. This is just an additional interface by which new folks can interact with you in the same places you already are.

Implementation is planned to be based on waartaa, for which the lead Hubs developer Sayan Chowdhury is also an upstream developer.

Long-term, we (along with waartaa upstream) have been thinking about matrix as a better chat protocol that waartaa could support or be ported to in the future. (I personally have migrated from HexChat to Riot.im – popular matrix web + smartphone client – as my only client to connect to Freenode. The experiment has gone quite well. I access my usual freenode channels using Riot.im’s IRC bridges.) So when we think about implementing chat, we also keep in mind the protocol underneath may change at some point.

That’s a high-level explanation of how we’re thinking about integrating chat into Hubs.

Next Level: HALP!!1

As of late, Aurélien Bompard has been investigating the “Help/Halp” feature of feature hubs. (https://pagure.io/fedora-hubs/issue/98)

The general idea is to have a widget that aggregates all help requests (created using the meetbot #help command while meeting minutes are being recorded) across all teams / meetings and have a single place to sort through them. Folks (particularly new contributors) looking for things they can help out with can refer to it as a nice, timely bucket of tasks that are needed with clear suggestions for how to get started. (Timely, because new contributors want to help with tasks that are needed now and not waste their time on requests that are stale and are no longer needed or already fixed. On the other side, the widget helps bring some attention to the requests people in need of help are making, hopefully increasing the chances they’ll get the help they are looking for.

The mechanism for generating the list of help requests is to gather #help requests from meeting minutes and display them from most recent to least recent. The chances you’ll find a task that is actually needed now are high. As the requests age, they scroll further and further back into the backlog until they are no longer displayed (the idea being, if enough time has passed, the help is likely no longer needed or has already been provided.) The contact point for would-be helpers is easy – the person who ran the #help command in the meeting is listed as a contact for you to sync up with to get started.)

The mockups are available in the ticket, but are shown below as well for purposes of illustration:

Main help widget, showing active help requests across various Fedora teams

Main help widget, showing active help requests across various Fedora teams

Mockup showing UI panel where someone can volunteer to help someone with a request.

Mockup showing UI panel where someone can volunteer to help someone with a request.

An issue that came up has to do with the mapping we talked about earlier. Many Fedora team meetings occur in #fedora-meeting-*; e.g., #fedora-meeting, #fedora-meeting-1, etc. Occasionally, Fedora meetings occur in a team channel (e.g., #fedora-design) that may not map up with the team’s ‘namespace’ in other applications (e.g., our mailing list is design-team. Our pagure.io repo is ‘/design’.) Based on how Fedora teams use IRC and how meetbot works, we cannot rely on the channel name to get the correct namespace / hub name for a team making a request during a meeting using the meetbot #help command.

Meetbot does also have a mechanism to set a topic for a meeting, and many teams use this to identify the team meeting – in fact, it’s required to start a meeting now – but depending on who is running the meeting, this freeform field can vary. (For instance – the design team has meetings marked fedora_design, fedora-design, designteam, design-team, design, etc. etc.) So the topic field in the fedmsg meetbot puts out may also not be reliable for pointing to a hub / team.

One idea we talked about in our meeting a couple of weeks ago as well as last week’s meeting was having some kind of lookup table to map a team to all of its various namespaces in different applications. The problem with this is that because meetbot issues the fedmsgs used to generate the halp widget list of requests as soon as the #help command is issued – it is meetbot itself that would need to lookup the mapping so that it had the correct team name issued in its fedmsg. We couldn’t write some kind of script or something to reconcile things after the meeting concluded. Meetbot itself needs to be changed for this to work – for the #help requests put out on fedmsg by meetbot to have the correct team names associated with them.

Which Upstream is Less Decomposed?

Do you see dead upstreams? Zombie image

Zombie artwork credit: Zombies Silhouette by GDJ on OpenClipArt.

We determined we needed to make a change to meetbot. meetbot is a plugin to an IRC bot called supybot. Fedora infrastructure doesn’t actually use supybot to run meetbot, though. (There haven’t been any commits to supybot for about 2 years.) Instead, we use a fork called limnoria that is Python 3-based and has various enhancements applied to it.

How about meetbot? Well, meetbot hasn’t been touched by its upstream since 2009 (7 years ago.) I believe Fedora carries some local patches to it. In talking with Kevin Fenzi, we discovered there is a newer fork of meetbot maintained by the upstream OpenStack team. That hadn’t seen activity in 3 years, according to github.

Aurélien contacted the upstream OpenStack folks and discovered that, pending a modification to implement file-based configs to enable deployment using tools like Ansible, they were looking to port their supybot plugins (including meetbot) to errbot and migrate to that. So we had a choice – we could implement what we needed on top of their newer meetbot as is and they would be willing to work with us, or we could join their team in migrating to errbot, participate in the meetbot porting process, and use errbot going forward. Errbot appears to have a very active upstream with many plugins available already.

How Far Down the Spiral Do We Go?

To unravel ourselves a bit from the spiral of recursion here… remember, we’re trying to implement a simple Help widget for Fedora Hubs. As we’ve discovered, the technology upon which the features we need to interact with to make the feature happen are a bit zombiefied. What to do?

We agreed that the overall mission of Fedora Hubs as a project is to make collaboration in Fedora more efficient and easy for everyone. In this situation specifically, we decided that migrating to errbot and upgrading a ported meetbot to allow for mapping team namespaces to meeting minutes would be the right way to go. It’s definitely not the easy way, but we think it’s the right way.

It’s our hope in general that as we work our way through implementing Hubs as a unified interface for collaboration in Fedora, we expose deficiencies present in the underlying apps and are able to identify and correct them as we go. This hopefully will result in a better experience for everyone using those apps, whether or not they are Hubs users.

Want to Help?

we need your help!

Does this sound interesting? Want to help us make it happen? Here’s what you can do:

  • Come say hi on the hubs-devel mailing list, introduce yourself, read up on our past meeting minutes.
  • Join us during our weekly meetings on Tuesdays at 15:00 UTC in #fedora-hubs on irc.freenode.net.
  • Reach out to Aurélien and coordinate with him if you’d like to help with the meetbot porting effort to errbot. You may want to check out those codebases as well.
  • Reach out to Sayan if you’d like to help with the implementation of waartaa to provide IRC support in Fedora Hubs!
  • Hit me up if you’ve got ideas or would like to help out with any of the UX involved!

Ideas, feedback, questions, etc. provided in a respectful manner are welcome in the comments.

I’m accepted into Outreachy for this winter!

Posted by Suzanne Hillman (Outreachy) on November 09, 2016 03:48 PM

Just remembered to check the website, and indeed: I’m accepted.

This is excellent news!

Blender and video sequence editor on Fedora

Posted by Luya Tshimbalanga on November 06, 2016 08:00 AM
Due to the legal matter related to FFMpeg, the video editor on Blender for Fedora will fail to run any video format. Tracking this bug report, it seems possible to build FFMPEG without the patented codecs thus possibly allow Blender video editor to properly run.

For the time being, alternative is already available on Fedora repository like Pitivi bundled in Fedora Design Suite. The downside is the occasional crash while editing, the upside is the use of extensible Gstreamer on several plugins compared to FFMPEG although the latter is popular.

Readying Fedora Design Suite 25

Posted by Luya Tshimbalanga on October 29, 2016 08:28 AM
LuxRender plugin now selectable on Blender in Software

The official release of Fedora 25 Design Suite is nearby with the following changes:
  • Inheriting the features from Fedora Workstation, it is now possible to rename several files.
  • Blender just reaches 2.78a with several bugs fixes. Non-western speaking users will delight the issues related to the interface is fixed.
  • LuxRender plugin for Blender  is updated to 1.6 bring new features. That version no longer supports 32 bit architectures known as x86. In addition, the plugin is now visible as addon for Blender in Software.
  • Sadly, Yafaray plugin for Blender is currently retired from the Fedora repository thus dropped from the default selection. It is still available for the previous release. The plan is to bring it back for the next release as I took over as packager.
  • Some applications like Gpick are unable to properly run on the default Wayland session and needs X session.
  • New fonts are available Grand Hotel and Molot (a big thanks for TypeType foundry for making it license friendly) needed as template for Fedora Magazine featured image.
  • Inkscape (pre-release of 0.92) gains new support of creating tables via plugin
  • Suppplemental wallpapers from Fedora 25 replaced their F23 version as default.
  • Pitivi 0.97, a video editor, received a fix and should properly.
All listed feature will be available on the wiki

    Research planning

    Posted by Suzanne Hillman (Outreachy) on October 11, 2016 12:17 AM

    The next step in our process is to talk to our users. In this case, I will be doing contextual interviews with 7 people.

    The major goal of these interviews is to identify the tools that Fedora folk are currently using to handle event planning for Fedora events. I hope to identify both existing pain points and aspects of the current tools that work well.

    Who should we interview?

    Lots of discussion with Mo turned up a few different axes on which we need to spread out our users.

    This project is meant to aid Fedora members in doing things with people near them. First, to find other Fedora community members to interact and potentially meet up with. Second, to coordinate events to introduce the general public to Fedora. Therefore, the most important aspects of our users is location.

    Coordination of public events is most likely to be done by Fedora Ambassadors. Other Fedora members will also need to create and organize public events. As such, we need to include both Ambassadors and non-ambassadors.


    The Fedora Community has four major locales: North America, Latin America, Europe and the Middle East, and Australia and the Pacific Islands. In addition to these four locations, we also have people who are specific to college campuses. As a result, we decided that we needed to be sure to have people from each of the locales, as well as people who were from college campuses.

    Ambassadors and other community members

    Ambassadors are the public face of Fedora, and therefore the people who are most likely to be organizing events for the public. The main goal of Fedora Regional Hubs is to make it easier to organize events, both within the Fedora Community and including the general public. Given that Ambassadors will definitely need to create public events, we need to include them in our user set. However, Ambassadors are not the only people potentially creating Fedora events for the general public, and so we need to make sure that Ambassador were not the only types of users we included.

    Other important criteria

    Age: It is possible that this will affect the types of tools currently being used, as well as the assumptions that users will make. When Mo suggested who to talk to, she expected that various ages will naturally fall out of the list she offered.

    Presence of frustration with current methods: As I am new to this project, and do not have much experience with how people are currently handling event planning, I wanted to be sure that we would include people who are known to be struggling. Discussion with Mo suggests that anyone we talk to will have at least some level of frustration to tap into.

    Gender: This was less strongly emphasized in our recruiting goals, although we do have 2 women of the 7 total users. I would have been concerned if we had had none. However, given the topic, I expect we would have struggled to find approximately equal numbers who were also appropriately spread out for location and ambassador status. Those two were more immediately important for the purposes of determining what people are currently using.


    Our list of potentially relevant aspects of our potential users included a number of additional axes of variation. These were not expressly included in our decision on who to include, but will be included on the demographics survey that participants will fill out ahead of time.

    Experience with Linux/Fedora: What experience do people have, how long have they been using it, how do they use it.

    Learning new things to do one’s job: Given that we would be developing a new tool to hopefully help people do the things they want to do, it seemed important to get people who were enthusiastic about learning new tools, fine with doing so, and actively dislike doing so. This will become relevant when it comes time to test prototypes.

    How active are Fedora groups you are already in? This is to get a general sense of the spread of the activity the people we interview are accustomed to.

    Final users

    We ended up selecting 3 ambassadors from three different locations, 2 non-ambassadors with one location overlap (Australia and Pacific Islands), and 2 campus people one of which was an ambassador and one not (both in North America).

    Mo will both be one of the non-ambassadors and the pilot user for the interview process. I expect that the pilot will bring to light many things that I flat out forgot to include or which needed to be more clearly stated. As a result, I expect that the interview and the survey will need adjustment before continuing.


    Coming up with relevant questions for the interviews was difficult. I originally started out trying to use the same categories that I used in my competitive analysis, but Mo correctly pointed out that those were too specific for this purpose. She gave an example of what she might do instead, and it became clear to me that I needed to do a high-level brainstorm of the kinds of tasks people might use regional hubs for.

    I expect people will want to:

    1. Find people who are local to them and interested in Fedora.
    2. Set up events (public ones) or meetings (within group).
    3. Discuss things about Fedora.
    4. Find people to attend the public events (advertisement).
    5. Find events to attend/support

    I suspect that #1 will not be relevant to our contextual interview due to being something someone new to a site might want to do. I also suspect that #4 may fall under #2. I’m currently waiting on feedback from Mo on the tasks and questions that I came up with.

    I will use some combination of Steve Krug’s Usability script from Rocket Surgery Made Easy and “Interviewing Users and Others” in User and Task Analysis for Interface Design by Hackos and Redish to come up with the final interview script. Of course, Mo may have a better suggestion, but that’s what I’m planning at the moment.

    Next post should include discussion of the pilot test. Stay tuned!

    Competitive analysis summary

    Posted by Suzanne Hillman (Outreachy) on October 07, 2016 08:16 PM


    1. Get an overview of current practices and general structure of existing meetup sites
    2. Identify potentially useful techniques and things to avoid.
    3. Identify questions for contextual interviews and for ourselves.


    1. http://loco.ubuntu.com/ — Ubuntu’s regional meetup organizational site (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157670346963233)
    2. http://meetup.com/ — the most commonly used site for regional meetups. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157673502663516)
    3. https://www.citysocializer.com/ — Very event-focused site. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157673872243535)
    4. 1) http://www.bigtent.com/ — a barebones site for parents and their kids. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157672661407220)



    A simpler home page will help potential users decide if they want more information without overwhelming them.

    Search is very difficult. It’s a major challenge to have search that does what a user expects and provides results that are easy to understand and use.

    Including a photo of a group or specific event in search results helps a group seem more approachable.

    Use spacing and font styles to more visibly separate pieces of information to improve readability.

    None of the sites I looked at integrated real-time discussion.

    Site Summaries

    loco.ubuntu was the site with the most similar intentions to our own, as both Fedora Regional Hubs and Ubuntu LoCo are about regional and local groups within an opensource community. They have one teams per area, to reduce fragmentation of groups. This is reflected in their interface, in that they made the creation of teams a complicated process. They also want it to be very easy to find and join teams and events, so those are easy to do.

    meetup.com is all about making creation of groups, attending of meetups, and general interaction with other people as easy as possible. It’s got the easiest interface for all aspects of group and event creation and joining, and discussion, of the four I reviewed. However, something we will want to keep in mind is that we may not _want_ everything to be simple to do. Keep in mind the potential problem of fragmentation.

    citysocializer really just wants people to go out and do things together. There is very little on-site discussion, and no groups or teams. It’s all about events.

    bigtent.com wants to make things easy for group creators. Creating a group and creating a page for the group are very clean and clear and simple. Using those pages and finding information on them, however, is quite confusing and poorly laid out.


    Home pages varied wildly, although everyone had navigation across the top. The home page of bigtent was much cleaner and easier to parse than the others were.

    Events pages also varied a great deal. Meetup’s events page was easiest to interpret, possibly due to the amount of separation and white space between various types of information. Meetup’s events page also had fewer types of information on the page. Bigtent, on the other hand, had a small number of pieces of information, but they were poorly separated or not at all separated, and as a result were difficult to scan to get relevant information.


    The second goal, that of identifying techniques to use and things to avoid, was a little ambitious for a first look at the competitors in this space.

    What are people currently using within Fedora? Learning this will be a major goal of the contextual inquiry that is the next step in this process.

    What do we plan to support and not support for search?

    What sorts of things should be visible to people not logged into Hubs, for such things as public events planning and advertising?

    How easy do we want each aspect of a social site?

    Finding groups and events should likely be as easy as possible, given the desire to make it easier on new users to become part of the Fedora community. Joining should also be easy, for much the same reason.

    Discussions is an open question: should it only be within groups? Should we let the general public comment on/ask questions about public events? What should various people (owner of group, member of group, member of Fedora, general public — for example) be able to see on a group’s or event’s page?

    How about creating or suggesting events or groups? This may not be as simple to come to a decision on.

    For more information

    See https://pagure.io/fedora-hubs/issue/47, and the full writeup of the analysis at https://pagure.io/fedora-hubs/issue/raw/files/f258136ec925fe9a4cd13c127b8a428e7adac83135939ce5ccff5cab145aca30-Competitive_analysis.pdf

    Next up, planning research.

    Outreachy Competitive Analysis

    Posted by Suzanne Hillman (Outreachy) on September 22, 2016 12:52 AM

    Following up on the previous post about about my time in Outreachy working on the Fedora Project, with former co-worker Mo Duffy. I’ll be working on the UX of Local, Regional, National, and Continental Hubs as part of Fedora Hubs. The main idea is to help co-located Fedora contributors find each other, meet up in person, and set up local events like hack-a-thons and meetups.

    Competitive Analysis

    I’ve done most of the work for a competitive analysis of existing local/regional meetup websites, and am currently working on writing up a report of what I’ve found.

    My initial goal for the competitive analysis was to try to get a sense of what people currently do around regional meetups, and Mo suggested that I pattern my data collection after screenshots in the ‘relevant art’ sections of a few Gnome design projects: Chat, Documents, and Mail. We also decided that Flickr would be a good place to store the screenshots, as it supports comments and adding drawings to uploaded photos.

    As I proceeded with the screen-captures and annotations, I noticed that this task would not necessarily tell me what people in Fedora are currently using to organize their events and meetings. As such, the contextual inquiry that is my next task will need to include interviews with potential users to find out what they are actually doing right now.

    The report that I’m currently working on incorporates some of the competitive analysis explanation from “Communicating Design: Developing Web Site Documentation for Design and Planning” by Dan M Brown (seems to be a more recent version), which Mo lent me. It also leans on my existing experience in explaining and summarizing concepts, as that is a lot of what this report really seems to be about. It’s not yet complete, but I’ve sent it to Mo for some feedback to make sure that I’m on the right track with my report. So far, I’ve found this book a very useful guide to keep myself focused and remembering what I’m doing. It strongly informed the structure of the report I’m writing, most especially the part at the beginning of a document where I need to say what I’m doing, why I’m doing it, what I hoped to figure out, and what I actually figured out.

    I’ll go into more detail on what I did and what I found once I’ve finished the report.

    The next task before the application is due on Oct 17th is to create a rough plan for contextual inquiry and potential interview candidates. When I have finished up the next blog post about the report, I will start talking more about that part.

    I have run out of words that want to stick together in a useful order, so this post must therefore be complete.

    Long radio silence!

    Posted by Suzanne Hillman (Outreachy) on September 21, 2016 02:12 PM

    Long radio silence!

    I’ve been busy trying to find a part time job and working on ways to break into ux.

    Today, I’m starting a part-time job with the mbta through Thanksgiving. I’ve also been working on the initial submission for the Outreachy program, wherein I will be working with the Fedora project.

    My initial submission will include a competitive analysis, for which I am currently writing up a report after putting up groups of annotated screenshots on Flickr. I also need to write up my plans for user interviews to identify current methods for creating and attending local group meetings and events, and the plans for contextual inquiry.

    The contextual inquiry may be more complicated than ordinarily, as the entire point of the project is to provide a consistent interface for local and regional fedora meetups. This means that my best users may be scattered across the world.

    Solving that problem with my mentor will be interesting, and will involve some compromise. Perfect is the enemy of good, however, so finding a way to get useful information which does not involve me being in the room with the users will be useful. The best possibility probably involves remote desktop viewing, with two-way audio. Other possibilities may by necessity involve a running commentary on IRC. Or maybe Skype. I’m not yet sure, as my mentor Mo and I have only briefly discussed this aspect of things.

    Sneak into…

    Posted by Sirko Kemter on September 16, 2016 05:25 AM

    the current stage of the Fedora 25 Supplemental Wallpaper.. Start of this month I openend the submission phase for the Fedora Supplemental Wallpaper. So far we have received 91 submissions and currently 72 of them are approved. So far 49 contributors earned a badge for their submission. But there is still time until 11. October left to contribute a wallpaper.

    So far that are my favorites:

    Update on Asus X550ZE running on Fedora 24

    Posted by Luya Tshimbalanga on September 02, 2016 06:26 AM
    Since applying fix related to the ACPI from Linux kernel (future 4.8.0), ASUS kernel laptop runs smoother on Gnome Shell inside Fedora 24 Design Suite. Based on the following observation:
    • The delay of pluggin on/off the power is gone. Without the fix, it took about ten seconds before the system switched the status.
    • Power management has drastically improved. 
    • Closing the lid will automatically suspend the laptop.
    • Multimedia control now works on all applications.
    • Brightness control properly works.
    For Fedora users having similar issue with X550Z (also F550Z on some countries), a COPR repository is created for that purpose until upstream release the fix version on the kernel. Other distributions can look at the patch and provide feedback for testing and improvement.

    A big thanks to Peter Wu and Lv Zheng for investigating the issue which turned out bigger than expected: the discovery of new ACPI scheme on some modern laptops .

    [Solved] Quest to enable hotkeys for Asus X550Z

    Posted by Luya Tshimbalanga on August 31, 2016 12:23 AM
    Following previous topic, testing the build kernel 4.8.0rc4 with the patch related to ACPI EC allow unlocking the functionality of hotkeys. For the first time, ASUS X550ZE has nearly full functionality from keyboard in Linux operating system (Fedora in my case) on par with Microsoft Windows 8.1 and 10.  Hopefully other laptops having similar problem will regain that access.

    For that learned experience, that bug turned out more complex than expected revealing a different ACPI scheme used in Microsoft Windows 10 and a bad practice from BIOS vendor. It also shows how some vendors ignore standard procedure thus making harder to find the problem.

    The important lesson is the cooperation between users and developers exchanging knowledge and discovering new elements never seen before. One day, vendors will open themselves approaching the kernel community to improve their products.

    Now the hotkeys saga comes to the end, the next step is the support of AMD hybrid graphic card. This blog is written on ASUS X550ZE running on AMD A10 7400P itself using Radeon M265DX.

    [Follow-up] Quest of enabling hotkeys on ASUS Laptops

    Posted by Luya Tshimbalanga on August 30, 2016 07:59 PM
    Resuming for the previous topic, with the help of an Arch user and one of kernel maintainers, it turned out the failure of hotkeys functions [Fn] is due to a Linux ACPI bug. Further investigation revealed a bad practice from BIOS vendor and unexpectedly a new challenge in Linux kernel world as quoted:
    However this report indicates us another gap (except the enumeration order gap):
    If the namespace EC (DSDT EC in short) is not ready, EC access availability can be kept
    using the ECDT EC. In Linux, that requres _Qxx control methods to be registered for
    the ECDT EC. I have never seen a Linux EC driver version doing this before,
    _Qxx registration is only invoked in acpi_ec_add(). So this bug indicates a gap for Linux.
    Essentially, what is initially a bug related for non-functional hotkeys for ASUS X550Z laptop revealed a much more deeper issue related Linux ACPI. It is the first time I reached that level of testing in kernel world with the help from upstream kernel.

    A built kernel with an attempt patch to resolve ACPI EC problem is on COPR repository. It willl take longer to complete before testing the patch which will hopefully restore hotkeys functionality on some modern laptops especially ASUS. A suivre...