top of page

Hubs Design and Usability Testing

One of the most interesting parts of the Regional Fedora Hubs project was working with my team to figure out how to best handle collecting, storing, and using location information.

 

Within the design section, I will describe the process I used to explore, design, and iterate on this problem.

​

In the Testing section, I will focus on the Finding People prototype, as that resulted in more interesting usability problems.

User locations - Design
Flowchart and sketches

First, I developed a stronger understanding of our brainstorming session through the use of a flowchart and some handwritten sketches.

This person has a FAS account with some location information in it.

On top is someone with a FAS account with no location information, and on botton is someone who does not have a FAS account.

For additional sketches, see this Flickr album.

This person has a FAS account with all location information in it.

Balsamiq Mockups

I then moved to Balsamiq mockups, iterating based on stakeholder feedback.

 

For additional mockups from the Regional Fedora Hubs project see this Flickr album.

First mockup, before feedback

Mockup after feedback from Fedora UX lead

(associated pagure ticket)

Locations are not a solved problem

While reviewing feedback, I realized I had been making inaccurate assumptions that the technical underpinnings for locations were an already solved problem. This was definitely not the case, and it turns out that locations are a very complicated problem to solve. 

 

We decided to avoid the need for street addresses and any information between the city and the country by presenting locations on a map in the center of a given city. To best show proximity, street address were not necessary. 

Discussion with the lead developer brought to light another major assumption around locations that would need further exploration before Regional Hubs could be brought to life.

Further design details

For further details on the design work for this project see: 

 

 

I also have a page on the survey for prioritizing the order of integration of social media and photo sharing platforms.

Usability Testing
Finding People Prototype
Identify and Describe Tasks

I identified the tasks that were possible with each prototype, prioritized those tasks and the prototypes based on frequency of use and number of people affected, and came up with potential task descriptions for the highest priority tasks. With feedback from Mo, I improved the clarity and specificity of the wording of my possible tasks and determined the optimal number of tasks to test with during each session.

Finding ​​​People

​​​

  1. 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.

  2. 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.

During the Sessions

Early Adjustments

 

After the first two sessions, I realized that any individual should only be asked to do one of the two tasks in people, events, and join us or sign up. These tasks were too similar and were confusing people when they were asked to do both in a single session.

 

In the initial prototypes, the top-most bar was a screenshot from Fedora Hubs, and too realistic-looking compared to the rest of the prototype. This made it difficult to determine whether participants were using it over other search options due to that increased fidelity or because of an underlying confusion resulting from the design decisions in the prototype. To better differentiate between the two possibilities, I replaced the screenshot-based search bar with one from Balsamiq.

 

Summarizing

 

With information from my notes and transcriptions, I created a spreadsheet to organize and filter what I had learned. 

Analysis and Discussion

Mo and I met to discuss and brainstorm possible solutions for problems my participants had run into. One of the more complicated problems focused on identifying which of a list of people one might select to contact. This was not related to locations as with the rest of this page but instead was about the relationships between people.

Do I know Jen Smith better than John Holsberg? Who knows?

Who do I talk to?

 

The tasks for this prototype required that participants select someone to contact. However, none of my participants was sure if anyone was a better or worse selection than any other. 

 

Some participants mentioned that they would appreciate information to indicate what, if any, relationship they had with the folks in the list.

 

  • Who did they already know?

  • Who were they on a team with?

  • Who did similar work to them?

  • Who had they been conversing with?

  • Who did their friends know?

 

Others noted that even without an existing connection to someone on that list, knowing who was interested in talking to or meeting new Fedora folks would ease their discomfort with contacting strangers.

 

 

Possible solutions?

 

Mo and I discussed the fact that identifying relationships between folks on Hubs could get quite complicated: 

 

  • We could decide that people who are following each other are friends.

    • Following someone in Hubs means that you see their Fedora activity in your stream.

    • Sometimes you might decide against following someone who you think is fabulous because their work isn’t relevant to yours, or you don’t have the time to add yet another person’s activity to your stream. Mutual following may not be the right axis to base friendship status on.

  • Maybe you’re on a team with someone.

    • This likely means that you’d be interacting with them regularly, and suggests that team connection may be more relevant than one’s following status.

    • However, what if you’re on a large or highly geographically distributed team? You might never have a reason to talk to some of the people on your team.

  • There are probably people you talk to regularly, via IRC, email, or some other work-related communication.

    • This probably means that you know them.

    • However, this may not mean that you’d prefer to ask them for help or to meet up with them.

 

As of yet, the best types of relationships to signal between Fedora members is unclear. However, this is useful information to have, and further investigation is required.

 

 

Indicating interest in meeting or helping strangers should be easier to determine, since it requires no information about relationships between folks. However, the best way to implement this is not yet clear. 

For example, we could use an open/closed sign, but that may not provide granular enough information. We want this to be easy to use for people who want to specify what kind of availability they have and easily understood for those who want to know who to contact.

 

 

For additional details on our analysis and discussion, see my usability testing and analysis post on Medium.

bottom of page