Fedora Design Team Planet

“The Designership”

Posted by Suzanne Hillman (Outreachy) on October 12, 2017 12:06 AM

“The Designership

Will check that out!

I’ve also been fond of UX Mastery, and the Junior UX Community slack.

I’m in the middle of a career change, and turned 40 a week ago.

Posted by Suzanne Hillman (Outreachy) on October 11, 2017 11:55 PM

I’m in the middle of a career change, and turned 40 a week ago. I’ve been working on UX projects in my own time, and trying to get paid work in UX has been quite difficult. I think part of the problem is that there are a huge number of new UXers in the area I’m in, which makes it harder to stick out as worth someone’s time.

Finding a mentor is _hard_!

Posted by Suzanne Hillman (Outreachy) on October 11, 2017 11:50 PM

Finding a mentor is _hard_!

Then again, I’m not entirely clear on what a mentor is supposed to offer a mentee. I’m currently working on a simple project with someone currently in school for technical communications, which feels like mentoring even though I’ve not yet managed to get a paid UX position yet (I’m a career changer).

Just a strange position to be in!

Running Sapphire Radeon RX 560 on Fedora 27 beta (follow up)

Posted by Luya Tshimbalanga on October 09, 2017 05:45 AM
Following the previous blog and some investigation, it turned out the kernel package from Mystro256 COPR repository based on agd5f kernel branch (one of AMD developers) resolves the blank screen issue. That could trigger a problem for users having a new AMD graphic hardware so perhaps a warning should be written on the release. Perhaps having one of contributors be part of kernel team bringing these improvement until those patches arrive to the mainline kernel for a better user experience.

Past the issue, the desktop experience with Radeon RX 560 was tremendously improved compared to the retired GTX 460 v2. Gnome on Wayland on Fedora runs smooth showing how far the open source amdgpu driver went through compared to previous years. That was also the opportunity to run a vulkan based smoke test demo on RADV, which is a counterpart of glxgears.

Overall the card is excellent once missing software are installed.

Running Sapphire Pulse Radeon RX 560 4GB on Fedora 27 Beta

Posted by Luya Tshimbalanga on October 08, 2017 07:08 PM
I bought a Sapphire Pulse Radeon RX 560 4GB to replace the broken Nvidia GTX 460 v2 after a long years of service. It is then my first ever dedicated AMD based video-card for a desktop.

The boot sequence on Fedora 27 hit a problem: a plain blank screen suggesting the card is not yet supported. Looking at Phoronix website revealed one of possible requirement missed: LLVM 5.0 which is currently not available to Fedora repository save a failed built. I filed a bug report to address the issue. Hopefully that will land on time for the official release of Fedora 27.

Considering AMD desktop card

Posted by Luya Tshimbalanga on October 03, 2017 08:53 PM
My Nvidia GTX 460 v2 card just died after six years of service after attempting to restore it. It was the last known Nvidia card that could work out of box with open source driver.
I have used Nvidia for a long time but the behaviours from the company prompt me to no longer consider that option. Currently the GPU market is very expensive to afford a good AMD card.
Additionally, the nine years old motherboard needs a replacement as the venerable AMD Phenom II 940X shows its age. The onboard Geforce 8300 is troublesome to run.

For now, I use a laptop until I can afford a powerful custom built desktop this time will full AMD hardware.

Inkscape Workshop for the Young Eco Ambassadors

Posted by Sirko Kemter on September 28, 2017 04:37 PM

 

After a long time it is time for another Inkscape Workshop here in Phnom Penh. This time the audience are young “ecopreneurs”. The environmental situation in Cambodia isnt the best, especially the situation with the trash. It is really a problem, if you drive trough the city, you seeing that Khmer always have a coffee or sugar can juice on their motobike hanging, that is a ot of plastic which ends up directly on the street. The effect of that is it flowing around when the rain comes, the channels are full of them it stinks and it always ends in the chain if you drive with the bicycle during the rain. So not nice!
This young people, want to change that. They do events educating people, what they can do better and founding businesses with an higher ecological impact and sometimes they just going on the street and collect the trash by them self. So a good thing to do.
This workshop shall help them to reach more people. We will do it for two days, the first day will be an introduction to Inkscape, with an practical part where we draw an trash bin. The second day will an introduction to poster design, where we work out the principles for it and design with Inkscape a few posters.

Merken

Enabling New Contributors

Posted by Máirín Duffy on September 27, 2017 08:57 PM

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:

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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!
  6. 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?
  7. 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. 🙂

Further on the UX hiring process

Posted by Suzanne Hillman (Outreachy) on September 22, 2017 09:55 PM

Hi again!

The previous post on this topic offered an overall summary of what I’ve been learning in my conversations with folks. Now I’d like to go into a little more detail on some of the topics.

So what should I learn?

Identifying the best areas to focus is probably one of the hardest tasks, especially for those folks who are not able to afford to get a degree or do a bootcamp like General Assembly. The guidance offered through official programs is not to be underestimated!

What do you already know?

You almost certainly have experience in _something_ that falls into UX design. Whether it’s researching how to do something, drawing things in your spare time, talking to someone new, explaining a skill or idea to someone else, or trying to use a new piece of software: these are all applicable to UX in some way or another.

The way I like to think about UX research and interactive design breaks down like this (see my quick and dirty handout from a recent talk I did):

<figure></figure>

Everything informs everything else, from the information you gather at the beginning, to the analysis with other folks, to the early sketchy design possibilities you create, through to iterating on your design based on feedback you get from stakeholders and users.

When these designs need to be produced in higher and higher fidelity as your team gets closer to something that works well for the stakeholders, there will likely be continued iterations based on what’s actually feasible and plausible. (I am not as experienced in the visual design aspect of the UX process, so I cannot offer as much structure around that part.)

What do you like to do, what do you need to learn?

Figure out what you know how to do or could easily learn. With that information, you can focus on what you know how to do and how to integrate it into a project, and then on improving any areas you specifically want to learn.

I personally need more practice in visual design and data visualization: I’m not especially familiar with visual design or otherwise making things visually approachable, and these both seem useful to at least have a basis in.

I’m working on identifying the best ways for me to improve these skills, and found that working on badges with Fedora folks helped a bit. Among other things, it meant that I had the opportunity to ask what people did when they did specific things that I might otherwise not have encountered (such as specific keystrokes in design programs).

For other folks, it might be wise to learn the basics of HTML and CSS. Even if you do not wish to write the code for your designs, it is immensely helpful to understand how programming works.

Depending on one’s level of familiarity with these, something like https://www.codecademy.com/ might be your best bet. These are free courses that let you see what you are doing as you go along. You might also appreciate https://codepen.io, which will update with your changes as you go along, and which supports HTML, CSS, and Javascript.

If you’re not familiar with how to phrase things, maybe you want to work on writing content for your designs. Maybe pretend that you are talking to someone who has never run into the thing you are talking about, or to someone who is too busy to give you more than a 30 seconds to a minute to read whatever you have to say. Figure out the most concise, but clear, way to say whatever you need to say. Even if you don’t want to write the content for your designs, it’s really important to be able to express yourself simply and clearly. Words are important, along with visuals and structure.

If you are looking to get into research, it would behoove you to learn some about quantitative research, not just qualitative. One of the major points that folks looking for quantitative researchers want is the ability to tell if the company is measuring success effectively.

Possible places to get cheap but decent classes include Lynda and Coursera. I’ve done some Coursera courses, specifically “Human-Centered Design: An Introduction”, ”Design Principles: An Introduction”, and “Information Design”.

Whatever it is that you need to learn more about, there is probably a way to do it online (remember to check Youtube!). However, it is often the things one needs the most help in that are the hardest to figure out how to learn on one’s own. Knowing the terminology is important for any successful google search!

(Note: I suspect that offering classes in basic aspects of each piece of the UX process would be a good value for the UXPA boston group, given the content of the previous paragraph. Not everyone learns from videos/written instruction very well)

Do a project. Any project

In my experience, the best way to learn is to find a specific design project — really any design project is fine to start out — and start working on it. If you have friends who write programs, see if they want your help. If you have friends with lots and lots of ideas, ask them to let you help design one of them. If neither of these are the case, consider an area in which you wish that something existed, or in which you wish a piece of software were easier to use. At this point, it matters less if your project goes live — although that’s always preferred if possible — and more that you are working on something.

Take lots of screenshots and notes and keep track of what you’ve tried, what worked, and what didn’t work. These will be useful when it comes time to create your portfolio!

Remember: the point of your first project is to learn, rather than to succeed, and most people learn the best from failure. Failing at something isn’t actually bad. Indeed, it’s almost expected, since you’re new at it. Figuring out where things went wrong is the important part.

That said, it can be difficult to know what to do at any stage of a project, especially if you’ve never tackled one before. This is where having someone you can check in with is invaluable. Not only is UX design not really a solitary activity, but having someone to help nudge you on the right path when you get stuck is fantastic.

If you have a mentor, that’s great. If not, see if you can find other folks who are also job hunting to work with. Chances are good that you are each better at different pieces of the project, and this will provide you both with additional experience.

For a possible mentors, join http://designmentors.org/ (credit to David Simpson for this!) and get in touch with someone who looks useful for your needs.

If you’re still struggling to figure out a design idea, this page might be helpful.

If you’re not sure how to approach a project, this site talks about the whiteboard design challenge that sometimes happens in interviews, and is a decent overview of what a design project could involve.

(Note: Offering folks ways to get in touch with others who are looking for their design projects to work on might be a useful feature. Similarly, ways to find mentors.)

Which tools?

In general, you will need to use a tool of some sort for your design project. Paper prototypes are amazing, no doubt about it. Unfortunately, they are difficult to test out remotely, and rely on excellent drawing skills and handwriting to be easily used for prototypes.

There are a large number of options for tools in the UX design space.

Mockups/Prototyping

Some are focused on being easy to use to make low and medium-fidelity mockups and prototypes (Balsamiq was my first tool, for example. Axure is easy to start out, but a bit complicated to learn to turn into a prototype). Some are specifically meant to help folks turn their designs into prototypes (like Invision, which is free and supports uploading existing designs) and often support collaboration quite easily. Others are more on the visual design side of things, although sometimes still include fairly easy ways to make mockups and prototypes (Sketch is extremely popular, but mac-only).

Adobe’s creative cloud service includes a lot of commonly used graphic design tools, whether photoshop (for which Gimp is a decent free and open source substitute, if poorly named), illustrator (vector graphics; try Inkscape for a free and open source substitute), indesign (as far as I can tell it’s about design for publishing online and off? Not sure of the best free equivalent) or the recently added experience design (XD beta, again not sure of an equivalent, although I think it may be meant to compete with Sketch).

The ones I’ve listed above are the most frequently mentioned in job applications, especially Sketch and Adobe creative cloud. Axure and Invision are also quite common. There are a _lot_ of other newer (and often free/beta) options, although I’ve not done much exploring of those.

(note: classes/mentors for basic introductions to the most common design tools might be useful, especially for those who are not already familiar with Adobe Creative Cloud. Not everyone learns from videos/written instruction well)

Other tools and techniques

You may also want to investigate tools for mind mapping (I like MindMeister, free for a small number of maps), which can be useful to keep track of relevant ideas and concepts. Or for remote affinity mapping (I like Realtimeboard, free for a small number of boards) and other sticky-note/whiteboard-based activities.

There are a lot of other techniques that could be good to learn, including task flows and journey maps.

Many companies want folks with experience in the agile framework, so learning what that is and the various ways that design folk have figured out how to integrate into it would be useful.

If you are not already familiar with style guides and pattern libraries, getting a basic understanding of those would be useful.

Ok, I’ve done my first design. Now what?

First, congratulations! That’s often the hardest part.

Review your work

Take a look at what you did with an eye toward improving. What do you want to learn more about? What do you need help with? Where do you feel you excelled?

Read

Take a look at various blogs in UX, as now that you’ve done your first project, you will likely start finding that those start making more sense to you. I found that reading various blogs and watching videos was overwhelming before I’d done a project, because I had no idea what was relevant.

Twitter has a lot of fantastic UX folks, although who you want to follow may be partly location-based. I like Jared Spool, Joe Natoli, Luke Wroblewski, Mule Design Studio, Dana Chisnell, Sarah Mei, and What Users Do.

http://52weeksofux.com/ is an excellent overview site that I really need to revisit myself, now that I’ve got some experience in UX.

I’m also fond of UX Mastery, and the Nielsen Norman Group.

There’s also a lot of good books out there!

(note: a curated list of useful links and books would be really helpful!)

Portfolio

Your best bet would be to summarize what you did, whether as part of your portfolio or as preparation for your portfolio. Keep your eye out for things you would have done differently next time, as well as things you think worked out well. You want to describe your process, and at the same time tell a story about what you did and why. Remember to be clear on what you did and what your teammates did: as I’ve mentioned above, UX is typically a team process.

If you want to write the HTML and CSS yourself, that’s fine. However, beware of the problem of running down rat holes to make things look perfect, and never actually creating a portfolio that you can share. That’s a major reason I’m moving away from a static website to Wix.com — it’s so much easier to do good design if I’m not also trying to write the code.

Tell a story?

I’ve had lots and lots of people say to tell a story, so I’ll share something about that. I had no idea what that actually _meant_ until I had a chance to a) dig deeper into what specifically folks were thinking about and b) see examples of this. One of my major problems is that writing a portfolio for a UX researcher is _hard_. You tend to have fewer pretty things to show folks than the typical graphic design portfolio might, and you may or may not have the design skills to make your portfolio pretty.

To the best of my understanding, your story needs to include as much guidance for your reader as possible. Like everything else, use your nacient UX skills on your portfolio: guide your reader through it.

Guide your reader

Use Gestalt principles to help your reader know where to go next, and I recommend an overview (this links to my in-progress update for my website) of your major goals and results to act as guideposts.

From this page: Include as much as possible of the STAR method in your portfolio to communicate what the situation is (goal of the project), what tasks and actions you accomplished (your UX toolkit of wireframing, usability testing, sitemaps…) and what the end results were (analytics, final designs, customer testimonials).

Note that I’m still struggling with the best way to explain the end results in some of my projects, because they either were one shot things (through hackathons) or are on pause while underlying things are completed.

I’ve got a portfolio, now what?

Get someone to look at it! Just as in everything else, you want someone else to take a look because there will be something you’ve missed, or ways in which you are not as clear as you’d like.

If that’s not an option, take a week or two, and then take another look at it. You’ll probably find typos and brainos (places where what you wrote doesn’t actually make sense), even though you are the one who originally wrote it.

(note: I expect that offering folks portfolio feedback would be really helpful! I’ve personally gotten in touch with someone from designmentors.org and have a review pending)

Do more design work!

Find more projects to work on. Now that you have your first one under your belt, this will go more smoothly, and you likely will find it easier to identify areas to work on.

If you happen to be able to find an internship in UX (say, Outreachy), take it! Guidance is amazing.

Start looking for jobs

This will help you get an idea of what the market looks like right now. It may help you decide what tools or skills to learn, or identify things you specifically _don’t_ want to do. And hey, you might find a job that looks good!

Network!

Honestly, I should have already said this, but this is easier when you have a little experience. At least in my case, having some basic knowledge makes it easier to talk to folks about UX.

Better yet is if you have a specific goal in talking to folks. For example, since I’ve been collecting data about the hiring process in Boston, I’ve had no trouble contacting folks about interviewing them. You may be able to take the tactic of asking folks about what they do in UX, potentially allowing for the opportunity to learn more about UX at their company.

Business (MBA) folk do something called an informational interview. In some cases, this appears to mean talking to folks about UX at their company. In others, it might involve the possibility of going to someone’s company and actually seeing how it works. As far as I can tell, your best bet is to see if you know anyone working at a company that includes UX folks and see if you can get any of them to introduce you. You can also message people on LinkedIn without a connection, but that may not work as well.

Present on your project

If you have the opportunity to present on a project you’ve done, take it. Presenting skills are very important in UX, and practice does help. Talking in front of a group of people can be scary, especially if you’re also trying to get them to hire you. Practice in a safer space, first, if you can.

Be visible online

If you don’t already exist online, you really should. Start a blog (I’m quite fond of Medium) about your UX experiences/learning/thoughts. Be active on twitter. Be visible in your UXness.

What next?

I’ll be chatting with more folks over the coming weeks, and will be speaking to the UXPA Boston board the first week of October. Watch this space!

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.

Problems?

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:

<figure></figure><figure></figure><figure></figure><figure></figure><figure></figure>

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.

Why?

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.

<figure></figure>

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

Viewing

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.

Creation/editing

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.

Puzzles

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.

Notes

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

Bootstrap-based.

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.

Who?

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.

Users

Personas

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

Website

<figure></figure>

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.

Projects

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:

<figure></figure>

After opening the menu:

<figure></figure>

Under ‘More options’:

<figure></figure>

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.

Querki

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.

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

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.

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

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.

Responsive?

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.

Meanwhile…

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.

Enthusiasm?

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!

Presentations?

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.

Summary

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

Analysis

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

Design

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

Summarizing

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.

Brainstorming

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>

Search

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.

‘You’

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.

Conclusion

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.


Valentine's

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

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

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

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!

https://docs.google.com/forms/d/e/1FAIpQLSdwqrBZAl7FGowexrkCWR-H-XeP5a6zeVpjRDEc9PsBuQpU6g/viewform

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>
<div class=”col-xs-6">
<p class=”viewall”><span class=”callout”><a href=#”>View All Team Badges></a></span>
</div>
</div>

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.

Background

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

<figure></figure>

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.

Preparation

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.

<figure></figure>

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?

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

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

<figure></figure>

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

<figure></figure>

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.
<figure><figcaption>Missions!</figcaption></figure>