Fedora Design Team Planet

Website and portfolio design

Posted by Suzanne Hillman (Outreachy) on September 16, 2017 06:30 PM

I’ve been slowly moving my website from the official pelican-based version to an in-progress Wix-based version. I learned interesting things around current web development while using the Pelican version, but I found it difficult to implement the kinds of design choices I wanted to make. I also found it quite difficult to get a responsive design that _stayed_ responsive when I made changes to the CSS file.

Wix is very nice for many design decisions, in large part because one can take a particular design element and put it wherever you want on the page. There is no futzing with the HTML or CSS, and no need to learn Python or Javascript.

Given that I want my page to be welcoming and easy to follow, easily choosing specific design elements is vital.

Tell a story!

One of the most important aspects of a UX portfolio is demonstrating one’s UX skills. This means walking folks through your process and making it easy to follow and understand.

One of my major challenges was (and is!) deciding how to structure my portfolio to offer the greatest ease of use without losing too many of the specific details. Upon the recommendation of one of the many recruiters I’ve spoken with, I’ve been adding an overview page to each piece of my projects:

<figure><figcaption>In this version, I offer an overview and links to more details of some of the pieces.</figcaption></figure>

If you compare this to the currently official version of my page, it’s a clear and huge difference in usability:

<figure><figcaption>This doesn’t show the overall goal, what my role was, or offer much guidance. It’s also not physically structured for easy reading.</figcaption></figure>

How to tell my story?

One of my major struggles is with offering too much information. Too many details, and too little structure.

I want people to know what I did! Unfortunately, if there’s not enough structure, they won’t read any of it. If there’s too much information, they won’ read any of it. So my major task is to take what I have and create overviews; not just for the main page of a project, but for sub pages.

This is unfortunately not quick or easy! As a result, I’m working on bringing the overviews back to my pelican site as I make them, with the eventual goal of fully transitioning. Sadly, I have been unable to convince my pelican site to let me stack things horizontally. My impression is that this is one of the major improvements to my Wix site, so even though I’ll bring some of the ideas back to Pelican, they are simply not as well-designed there.

I’ll be asking for feedback before I move over completely, of course. In the meantime, it’s pretty clear to me that my Wix site is just _better_. I’ll also be grabbing what I have at the Pelican site before ditching it, as I will worry that I’d lose information otherwise.

Other changes?

I’m also ditching the references to Cambio Buddies. It was a valuable and useful project, but I had very little guidance for what I was doing. I made a lot of mistakes, used techniques poorly, and am generally not happy with that project. Maybe it’s a mistake to remove my first project, but I just don’t like it.

Some folks have suggested incorporating the ‘current’ and ‘complete’ design projects into a single area. I’m reluctant to do this, since the current projects are still in process: I don’t want to be presenting them as if they were finished when they are not.

Similarly, folks have suggested getting rid of the design artifacts page. I’m not completely clear on why: they are in the Projects area, and it seems helpful to let folks get to a specific artifact quickly if they so desire.

One of my early bits of feedback for the Pelican portfolio was a lack of process. I’m still not entirely clear on what was meant by that, although I suspect that the lack of overview may have been part of it.

UX Hiring Process investigation ongoing

Posted by Suzanne Hillman (Outreachy) on September 16, 2017 06:03 PM

Hi folks!

I’ve been meeting, finding, and interviewing folks at various points in their UX careers. It’s been fascinating, and reminds me that I’m _much_ better at networking when I have a reason to talk to people.

I’ve not yet had a chance to analyze my interviews in depth thus far, but I have noticed some interesting trends.


Portfolios and online presence

  1. It’s difficult to know what to put in a UX portfolio, especially for researchers. Lots of folks talk about having a story for your reader to more easily understand and follow what you’ve done. I’m collecting information on what this could mean in practice.
  2. It’s really helpful to have an online presence that shows how you think about design, whether a blog, twitter, behance, dribble, or github. Some companies won’t consider someone without an online presence demonstrating their thought processes and personality. Put links to your online UX presence in your resume.

Finding your first job

  1. There’s not a lot of companies hiring folks who are new, and there seems to be a bit of a lull right now even among those who typically would be doing so. There’s a much better chance to get a job if you have at least 2–3 years of experience.
  2. Most internships require that one is currently or recently in school. It’s also difficult to find mentors or apprenticeships.
  3. Folks doing the hiring may or may not understand what UX is, what each UX role involves, or what the best things to look for are. Job descriptions may or may not involve throwing everything they might want in there, so it’s often worth applying even if you don’t know all of what they are asking for.
  4. Lots of companies are playing catchup — they feel like they should have gotten into UX 10 years ago, so think they need senior UXers to get things jumpstarted. Those senior UXers are typically under-resourced and rarely have time or space to take on juniors and help get them the experience they need. Unfortunately, without higher ups understanding and believing in UX, even hiring seniors often results in failure of the UX team.
  5. Very few folks I talked to have specific tools they prefer folks to know how to use, except in cases where getting permission to use specific tools is complicated. This is especially relevant given the sheer number of tools out there, whether for wireframing, prototyping, or creating high-fidelity visual designs.

Keep learning

  1. It’s hard to figure out what online resources and books are the most useful to read or follow.
  2. It’s important to keep toward learning more about UX — even for folks who have a UX job. The field is constantly evolving.

Getting experience and taking criticism

  1. It’s difficult to get experience before you have a job in UX. This may be worse for researchers, as visual designers have an easier time selling their skills (but ‘looking pretty’ may not actually translate to ‘useful’).
  2. Even if you’re not great at sketching by hand, it’s really important to be able to jot your down ideas on paper visually. This offers a way to communicate your thoughts, and is quick and easy enough that you’re less likely to be attached to the ideas you’ve come up with. In turn, the sketchiness and reduced attachment makes criticism easier to take.
  3. Work with other folks on your designs. Practice giving and taking criticism, because no one gets it right on the first try. Design is a process for a reason, and there’s a lot of different pieces to it.

Possible solutions?

Getting experience

This is a significant problem. Given that few places are hiring folks without a couple of years of experience, newbies and career changers need to find ways to get that experience.

For those who can afford it and have access, in-person UX programs like Bentley’s master’s in human factors program and Jarod Spool’s Center Centre are an excellent choice. These offer curated and guided information, connections, and practice at design. Unfortunately, these and other programs rely on proximity and available time and money, and are not inexpensive (although Center centre tries to mitigate that part).

There are also online courses which can be helpful, and bootcamps both on and offline, but these again cost money and may or may not offer built-in networking.

So how does one find work, even if unpaid? There’s a few options that I am aware of:

  1. If you can make Code for Boston’s weekly meetings, that’s a good option. They tend to have ideas for what to work on, and specifically mention both developers and designers.
  2. You can find other folks looking for UX work, and see if they want to team up with you on something. This is especially useful if you each have different skills: like a researcher and a visual designer, or a UX person and a developer. This does require being able to find those folks, and is one possible option for how my project can offer help. These designs are less likely to go live, but any projects are better than no projects.
  3. You might be able to find non-profits who need help, although this does require a) that the non-profit is able to understand the value of what you can offer them, b) you know the right people to talk to, and c) that they have someone able to implement the suggestions you make. Attending a Give Camp may help with those problems, but the New England page appears to not be functional (the website for it goes to a godaddy page). This may be another thing I can offer help with through UXPA.
  4. Outreachy might be another option. This is a program to help women and minorities get into open source software, and is not specifically focused on UX. However, I was able to do a UX research and interaction design project with the Fedora Project through outreachy, and it was fabulously helpful and interesting.
  5. You may be able to find an open source project to help out with, such as Red Hat’s Patternfly Design Library (also on github).
  6. Do you know any developers working on projects in their spare time? See if you can help them out.
  7. If you are currently in school, or just recently left, look for design internships. These are easier to get if you have some design experience, perhaps through your classwork.

Options 2 and 6 may be more difficult for designers just starting out, as they are much easier to do if one has some guidance for how to approach design problems.

Finding a mentor

Mentorship is really important, especially if you cannot afford to attend school and get guidance that way. Unfortunately, it can be difficult to find a mentor, and precisely what a mentor can offer or do for you varies by the mentor.

Ideally, I think that mentors should offer:

  1. Guidance around how to start or continue your UX learning process.
  2. Suggestions for how to improve the things that you’ve identified as weaknesses in your skillset. Alternately, ways to identify those weaknesses.
  3. Portfolio and resume reviews.

Beyond this, it’d be lovely if mentors could offer networking help (eg: connections to open positions and folks who may eventually have open positions), and suggestions for projects to work on.

The XX UX community offers a mentorship matching program in some cities, although Boston is not yet one of them. This may be another opportunity for my project to help folks out, whether by working with XX UX (which would mean it’s only available to women), or by building on their example and making our own program.

Curated resources

Given how much information there is out there, a possible way to help folks out would be to offer resources that experienced UX folks agree would be useful to those who are starting out.

These resources could include basic guidance for portfolios for various design specialities, design interviews (including design exercises), and job applications, as well as structure within which to learn design processes.

Also relevant might be instruction on persuasion, on communicating and working within cross-functional teams, and on presentation skills (both creating a presentation and presenting it).

We might want to include specific information such as the use of short-cut keys within design programs (Ctrl d, alt Ctrl shift arrow keys for movement, etc), recommendations for tools to start out with and an introduction to their use, and suggestions for how to use those tools to more easily share and maintain one’s designs (since all good design involves many different folks in various different teams).

Finally, we could offer recommendations for good books for folks in various stages of learning.

Keep learning!

One of the most important things for someone new to a field is to keep learning. Be visibly interested in and passionate about your field: it’ll communicate itself to those you are working with, and will help keep you informed and aware of what’s going on.

At the same time, don’t believe everything you read — some folks make things look more clear-cut and simple than actually happens. Reality is messy!

Don’t be afraid to try things out. No one in UX knows everything about it, and mistakes are how to learn.

Remember to mention others who had a role in any design you talk about: design isn’t typically an individual process (collaboration is important!), and hiring managers want to know that you understand and can talk about your role in the project.

If you’re interested in research, learn both qualitative and quantitative methods. Most of your work will probably be in qualitative spaces, but it’s useful to be able to measure success (are we accomplishing our goals?). It’s also helpful to understand basic data visualization techniques.

Remember to take pictures at all stages of your process! This will be hugely helpful when it comes time to make your portfolio.

Flock 2017, Cape Cod, Masschusetts, USA

Posted by Suzanne Hillman (Outreachy) on September 02, 2017 06:25 PM

Hi folks!

I returned from Flock 2017, which was in Cape Cod, MA this year. This was my first Flock, largely as a result of my Outreachy project. I will be claiming my Outreachy travel fund for it, and likely would not have gone were it not for that fund. I’m still job hunting, and all!

There is no substitute for in-person interaction!

Fedora folks are very friendly. :) OK, at least the ones at Flock were! Being there reminded me of the aspect of my Regional Hubs design wherein a major goal was to encourage in-person interactions because they’d increase the chances of people remaining engaged with the community. I’d say Flock definitely confirms this goal, given the number of ways in which people — including myself — were becoming more involved simply through chatting with others in the community.

I’d say one of the major effects of my time at flock was making people I’ve spoken to only through IRC and email more real. I do find in-person interaction so much better! Of course, I also really like people and being around people, and lack of a job means I am not really getting a lot of that (I’m one of those weird introvert/extrovert combination people).

I met a lot of people, although being partly faceblind and poor at remembering names made (and makes) that more complex. Hopefully people remember me, even if I can’t remember who they are!

Presenting my work

<figure><figcaption>My best approximation of a UX design process.</figcaption></figure>

I gave a presentation on my UX work for Regional Fedora Hubs, with the goal of helping others be able to do basic UX work on their own development projects. I did most of the talking, and Mo was helpful for moral support and answering Hubs questions I didn’t know the answer to. The presentation and handout are available on my website, and the video will also be available there once I have access to it. I’m not certain how likely others are to use that information, however. I did find that people asked relevant questions at the end, suggesting that not only did they follow my talk, but they were interested enough in it to be curious about things I hadn’t mentioned.

I appreciated the chance to present to a new audience, and to gain additional practice in presenting and preparation thereof.

What did I learn? What did I do for the first time?

I also appreciated the opportunity to attend various sessions on UX, both to see how other people do certain tasks and to add additional tools to my toolbox (microtesting, “SUS” or System Usability Scale, and focus group-based usability testing all come to mind).

I enjoyed learning about various aspects of Fedora that I hadn’t yet encountered, whether specific technical concepts like modularity and project atomic, or being able to attend and contribute to the diversity team’s session. I also liked being able to get caught up on what’s been doing on with Fedora Hubs since Outreachy. I’ve been out of the loop there because jury duty for 3 months and various temp jobs make it difficult to attend the weekly meeting.

I created my first badge, albeit through a very simple change to an existing one. Additional experience with Inkscape with others around to guide me is always appreciated, given that I’d like more experience with basic visual design!

Now what?

I am not sure yet how I might best continue to offer my skills to the Fedora and open source community, but this conference has definitely confirmed my interest in doing so. Thank you Flock, Outreachy, and the organizers and participants thereof!

We’ll see if I can figure out some way to make the next Flock. :)

Calling all UX peeps

Posted by Suzanne Hillman (Outreachy) on August 15, 2017 01:27 AM

Yesterday I mentioned a discussion I was involved with on Facebook in which someone on the board of UXPA Boston suggested that I could organize a program for UX newbies and career changers.

I’m really pleased by this idea, and very glad she suggested it. However, before I bring my ideas to the board and get advice and help, I want to have slightly more clue than I currently have.

So, research!

The best way I can think of to get more clue is to talk to people in the UX space. I’d like to talk to other people who are new, people who do the hiring, and people who are working in UX with other UX team members.

UX Job Seekers

Based on my instincts and some of the suggestions on the FB discussion, I suspect people trying to get into UX full-time struggle with:

  1. Getting experience
  2. How to best structure their portfolio and resume
  3. Becoming known to companies

Some off-the cuff ideas of ways to help with these:

  1. Internships, co-ops, programs like Outreachy/Google’s Summer of Code/akamai’s technical academy, mentorship, apprenticeship, small multi-person design projects, and UX hackathons
  2. Finding mentors, having get-togethers to review portfolios and resumes (among each other), and developing sustainable ways to get feedback from hiring managers
  3. Things that I listed in option #1, company visits, and informational interviews

UX Hiring Managers

I have a lot of interesting ideas above, but I would need to know more about what hiring managers are looking for to understand what would be most useful.

For example, in an ideal world, what do hiring managers want to see from candidates? What would be most useful to determine if they want to take a chance on someone? What do they want to see them do, have done, or be interested in doing? What do they _not_ want to see? What do they struggle with figuring out, but very much want in their employees?

People currently on UX teams

Of course, not only do I need to know what hiring managers look for, but I’d like to better understand what people look for in their co-workers.

Such as, what do UXers find most useful when working with other UXers? What do they especially dislike? How well do their hiring practices seem to tease these out? What do you most appreciate in your co-workers?

How can you help?

If you are in UX, or trying to get into UX, talk to me! Comment or email me!

Patternfly User Dropdown

Posted by Suzanne Hillman (Outreachy) on August 13, 2017 07:51 PM

I’m back with more about Patternfly’s navigation bar user dropdown.

More from developer

I’ve done a brief, remote, contextual interview with the developer who originally asked for this to be researched. With this, I confirmed a few things about what his concerns are:

  • Accessing items within a dropdown takes more time and more clicks than without one
  • Dropdowns can be extra slow to interact with when on a slow network connection, especially when animations are involved
  • It’s easier to remember where to go to get to menu items that are top-level rather than under a dropdown
  • Frequent use items need to be easily accessed and easily discovered

Discussion with patternfly UX researcher

I’ve started a conversation with the UX researcher at Patternfly, Sara Chizari. In large part, I wanted additional perspectives on the problem. I was also hoping to learn if there is existing research on this topic that I’d missed.

My inclination is that the major goal of this research is two-fold:

  1. In the specific case of the developer I’m working with, what are the best guidelines for the use — or lack of use — of navigation bar dropdowns.
  2. In general, we need guidelines for the use of dropdowns.

I expect that these will also change with the display screen size: limited space constrains what can be at the top level.

How do we figure this out?

I’m not yet certain of the best way to go about figuring this out, which is part of what I’m discussing with Sara.

In this particular case, the dropdown is not expected to contain high-use items. While useful, I wouldn’t expect things like ‘settings’ and ‘log out’ to come up during the course of everyday use of an application or webpage. It’s difficult to be sure what other categories of items people are likely to wait to use here, but the real-world examples I have are suggestive:


It looks like basically everyone includes settings and sign (or log) out. Many also include help. Of these, I would expect that sign out would be highest use, especially for those folks who access the applications on computers that are not their own.

Because these won’t be high use items, I’m not yet sure how best to create tasks for people to do during a usability session. I don’t think I want to overemphasize actions that they might not otherwise do, as it’ll make it somewhat difficult to identify the highest use items. At the same time, I need to have people try different prototypes of the menu and menu area to see how they turn out in practice.

What do I think so far?

My instinct suggests that we will specifically want to test the usability of a few different things:

  • Dropdown of 3 or fewer items vs not being in a dropdown.
  • Logout, settings, and/or help being inside or outside of a dropdown.
  • Mobile vs tablet vs computer monitor

These feel like they will address the ‘dropdown vs not dropdown’ item number cuttoff point on various screen sizes, and the specific menu items that I believe to be the most frequent use.

I may want to identify the most used items in those dropdowns, before I go into more specific testing as per the above list. I’m not yet certain of the best way to approach this, however.

Now what?

Patternfly dropdown

Sara will be doing some literature research this coming week, and will then be busy until mid-Sept on her own projects. I’m hoping to figure out the kinds of things to be testing with the aim of starting usability sessions in September.

UX Newbies and career changers group?

In the meantime, due to conversations with the local UXPA group on Facebook, I’ve started investigating both problems and potential solutions facing UX newbies and career changers within the Boston area. The major goal here will be to figure out what types of things are interfering with getting new people into UX jobs, coming up with concrete things to do about them, and figuring out how to make those things available to people locally. I’d love additional perspectives and ideas, since I am only one of many folks trying to get into UX, and will definitely not have thought of all the obstacles (or possible solutions!).

What is Querki?

Posted by Suzanne Hillman (Outreachy) on August 11, 2017 06:05 PM

I’ve met with Mark, the owner and developer of Querki, a couple of times now. I shall now do my best to summarize my understanding thereof, with the purpose of identifying any obvious gaps in my knowledge and any clarifications that may be needed.

Querki is intended to support and encourage collaboration about and sharing of information within communities. The longer blurb on the Querki help page is:

It is a way for you to keep track of your information, the way you want it, not the way some distant programmer or corporate executive thinks you should. You should be able to share that information with exactly who you want, and it should be easy to work together on it. You should be able to use it from your computer or your smartphone, having it all there when you need it.


Everyone has a lot of information to keep track of, much of which they would also like to be able to share and discuss with others. Querki offers a customizable interface in which to manage, display, discuss, share, and explore small to medium data sets with small to medium-sized groups.

An existing example of this is from the Cook’s Guild in the local SCA chapter: they have recipes from specific time periods, and they figured out reconstructions of those recipes so that they can be made nowadays.


As you can see in the screenshot above, the recipes are categorized by type of food, period of food, and culture. Clicking on any of those — also known as tags — will bring you to a list of relevant recipes.

Many of Querki’s useful abilities are currently only possible using the Querki programming language (QL, said as ‘cool’) — such as finding a recipe for 14th century French pancakes in the above cook’s guild space. In the future, the plan is to make common tasks easy to do without the use of QL.

Basic Usage


To view a Querki space, one only needs a link to said space. Precisely what a space will look like varies depending on the desires of the owner of that space.

One of the topics that Mark and I are currently discussing is the idea of a basic default structure for a space . This would hopefully mean that those who don’t want to spend a lot of time structuring their space will still have usable spaces for people to access, discuss, and interact with the data. For those who want to affect structure, that can be done when one has time and inclination, smoothly allowing the transition from a basic Querki space structure to whatever modifications are desired.


A Querki space is meant to be a place for information to be stored and shared. To do this, however, one needs to tell Querki how you want your information to be structured. A model is how you tell Querki the structure you would like for your information.

For example, a model for a CD might include properties for the album title, author, song lists, genre, and publication date, as well as an auto-generated name of the model. Properties can be added when the model is first created, as well as after the fact.

Properties have types. Types include the tag type, the text type, the photo type, and the views type, among others. Properties can themselves have properties, such as with tags. Tags are both the name of a thing and have the possibility of pointing to a related model. Tags may have a description, visible when the tag name is clicked, or simply show a list of things with that tag.

Views are ways to display models. The current default view shows a list of things with that model associated with it. There is also the possibility of a ‘print view’, which will tell Querki how to print the model.

Models will have instances of that model: rather than the generic properties that models contain, instances contain information specific to the instance of that model. In our CD model example, you might have the CD Zoostation by U2, as an instance of the CD model.

In addition to models and their associated pieces, Querki has pages. These are unstructured, and may be understood as a report from a data base, or a wiki page.

What else?

Major goals of Querki

  • Allow for integration with existing social networks in order to help people connect with and invite people they know to work together on Querki.
  • Get Querki to the point of general availability (it’s currently in beta) and having people interested in paying for it. It’s not yet clear what this entails. More investigation required.

Different skill levels of users

Currently, there is an idea of an ‘easy’, ‘medium’, and ‘hard interface. These largely describe the degree to which one needs to be able to program to get the interface to do what you want.

  • The “easy” interface is meant to allow people to use a published template (aka ‘an app’) from an existing Querki space to structure their own, and to use someone else’s space.
  • The “medium” interface allows more customization, but doesn’t present the more complicated/confusing programming options to the user.
  • The “hard” interface is meant for hard-core programmers, allowing the use of every tool available in Querki. This allows the building of templates (apps) and lots of power user commands through the underlying programming language QL (pronounced “COOL”).

It is not currently very clear to users what their options are for using QL.


Search is very basic right now, with searches being within a Querki space, on plain text strings. The goal in the future is to include the ability to search across spaces as well as objects, including tags.

There are currently icons for editing a page, refreshing a page (with your changes?), and publishing a page (for those spaces which do not want changes to happen immediately during editing). Are these reasonable things to have as icons? Do they need text also/instead?

Mobile is very important! Consuming a page should be possible even on small phone screens. Editing should also be possible on a mobile phone. Designing a page for a phone isn’t likely due to small screen, but planned for tablets.

Data manipulation/query building talks about the need to do some basic filtering and sorting of the information in an instance. We need to figure out the most common queries of this type, and see how many can be abstracted away from the underlying programming language for use by anyone/everyone.

Specific pages in need of (design?) work: front page, help, contextual help, model design page/advanced editor. The programming UI needs help (see the design page), and likely needs a simple IDE.


Querki spaces are mostly publicly visible, which should help come time to improve the login page/start page.


Tag names cannot currently be the same name as the model associated with them, due to the fact that tags point to a related model rather than containing it. This may need to be invisible to users to avoid confusion?

Recycle Bot

Posted by Suzanne Hillman (Outreachy) on August 09, 2017 08:42 PM

I’m working on a toy project with a Northeastern student to get us both more experience with UX.

What is it?

The student I’m working with, Radhika Sundararaman, came up with the idea of a robot that would carry recycling bins from someone’s home to the dropoff point. This is most relevant for people who live in condo associations and other larger housing complexes with the dropoff for trash and recycling at some distance from their homes.


We expect the main users to be folks who are unable to walk, unsteady on their feet, or do not have the strength to carry a bin. We imagine this to be relevant for older adults and differenlty-abled folks.

In addition, we think there is a market here for folks who are too busy or too forgetful to get their trash out regularly.

What are we looking into?

Our focus for this project is the user interface.



We have done quick interviews of a few different people, and came up with 5 personas.

These include an older adult couple, a single mom with two kids who works full-time, another mom with three kids whose husband is typically away on business, an office manager, and one adult of three whose household often forgets to bring out the recycling.

While exploring the personas, we identified a need for a website, a mobile app, and buttons on the robot itself.

Each persona includes important information about the context of each person’s trash situation. Some of the more relevant points include:

How do they find out about changes in trash pickup?

  • Poster in the room with the mail
  • Voicemail
  • Email
  • Paper schedule mailed out every year

How far are they from the pickup location?

  • 500 feet
  • Up a large hill
  • On the curb next to the stairs leaving the house

How much trash do they usually create?

  • Minimal
  • Lots — small child still using diapers

What sorts of difficulties do they run into?

  • not home on trash dropoff day
  • too busy
  • Forgetful

Tasks & Scenarios

During our task and scenario analysis session, we decided that one of the 5 isn’t a user we will focus on at this time, and another was covered pretty well by the first three users. We used sticky notes and a handy empty wall to organize our thoughts and discussion.

We started the process by writing down what users would do in the case where there were no errors. We made notes of where errors might occur, and things we might like to include as options in the future.

<figure></figure><figure><figcaption>Who are we talking about? What are the main points to keep in mind? How might they want to interact? What are the goals?</figcaption></figure><figure></figure><figure></figure><figure><figcaption>The actions that users might need to do, problems they might run into, and ways we might handle those problems. Also a short list of things to keep in mind for the future.</figcaption></figure>

We translated those into step-by-step descriptions of how a user would do their ideal actions with our software. Finally, we investigated those situations where things didn’t work out quite right for one reason or another, and explored how that might translate to our software.

<figure></figure><figure><figcaption>What are the situations for ‘things working as expected’? What do we need to have for settings and configurations?</figcaption></figure>

Once we had gotten to a point where we felt ready to start sketching, we also translated our sticky notes to a digital format for greater ease of access and reference. We do not have a centralized location in an office building to leave them, so this is the next best thing.

What are we not doing?

We will not be creating the robot itself, as this project is meant to complete before Radhika returns to school in September. Neither of us has the technical expertise to focus on construction, and my experience with robots strongly suggests that this is not a simple problem to solve.

We are assuming a few things about the robot as part of our design process:

  • It will not be able to handle stairs
  • It has a weight limit on how much it can carry
  • It cannot pick things up

Next steps

Our next steps are to start sketching our ideas and discuss what we have each sketched. This will allow us to get onto the same page about our ideas, and come up with more effective and useful interfaces as a result of the exploration we will do.

Still plugging away

Posted by Suzanne Hillman (Outreachy) on July 20, 2017 01:06 AM



I’m playing around with Wix for my website, in part because it’s a giant pain to change things around in my (still official) Pelican-based website, and in part because it’s useful to have the very ‘what you see is what you get’ perspective that Wix offers. I’m still deciding where a good point between ‘offer an overview’ — missing from the pelican version — and ‘not enough details’ — true of much of the Wix version right now — is.

<figure><figcaption>Pelican version of my site</figcaption></figure>

For the moment, any major changes that I think are important to include, I’m trying out in Wix first, and then figuring them out in Pelican. That which is frustrating me most right now is the apparent lack of grid support in Pelican, since that would make so many things look nicer and be easier to follow — indeed, that’s why I don’t have much overview in Pelican right now.

I’m hoping I can get Pelican-alchemy to work as a theme, as it appears to support bootstrap, which itself supports grids. Unfortunately, I can’t figure out how to get it to stop ignoring the settings I have in the style.css file. And, because it’s not as professional-looking without that, and it’s hard to see what things look like there without publishing them first, it’s slow going to figure out. I just want a clean style and grids!

Alternately, I need to continue to move things over to Wix and just give up on Pelican. But it’s a lot of work. And slow. Which is why I’m trying to get obvious wins over to Pelican in the meantime.


I’ll be meeting up with the person who is working in Querki next week, to get a decent basic understanding of his goals and needs, as well as to figure out the reasoning behind some of the current decisions.

I need to get in touch with people about doing a contextual interview with them about putting their recycling out for pickup. This is for the project I’m working on with the Northeastern student.

I’m also hoping to get a contextual interview with the developer who originally had concerns about user dropdowns. He has provided some screenshots of the kinds of places he runs into the problem, so I need to integrate those into our shared google doc, and figure out some next steps if he’s not willing to do a contextual interview.

I also need to grab some time to continue with my review of the accessibility document in patternfly.

Job Hunting

I am thoroughly confused about the status of my RedHat application. Theoretically, I was supposed to hear something after 5 days when I went through Mo for applying. Of course, I was also supposed to have had three applications through her, and only one managed to actually associate with her name. As of right now, it still says ‘manager review’ — whatever that means. That’s better than the other two, which say “no longer under consideration”. Confusingly, the job titles are all very different from what I actually applied for (the one I’m “under review” for talks about doing development, which… not so much).

I’ve also got an application in with Wayfair, whose UX team is fairly large and has openings at multiple levels of skill. We shall see.

I was contacted by someone at Onward Search, yet another UX recruiting agency. He seemed pretty impressed with my background, and optimistic about being able to find me some possibilities. We’ll see — I’m working with a _lot_ of UX recruiting companies at this point.

Easy way to fix non functional ctrl key

Posted by Luya Tshimbalanga on July 18, 2017 05:18 PM
Ctrl key buttons refused to work on laptop?
  • Tried pressing Ctrl + Alt + Fn? Mixed result.
  • Reboot hardware? No dice.
  • Pressing Ctrl + Left click on Touchpad? Worked

I am not sure what exactly caused the problem as the issue surprisingly affects more models than expected.

I’m happy to find time to talk about it; in person or skype work for me. :)

Posted by Suzanne Hillman (Outreachy) on July 08, 2017 03:16 AM

I’m happy to find time to talk about it; in person or skype work for me. :)

Thanks for link!

Done with Jury duty

Posted by Suzanne Hillman (Outreachy) on July 05, 2017 05:23 PM

That was a long and tiring experience, but now I’m not able to be called in again for it for 6 years.

I’ve been helping out with Patternfly. I started by helping to fix easy bugs in an effort to get a good understanding of their processes. I’m now helping to edit their accessibility document and working with one of the developers on a UX research project.

Navigation Bar User Dropdown

The UX research project in question is to determine how user friendly the common pattern of the user (profile? settings?) dropdown actually is. For example, see this upper-right dropdown:

Before click:


After opening the menu:


Under ‘More options’:


The developer I’m working with had concerns about the extra clicks required to get to items in the menu, the extra processing time to read and interpret those items, the speed with which the menus actually open, and the quality of the animations for the menus.

This dropdown is very common for tools within RedHat, since they are generally based on patternfly’s pattern library.

Has anyone already researched this?

My first goal was to get an idea of what, if anything, online research says about this. Curiously, I was unable to find research specifically on the user dropdown pattern, even though it’s everywhere nowadays.

That said, I did confirm my suspicion that it’s generally better not to hide high-use items behind a menu. There were a variety of reasons for this, including the ability to find out what is possible, remember what is where, and the extra time to locate the actions.

This suggests the need to know what, if anything, within the user menu is likely to be high-use. Unfortunately, the example I currently have is not a real example, and I’m hoping to get some real-world examples of what the developer has struggled with soon. This will make it much easier to identify the tasks that might cause one to need to use the user dropdown, and gather information about how high-use those might be.

What might we do?

One possibility I’ve suggested is that if there are some high-use items in there, they might be better off outside of that dropdown. The following example assumes that settings is the highest use option, and that we have minimal screen real-estate (on a mobile phone, perhaps).

For example, instead of the existing top-level controls:

<figure><figcaption>Balsamiq version of the controls</figcaption></figure>

Have the settings control be at the same level as the others:

<figure><figcaption>Now you can use the settings without the dropdown</figcaption></figure>

On a larger screen, I’d suggest that the settings gear — while in common use — should be the word ‘Settings’ to improve usability.

What next?

Once I get some real-world examples, I think the next step will be figuring out what questions we want to get answers for. Since we’re hoping to get an idea of how much this particular pattern affects users — within RedHat and perhaps more generally — we’re going to need to figure out what sorts of tasks are likely to send people into that menu.

I’m also going to want to select some good examples of the situations we’re most interested in. On top of whatever real-world examples we think are most relevant, we’ll want to offer users other options. If, for example, we suspect that settings and logout are the most likely options to use, we’re probably going to want to offer interfaces with one or both of those outside of the dropdown.

Currently, I’m waiting for information from the developer before I can continue.


A friend of mine has been working on a project for a few years now, and it occurred to me that I could offer him UX feedback on it. He’s working on it part-time nowadays, so I’m currently waiting for some background information from him. I need to know where is it so that I can see it, how he would describe it to people, and what he wants people to be able to do with it.

Early stage project with someone from Northeastern

I’m recently started discussing a possible project with a technical communications Masters student from Northeastern. She’s interested in getting more experience with UX, and I figure it’ll offer me more experience and mentoring people isn’t bad.

We’re currently trying to identify areas of UX that we are interested in, both in terms of domain (e-commerce? Machine Learning? IOT?), and in terms of specific aspects of UX (usability reviews? Design updates? Or specific pieces like transitions as related to optimization of interstitial anxiety or hapnotics?). If nothing else, time spent researching some of these should be time well-spent.

Still job-hunting

And, I’m still job hunting. Which is still frustrating, because a year and a half of experience means people rarely get back to me. Or it could be something else, but because no one gets back to me, I have no way to know.

In the cases where I apply through someone at a company, they usually say something like “we’re going with someone who more closely matches our needs”. Maybe that’s amount of experience? Maybe something else. Who knows?

I’m keeping an eye out for temp and contracting positions, because they can lead to full-time and are at least paid experience. We’ll see.

Propose a talk for Flock!

Posted by Máirín Duffy on June 08, 2017 12:43 PM

Propose a talk for Flock!

Flock 2017’s CFP is open!

We need your Flock session proposals!

This year’s Flock is more action-oriented compared to previous Flocks. The majority of session slots are hackfests and workshops; only one day (Tuesday the 29th) is devoted to traditional talks.

Calendar showing days of Flock - Tue Aug 29, Wed Aug 30, Thu Aug 31, Fri Sep 1

The registration system allows you to submit 4 different types of proposals:

  • Talk (30 min) – A traditional talk, 30-minute time slot.
  • Talk (60 min) – A traditional talk, 60-minute time slot.
  • Do-Session (120 min) – A 2-hour long hackfest or workshop.
  • Do-Session (120 min) – A 3-hour long hackfest or workshop.

There is no session proposal limit. Feel free to submit as many proposals as you have ideas for.

Our CFP ends June 15 so you have one week to get those awesome proposals in!

Submit your Flock session proposal now!

How to create a strong proposal

How can you ensure your proposal is sufficiently strong enough for acceptance into Flock? Here are some tips and guidelines:

Align your proposal to Fedora’s new mission statement.

Fedora’s mission statement was updated almost two months ago. The revised and final mission statement is:

Fedora creates an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.

If you can explain the connection between your session and this goal, you’ll make the proposal stronger. Even if you are not directly working on a hardware, cloud, or container effort, you can relate your session to the goal.

For example, say you’d like to propose a Fedora badges hackfest. Task the badges hackfest specifically with creating badges for activities associated with efforts aligned specifically with hardware, cloud, and container to strengthen it.

Make sure the folks relevant to your topic are involved.

If you want to propose a Fedora badges workshop, that’s totally cool. You might want talk to Marie Nordin or Masha Leonova, and see what their plans are, give them a heads up, and coordinate or even propose it together with one or both of them.

The committee reviewing proposals occasionally sees duplicate / overlapping topics proposed. Generally, the committee chooses the proposal that has the subject matter experts most involved in the topic. A weak proposal on a topic has no indication of involvement or coordination with subject matter experts most actively involved in a topic.

Make the audience for your topic clear.

Think about who you are giving your talk to or who you want to show up to your workshop or hackfest. If you’re proposing a Fedora Hubs hackfest, are there enough Pythonistas in Fedora to help? (Yes, yes, there are. 🙂 )

Tailor your content for your audience – while you may be able to get folks familiar with Python, they may not be familiar with Flask or how Fedora Hubs widgets work, so make sure your proposal notes this material will be covered.

General user talks are discouraged. This Flock will be focused on empowering Fedora contributors and actively getting stuff done, so make sure your audience is a subset of existing Fedora contributors.

Focus on taking or inspiring action.

A major focus of this year’s Flock is taking action, so talks that inspire action and hackfests / workshops where action will take place are going to be strong proposals.


Feel free to ask on the flock-planning list if you have any questions. Or, if you have private concerns / questions, you can email flock-staff@fedoraproject.org.

The Flock planning committee is looking forward to seeing your proposals! 🙂

Submit your Flock session proposal now!


Scribus 1.5.3 available on COPR repository

Posted by Luya Tshimbalanga on June 06, 2017 06:46 AM
Scribus 1.5.3 is now available on the new COPR repository while scribus-unstable is now switched to 1.5.4 snapshot.
Highlighted featurese for 1.5.3 are:
  • The most important change isn't immediately visible, namely a completely rewritten text layout engine, which supports complex scripts like Arabic, Hindi or Thai, as well as providing access to advanced OpenType features, such as ligatures and alternate glyphs.
  • Scribus now follows the XDG standard for configuration files. Therefore, the Scribus preferences directory has moved from ~/.scribus/ to a new default location: ~/.config/scribus/
  • The performance of copying and pasting objects in/from/to files with huge color palettes has been vastly improved. 

Measuring things only makes sense if you know what you’re measuring, why, and what you intend to do…

Posted by Suzanne Hillman (Outreachy) on May 26, 2017 08:50 PM

Measuring things only makes sense if you know what you’re measuring, why, and what you intend to do with it. Otherwise, even if you _have_ numbers, they don’t actually have any meaning. So what’s the point?

Applying for a UX volunteer job

Posted by Suzanne Hillman (Outreachy) on May 04, 2017 12:13 AM

I’m trying to keep myself in the UX game, which is complicated by the grand jury thing lasting through the end of June and making contracting positions difficult to do right now. My mentee (who is really only slightly behind me in her UX path) commented that she’ll be looking to work with non-profits and government sites such to get more experience.

She pointed out https://www.catchafire.org and https://www.taprootplus.org/ as possible places to hunt through. A quick glance at catchafire when we were co-working to get an idea of what possibilities there were, and I saw something called a ‘website audit’ for the American Cancer Society.

“Huh,” says I. “What is a website audit?”

Looking at their list of needs, I see that they want a report that includes an outline of the organization’s goals for the site, feedback on the current site’s UX in general (they give specifics, but I think my summary is accurate), and recommendations for improvements to help achieve the desired goals.

Looks like UX research!

Ok, interesting. This sounds a lot like UX research, mostly. With some prep work to figure out what they mean by ‘organizational goals’ and who their users are. Given that these goals could as easily mean ‘goals that someone in the organization thinks sounds good’ as ‘goals that were researched throughout various facets of the organization as well as users’, I think that’s going to be one of the first things I want to figure out.

They already have a site and some goals, which at least means that I should be able to work with them to figure out whose goals those are, and how specific they are. I’m not entirely sure what they mean by ‘built out site’, although I suspect they may mean working prototype. I don’t _think_ they mean the existing site?

They specifically list millennials as a target market, and I’m really curious as to what they actually mean by that. They say they want to engage young professionals, which is… rather non-specific, but certainly better than nothing.

What do I want to find out?

I’ve got a call with them Friday morning to see if we’re a good fit, and I’m going to focus on what they mean by organizational goals and who their actual and prospective users are. I strongly suspect that my QE experience will combine nicely with my UX research experience for this particular project, so we shall see. And hey, it’s a good cause!

I’m also noting that they suggest up to nearly half-time work hours for a month and a half. This may be too many hours what with three days eaten by jury duty, but we’ll see.

I do hope it’s not an SEO website audit (which is mostly what google says about websites audits) as I’ve no strong sense of those, but given that SEO shows up nowhere on that volunteer job description I doubt it. Worst case, I adjust my thinking and do some online research to see what’s relevant. This looks useful in that case!

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