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:
<figure>
</figure>
The next part is a quick visual for what search might look like for that list.
<figure>
</figure>
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.
Search
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:
<figure></figure>
Then, the month view:
<figure></figure>
The list view:
<figure></figure>
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.
<figure></figure>
And show stuff about an event if you hover over it (and then click it), default view:
<figure></figure>
Month view, event more than a week out:
<figure></figure>
Month view, event has passed (I’m struggling with this one!):
<figure></figure>
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):
<figure></figure>
See ticket #281 to follow along!
Notifications
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:
<figure></figure>
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.
Uncertainties
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.