Sometimes it’s good to stop worrying about the world and just work on my projects

As I’m sure many of you know, living in the US is worrying right now. It’s been a bit difficult to focus on work as a result!

However, organizing my thoughts to describe what I’m currently working on and have been working on since my last post is always a good idea. Let’s get to it!

What Have I Been Doing?

A lot, as it turns out. It can be a little difficult keeping track of it all, which is clearly why I should be blogging more. Asana (a task list) to the rescue!

Lots of mockups

The first thing I did was actually part of what I did two posts ago: lots and lots of mockups. I’d had some experience creating mockups, which made this quicker than it might otherwise have been. I’d also attended the Inkscape Workshop last summer, which gave me some useful keystrokes and tips that made it quicker to use. Still, though, mockups are not fast. But, faster using Balsamiq than if I tried to do mockups using inkscape.

The affinity mapping and brainstorming post contained a bunch of initial mockups which I basically threw together to try to cover the things we came up with during brainstorming. Máirín Duffy (Mo) reviewed and commented on each of those, both in the ticket and sometimes in IRC, email, and other such places.

Each of the tickets in question has more detailed information: master list of Fedora people, master list of events, notifications, joining regional hubs.

Location information turned into an unexpectedly complicated problem as per my previous post, and spawned a new ticket to figure out how Hubs would suggest new regional hubs.

I also created a number of tickets that I do not expect to be able to get to during this internship, but which were clearly necessary to keep in mind around this project: public-facing pages, event creation (for which I am trying to brainstorm some general thoughts on fields from my interview notes), bringing people back to hubs, master list of regional hubs.

Restructure of schedule

Around halfway through the internship, I began to wonder if we’d be able to get through the entire set of tasks we had put into the preliminary schedule. As a result, I asked Mo if we could talk about the schedule and how feasible it actually was. I was feeling a little behind, and was having trouble determining if in fact we had been too optimistic, or if I was simply not getting enough done.

As a result of this discussion, we identified tasks that we definitely wanted to get done by the end of the internship. We also listed some that I’d like to at least touch on. We retained the major goals of: prototype usability testing, feasibility discussion with the lead developer, analysis of the usability testing and feasibility discussion, and an overall summary of what was found through these. In addition, we decided to do some work to give me experience with visual design and CSS.

Mockup Feasibility

I scheduled time to talk with the lead developer over IRC, having sent him links to the tickets with mockup that I wanted to discuss. As is apparently the norm for me, I was very nervous about this discussion. I blame impostor syndrome, as everyone in Fedora Hubs has been very welcoming and approachable.

For the most part, his response to the mockups was that they were feasible. There were a couple of instances where more research was needed.

In one case, he wanted to do make sure that he could show who was online in a lightweight and reasonable fast way, given that one could change the search or the map dynamically.

In another, he needed to figure out how to dynamically do searches/filters that listed only people (or events) within x miles/km of a person or location.

As with the locations information discussion with Mo, talking about the locations mockup with our lead developer turned out to be a bigger thing than I was expecting. Indeed, I created a new ticket (as mentioned in the mockups section) to remind us that we needed to figure out how Hubs would handle suggesting new regional hubs. That conversation still needs to happen, and I’m not completely sure that it will before my internship is done. However, without that ability, regional hubs will become much less useful.

My takeaway so far is that location stuff is really hard. Which, had I thought about it, would have made a lot of sense! I just somehow… didn’t consider it in great detail. This would be why UX isn’t done in a vacuum!

Social Media and Photo sharing

We are hoping to identify which social media and photo sharing platforms Fedora members use to discuss Fedora and Fedora events. This information would allow the prioritization of plugins to pull info from and maybe push info to various types of social media and photo sharing platforms.

If we can do this, it would make it a lot easier to keep information about an event in one place, whether because attendees want to share with each other, or because organizers need to create event reports. As below, having the option to have the media in one place would be really useful.

I am nearly finished with a survey about social media and photo sharing platforms that I intend to post to this blog and ask people within Fedora to share widely. The more information we have, the more easily we can identify the key platforms to incorporate. My initial interviews suggest that location will affect which platforms are in use, especially given countries in which the norm is phone use, not computer use. As such, having that survey spread around will help a great deal.

Prototyping

A very important part of the UX process is user feedback. Once I had a reasonable number of mockups that Mo had taken a look at and provided some initial feedback on, I needed to get those in front of some users.

I originally tried to get in touch with my first interviewees, but they were largely unresponsive. Instead, after discussing with Mo, we identified people who might be good candidates, and I got in touch with them. Three of the four I contacted have gotten back to me, and I did the first usability study last night. Went well, but given my lack of experience in doing usability testing, I was nervous. I need to go through the video and take notes, as I found it impossible to pay attention to my participant and take notes during the usability session.

I found it challenging to identify tasks for my mockups, so I listed out a general idea of what was possible for each. This was based on my experience in quality engineering, and I found myself too easily getting into irrelevant details. Annoying, but still a good way to start.

From that list, I created a basic list of possible tasks, and sent those to Mo for feedback. Unsurprisingly, most of my tasks were not concrete enough and were likely to confuse people. She made suggestions for the kinds of things she would have done. For example, instead of:

Task: You are new to the area, and hoping to find an event nearby to go to. Please use this prototype and explain to me what you will be doing while trying to find this event.

She suggested:

Task: You’ve just moved to the Los Angeles, California area. You’re hoping to find a Fedora event nearby to go to, to find new local Fedora friends. Please use this prototype…. (same text as orig)

These kinds of concrete examples made it much easier to finish creating tasks.

I found myself stuck identifying which tasks were higher priority than others. With a bit of prompting from Mo, I used the same box diagram thing that we’d used after our affinity mapping. I listed numbers of people affected on one axis, and how often people would run into the interface on another. This helped me organize the mockups themselves, and then the tasks, and made it much easier to see which were more important to get eyes on. I discussed my thoughts on this briefly with Mo again, who provided useful feedback.

Prioritizing!

While planning the task list, I was also considering how to do the prototyping remotely. Originally, to avoid bandwidth problems, we were considering trying to send prototypes to people and have them walk through it and talk to me through IRC. The more I thought about this, the more concerned I got. First, having to change between a prototype and IRC to communicate seemed very disruptive. Second, not being able to see what they were doing with the prototype seemed like a huge problem.

After additional discussion with Mo, she pointed out the existence of MyBalsamiq. I hadn’t really thought about the fact that there must be a web-based interface, and that it might support web-based prototyping. After some investigation, Mo got a free web license for Fedora, and I moved my relevant prototypes to that platform. Between MyBalsamiq’s prototyping methods and google hangouts, remote prototyping became much more plausible.

I will also get some in-person prototyping experience with people who are at Mo’s office, although I am still working on scheduling those people.

Visual Design

I do not have a lot of experience with visual design, and sometimes find it baffling. I suspect that having the Designing Interfaces by Tidwell book that Mo suggested will help with this, as well as with mockups.

To get me a feel for how it might work, Mo has converted one of my Balsamiq mockups to the existing visual design. I have not yet had a chance to take a look at this, but am hopeful it will help give me a better sense of how that might work. I will then try my hand at doing the same thing with a different mockup.

My initial forays into CSS will be in another post, simply because this post is long enough.

Previous, locations are hard.

Next, CSS (part one).