Máirín Duffy

Fedora, Fedora Design Bounty, New Contributor Opportunities

Enabling New Contributors

by mairin on September 27, 2017 • 1 Comment

I had a random idea today and wanted to share it in case anybody has thought about this too, or tried something like it, or could add on to the idea.

How We Onboard Today

I onboard, mentor, and think a lot about enabling new contributors to open source software. Traditionally in Fedora, we’ve called out a ‘join’ process for people to join Fedora. If you visit join.fedoraproject.org, you’ll get redirected to a wiki page that gives broad categories of skill sets and suggests Fedora teams you might want to look at to see if you could join them.

I started thinking about this because I’m giving a keynote about open source and UX at Ohio Linux Fest this weekend. One of the sections of the talk basically reviews where / how to find UX designers to help open source projects. Some of the things I mention that have proven effective are internships (Outreachy, formal Red Hat intern program, etc.), training, and design bounties / job boards. Posting UX assistance on say join.fedoraproject.org? Didn’t come up. I can’t tell you if I’ve actually onboarded folks from that workflow – certainly possible. My best success ratio in onboarding contributors in terms of them feeling productive and sticking around the community for a while, though, is with the methods I listed above – not a general call for folks of a certain discipline to come to the design team.

In fact, one of the ways we onboard people to the design team is to assign them a specific task, with the thought that they can learn how our team / processes / tools work by doing, and have a task to focus on for getting help from another member of the team / mentor.

Successful Onboarding Methods are Task-Oriented

Thinking about this, these successful recruitment methods of new contributors all focus on tasks, not skills:

Internships – internships have a set time period focused on the completion of a particular project, scoped for that duration and complexity, that has been documented for the intern. This is such that digging through archives of proposed Outreachy and GSoC projects unearths (if it were still current) a great set of directions that any new contributor could use to get started.
Training – in my experience, when training folks without UX experience in UX, they had a specific task they were working on already, knew they needed the skill to complete it, and sought out help with the skill. A task was the driver to seek out the skill.
Job board postings – (e.g., like opensourcedesign.net/jobs) – they are focused on a specific task / thing to do.
Bounties – super task-focused!

If onboarding new contributors works well when those new contributors are put to work right away on a specific, assigned task with a well-defined scope, why do we attempt to recruit by categories of skills with loose pointers to teams (that get out of date), instead of tasks? You might have someone fired up to do *something*, but they’re redirected to a wiki page, to a mailing list, to wait a few days for something to respond and tell them “hi, welcome!” without actually helping them figure out what it is they could do.

An Idea For join.fedoraproject.org

If you’re with me here, up to this point… here’s the idea. I haven’t done it yet. I want to hear your feedback on it first.

I thought about redoing join.fedoraproject.org as a bounty board, really a job posting board, but let’s call it a bounty board. Bounties are very well defined tasks. I did a talk on how to create an effective bounty a while back, here’s the high-level crash-course:

Set the Stage. Give the narrative around the task / project. What is the broader story around what the software / website / project / etc. does? Who does it help? How does it make the world a better place? Most importantly, what’s the problem to be solved that the bounty taker will work on, and how does it fit into that broader narrative?
State the Mission. Make a clear statement at what exactly the bounty is – state what the successful completion of the bounty would look like / work.
Provide a Specification with Clear Examples. Give all the details needed – the specification – for the completion of the work. Is there a specific process with steps they should follow? Provide those steps. A specific language,or a specific length, or a certain number of items? Make this all clear.
Provide Resources and Tools. What are the resources that would be the most useful in completing this bounty? Where is the IRC channel for the project? The mailing list? Are there any design asset / source files they will need? How about style guidelines / specifications to follow? Will they need to create any accounts to submit their work? Where? Are there any tutorials / videos / documentation / blog posts that explains the technology of interest that they could refer to in order to familiarize themselves with the domain they’ll be working in? Link out to all this stuff.
Outline the Benefits. Clearly and explicitly state what’s in it for them to take on this bounty. Job sites do (or at least, they try) this too. You’ll become a Fedora contributor! You’ll get a Fedora account and membership in the team, which will get you an email forward! When I did bounties, I sent handwritten thank you notes with some swag through the mail. You’ll gain skills in X, Y, or Z. You’ll make life better for our users. Some of this is obvious, but it helps to state it explicitly!
Ground Rules and Contact Info. How does someone claim the bounty? Do they need to get an account and assign it to themselves? What happens if they don’t do anything and time has passed, can it be opened up to others interested? (We had a 48-hour rule before we passed on to the next person when we did this on the Design Team.) Who is the contact person / mentor for the assignment? How can they contact that person?
Show Off the Work! – After a bounty is completed, show off the work! Make a post, on a blog or mailing list or wherever, to tell the story of how the person who took the bounty completed it and give a demo or show off their work. (This is a big part of the benefits too 🙂 ) This not only gives the new contributor a boost, it’s encouraging to other potential new contributors as they can see that new contributors are valued and can achieve cool things, and it’s also helpful in that it shows folks who haven’t set up bounties that maybe they should because it works!

I was thinking about setting this up as a pagure repo, and using the issues section for the actual bounty posting. The notion of status that applies to bugs / issues also applies to bounties, as well as assigning, etc. So maybe it would work well. Issues don’t explicitly manage the queue of bounty takers (should the 1st claimer fall through) but that could be managed through the comments. Any one from any Fedora team could post a bounty in this system. The git repo part of the pagure repo could be used for hosting some general bounty assets / resources – maybe a guide on how to write a good bounty with templates and cool graphics to include, maybe some basic instructions that would be useful for all bounty takers like how to create a new FAS account.

What about easy fix?

We do have a great resource, fedoraproject.org/easyfix, that is similar to this idea in that it uses issues/tickets in a manner geared towards new contributors. It provides a list of bugs that have been denoted as easy to fix by project owners all in one place.

The difference here though, is that these are raw bugs. They don’t have all the components of a bounty as explained above, and looking through some of the active and open ones, you could not get started right away without flagging down the right person and getting an explanation of how to proceed or going back and forth on the ticket. I think one of the things that makes bounties compelling is that you can read them and get started right away.

Bounties *do* take a long time to formulate and document. It is a very similar process to proposing a project for an internship program like Outreachy or Google Summer of Code. I bet, though, I could go around different teams in Fedora and find projects that would fit this scope quite well and start building out a list. Maybe as teams have direct success with a program like this, they’d continue to use it and it’d become self-sustaining. I don’t know, though. Clearly, I stopped doing the design team bounties after 4 or 5 because of the amount of work involved. 🙂 But maybe if it was a regular thing, we did one every month or something… not sure.

What do you think?

Does this idea make sense? Did I miss something (or totally miss the point)? Do you have a great idea to make it better? Let me know in the comments. 🙂

Uncategorized

Propose a talk for Flock!

by mairin on June 8, 2017 • 0 Comments

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.

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.

Questions?

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!

Save

Fedora, Flock, Interaction Design, Uncategorized

Flock Cod Registration Form Design

by mairin on April 25, 2017 • 2 Comments

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.

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

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?

Final screen – summary

This screen is just a summary of everything submitted as well as information about 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.

Cheers!

(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!)

Fedora, Flock, Logo Design

Flock Cod Logo Ideas

by mairin on April 18, 2017 • 0 Comments

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!

Inkscape, Logo Design

A logo for cri-o

by mairin on February 22, 2017 • 9 Comments

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:

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

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?

Fedora Hubs

Help Fedora Hubs by taking this survey

by mairin on February 21, 2017 • 0 Comments

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!

Fedora, Fedora Hubs

Helping new users get on IRC, Part 2

by mairin on February 8, 2017 • 2 Comments

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

$IRCNICK,

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

Uncategorized

Refugee Hope Box

by mairin on February 7, 2017 • 1 Comment

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.

Fedora, Fedora Hubs, Interaction Design Work

Helping new users get on IRC

by mairin on January 31, 2017 • 5 Comments

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?

“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

Finish

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

Thoughts?

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!

Fedora, Fedora Design Team

Fedora Design Interns Update

by mairin on December 8, 2016 • 0 Comments

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:

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! 🙂