FLOSS HCI Workshop at CHI 2010 Atlanta

Introduction

CHI is the ACM Human Factors in Computing Systems annual conference. Last year, CHI was in my ‘hometown’ of Boston, and I attended the one day that had a few sessions on FLOSS and HCI back then, including a panel session on Open Source UX organized by Scooter Morris and Bonnie John. I was really excited to see all of the interest in FLOSS, and very happy to see it carried on this year, since Michael Terry and Paula Bach organized a full-day FLOSS HCI Workshop at CHI 2010 in Atlanta, GA. I shared my submission with you earlier, and I’m hoping the submissions of other attendees are going to be available as well soon.

HCI Speed Dating

Anyhow, here is my run-down of the day. I arrived exactly an hour late (flight delay) and was dismayed to see that I completely missed the introductions. Michael and Paula had a cool idea for kicking things off after that though – speed dating! The workshop was split pretty 50/50 FLOSS practitioners/academics, so all the academics lined up on the left, and all the FLOSS practitioners lined up on the right, and we gave each other 30 second (well in some cases 2 minutes, ahem 😉 ) pitches of our work. It was really great to put a face to the names on the submissions I’d read, and I think it set the stage well for the rest of the day. I didn’t know many people there already -which can be an intimidating situation to be in – but by the end of the speed dating exercise, I felt I knew everybody a lot better, and was able to pick up a lot of folks’ names as well as remember whose research/work was whose. (One suggestion Ivanka made towards the end which I agree with though, is that we only had the academics speed date with the practitioners, when many of the practitioners had never met either. Next time, I guess!)

Brainstorm Time

After the speed dating exercise, we had an open brainstorming session on FLOSS and HCI loosely guided by some topics that Michael and Paula had seeded the FLOSS HCI wiki with and some folks had added to before today. This is my full set of notes from this brainstorming session (I tried to identify folks where I could but in some cases I didn’t know the person’s name yet):

• The greater CHI community should care about FLOSS HCI. They can benefit from FLOSS because they can use the code to work on a real software project, not a toy.
• FLOSS CHI is different than traditional (proprietary?) CHI. FLOSS’ development methodology is quite different.
• In design, there is still nothing analogous to open source development methodologies. Open source development methodologies have arguably revolutionized software development in general. Where are the open source design methodologies? They would be a whole new approach to design that could benefit all if we can figure them out.
• We shouldn’t take methods from general HCI practice and try to retrofit them to FLOSS HCI practice. We should find our own methods, suitable to our different needs – generative and emergent practices come from the FLOSS world.
• Carlos: Design in these communities is not at the forefront; it comes after developers work on the artifact. Design knowledge comes farther down in the process. We need to influence how open source communities are doing design. Projects are more interested in applying usability AFTER they designed something.
• Charline: A user’s relationship with computer is changing these days. In a way, the FOSS community is the next step of human computer interaction, a little likeCeleste was saying how it results in emerging practices for us. It’s also emerging practices for users. Users are getting more control or desiring more control over the technology. FOSS is at the forefront of that movement.
  • Paula: Pushing back a bit – how is that different from people who just drive their cars, who don’t change the oil…. why would users be more motivated to be engaged in their technology?
  • Charline: if i have to know how to change the oil, i won’t buy it
  • Adding to analogy – it’s not about how your car works, finding something frustrating in your car, report back and tell Toyota, I wish the way how you reported how much gas I’m using is done this way. We feel powerless – who is going to listen to our suggestions? FLOSS = user empowerment?
  • Mo: The car analogy doesn’t work because most software is a tricked out lawnmower, not a car. Then Apple comes along with a car, and everybody starts demanding cars…
  • Jinghua: A social trend is changing – If you have great training on how to do user research, you’re not the only one who can say what is wrong. With Firefox we’re doing crowd sourcing. 40% of the code is submitted by contributors. This will totally change the game – the authority of the designer/researcher is changing.
  • Andy: It’s a different kind of exchange between users and developers – vs. paying money – there is something that changes when the software is free. You’ll see this in Alex’s bug report comments – people take the same understanding of paying for something, and apply to the free software. They don’t think of it in a different way. You have to persuade people; you don’t just get a change for free. ‘I donated $100, why don’t you fix this bug?’ – that model doesn’t work in FLOSS.
• Alex: The free market is creating innovative ideas, and they’re being tested – users are collectively more talented than a small design team.
• Ivanka: Why is FLOSS HCI different? Anybody, anywhere, can and does kick off open source projects. There are different motivations – I want a job, I want to contribute, I want to get x done…. we can be very clear what we’re doing research about and why in traditional CHI context. in FLOSS, it’s a little different – it’s very hard to put practices together when nobody’s agreed on why you’re doing it – it’s decentralized.
  • Paula: It sounds like, there’s the open source community – people who know how to write software – an emergent project – with a complete lack of knowledge that you can design it better… worse case scenario. The industry has established processes…. I don’t know which is more successful, the open source community or industry.
  • Ivanka: Great innovation happens in the open source community – we get problems solved for us in Inkscape so we can do things in it we could not do with Adobe products… Why would Adobe listen to us? Our need is niche. The cost of solving niche problems is reduced in FLOSS.
  • Carlos: You get feedback whether you want it or not. The cost is extracting knowledge/information from that feedback. So we’re dealing with a new set of problems. A lot traditional organizations can learn, in terms of how to build these feedback loops – a lot of closed source systems feedback loop. Filtering is more important…
  • Adam: In a proprietary model, you can choose to appeal to larger audience, or be a specialized tool with expensive licensing. In open source, we try to have lots of capabilities – there’s less of an emphasis on larger broad appeal to common / less-computer savvy users. Design is not as valued as much.
  • Celeste: I wouldn’t necessarily say that’s on purpose, it’s more stemming from how open source evolved. They know they need to understand users, they just don’t know how. How do you take out functionality without pissing off advanced users? The lack of emphasis on design is not on purpose but a challenge we need to help them solve. This goes back into process – the community doesn’t know how to think about those things or when to think about those. Most open source projects are in maintenance phase, not new, maintenance. Giant/massive changes to application fundamentals are extremely difficult but are most common UX need.
  • James: In the history of chi as a community, methods are developed as the fields are growing. You don’t steal someone’s else’s customer, you try to get someone who wasn’t already a customer into the market. Walk up and use, not expert functionality.
  • Jono: They need to reach an understanding that you can improve something by throwing out, forward progress isn’t always new development.
  • Celeste: Landscape of open source projects, governance…. smaller projects might not want to do this. 1000 developers and you can’t, you don’t have a hierarchy, there’s no company behind kde / gnome / debian… have to get most of 1000 people to agree on a direction, herding cats.
  • Alex: You don’t need to get people to agree. Firefox / Mozilla was a coup, forked off. These projects get big, in traditional organizations it’s very hard to create something that will destroy the major projects already in place. In open source, you can have a new thing that will compete and people will transition over.
• Paula: What aspects of FLOSS HCI appeal to the design community in CHI? In CHI there’s design, engineering, management, and UX communities. How do we make contributions to these?
  • We’re a distributed engineering community, most analogous. distributed design and development…
  • Lawnmower/car analogy talks about product, not the process. Compare Toyota factory to an enthusiast building a car in his garage. We have constraints about cost and time and distributed working – we have to solve them in vastly different ways. We might come up with some method that’s cheaper out of need, because we don’t have money – and that method would benefit everyone.
  • Alex: Developers come in, often for educational value to learn more about how something was done. Designers don’t do this to learn about design. iI we open up the artifacts we create…. see the source files for all the artwork? We don’t really open up most of our design source files. We should.
    • Paula: In some communities there are gurus devels want to work with. Can we have design gurus people would want to work with? In Alex’s blog, he has a blog post about logo, designers showed up and commented.
    • Jono: There’s a lot more to having an open process than just making things available. In test pilot, our source code is open, but nobody but me has ever contributed. You don’t just need the code open, you need to find ways to invite discussion, to draw people in.
    • Ivanka: I have to hire people, I have graphic designers, user experience, user researchers, implementation and prototyping. Very hard to get CVs. When they get in the door, most people walk away from the interview really wanting to work on FOSS. Until she has CVs, it’s very hard to get them in. Suddenly start appealing to idea – you can contribute to something that has potential to contribute to millions of people, much bigger than a website. It’s an environment where you can contribute to something that has far more far-reaching appeal than just someone selling toys on a website. It’s the same draw for engineers – it’s free. NGOs and non profits can benefits… you can get credibility by working here.
    • Andy: recruiting – one challenge is that the talent is somewhat rare. Design talent is rare, only a few peopleare going to be good at it, find ways to find them, develop mechanisms to select them. Finding good bug reporters…
  • Ivanka: you can learn a lot of new ways to communicate by working in FLOSS.
    • People come to CHI to share, FLOSS is about that…. simplest thing – it’s about the same thing that attracted to CHI, share and learn.
      • Adam: Even if you’re working on a small project without a lot of exposure – anybody can go and take a look at your work, download the software, install it, play with it, look at your design documents – follow up on how you work, an open, portfolio, good look at how you work.
      • Paula: if you are a designer working in propretary industry, can’t show your friends your designs and talk about them – NDA issues.
      • Jinghua: With Firefox, we have a direct connection to users. If you work in a closed source community, you don’t get immediate feedback from users. In FLOSS, you have really direct dialog with users all the time – it’s worth doing.
      • Carlos: I was first attracted to open source and integrated into education – students can work on real communities on real projects, in terms of education – they’re not working on mickey mouse teams, three students with same background. They’re working in diverse, real communities with history and conflict. When you’re done with the class, you’ve made a contribution that will live on. Whether it’s for coding or design, it’s really important for the academic community to try to connect to FLOSS.
      • Jono: It’s apprenticeship vs. textbook. FLOSS is more like an apprenticeship.
• Paula: How about culture and tools?
  • Jono: Maybe this already exists but I’m not aware – who remembers the very first wiki, a programming pattern repository? Where’s that for user interface design patterns? If there’s an open source design pattern library – if it exists why isn’t it more well-known? Openness in discussing it, more knowing there are resources – could be good fr a project starting off….. interface guidelines from the beginning. Helping people understand they have a choice of interface guidelines that they can pick at the beginning of their project – the trade-offs. Help people know what it is they don’t know.
  • Adam: Patterns will help establish a common vocabulary – how do you google for a usability problem?
  • Jinghua: Previous research us hard to find. We’ve done research on manuals for Firefox. This knowledge can be used by other people but it’s very difficult to find it. Design patterns backed up by data… how many users, context…
  • Celeste: that would be great. Increase the design community by 100 fold but we don’t have enough people to do this. GNOME has great interface guidelines but have a really hard time maintaining it. Calum is the only person working on it, he got paid to work on it. KDE, we’ve been trying to do it, we have a few patterns, documentation is tedious, no fun…
  • Ivanka: I’m having a visceral reaction to making developers read a manual – I don’t make users do it, why make devels do it?
  • Celeste: Canonical does some documentation stuff for Ayatana, but it’s out-of-date, you seem to have a hard time maintaining it, even with paid workers.
  • Andy: Some tools that might be helpful: it’s hard to do remote critique. You can’t put jpegs side-by-side easily, hard to be all in a room looking at different ideas. Tools for doing remote critiques in a collaborative way is very hard.
  • Andy: Another challenge – back to guidelines / principles – some of the principles we have for UI design are operationalizable… for every input there should be an output. We can build tools around that. Some of the tools I’m working on find contexts where no feedback is provided.
  • Celeste – higher-level patterns are an issue. The number of items that makes sense in a dropdown – that can be automated. A list editor – to make it consistent, account for the 10 different ways apps use it – a sort of metawidget – putting together guidelines for that is a lot more difficult. Developers are forced to develop them on their own. How do you solve this common problem? – they are looking for more guidance than how many radio buttons should go in a window.
  • Carlos: documentation sucks, even in general. No one likes writing documentation, it’s never up-to-date. One of the advantages of FLOSS is quite often, 90%+ of the discussion is captured in some format – IRC, mailing lists, wiki, code… one of the really interesting tools we should be working on is ways of marking up these artifacts, try to identify and later extract that knowledge, especially design knowledge and information. Newcomers to open source projects, the primary thing they need to do before they can jump in is to understand how the whole thing is cobbled together.
  • Paula: This seems to be rehashing arguments from 10-15 years ago, about design rationale – too much overhead and people won’t do it. How to extract it – how to make it usable. write it into software libraries?
  • Carlos: Even if you do very simple tagging. You have a couple hundred posts a day. How many are those going to be about design? Filter from there… filter out the other stuff on the list.
  • uidesignpatterns.org
  • Ivanka – we’ve talked about the GNOME HIG, updating our documentation. Seth Nickell – felt like he stopped creativity with it. Retrospectively looking at the HIG, he said that he felt responsible for dropoff in creativity in GNOME because he created those rules. I did developer interviews… say they’re interested in playing around with image technology and the UI part isn’t interesting for them. Can we make making the UI easier, so it’s ‘i need a thing here, eg’ and they can play around with image technology they are interested in but avoid so much of a UI mess. We don’t do that much development in house. Communicating with internal developers who are paid to talk to us – communicating to them is not straightforward. Showing them a picture and expecting it to turn up coded the way it was designed. – trying to engineer that handover is a challenge.
  • Daniel: We have a huge deisgn pattern library… the developers are asking for the guidelines in it to be as baked in as possible. They don’t want to move things by 2 pixels to meet the guidelines. Just bake it in so they don’t need to think about it. Bake more of the standards into it. You can drag the widget in without having to worry about following the standards, already blessed. People would appreciate that.
  • Mo: Can we revisit the communication tools? When was the last time someone worked on Mailman’s UI? Mailman needs design. Filters like Carlos was saying.
  • Carlos: We need to rethink how the current toolset we use, how it supports design discussion. Mailing lists – like Mo was saying – you can’t post an image inline! It’s a messy way of doing things. No way to filter. Need to rethink how to do these discussions too.
  • Celeste – Those tools are not even just a designer problem. They’re a problem for developers too!

Affinity Diagramming

For every point someone brought up, they were tasked with writing their point on a post-it. At the end of the brainstorming session, folks tacked their post-its on the wall, and folks cycled up to the wall to do an affinity diagramming exercise, clustering the notes into five main categories (a photo of each topic’s post-its is behind the links below):

1. CHI Community
2. Design Patterns
3. Rethinking design in open source
4. Tools
5. Recruiting

Lunchtime

I think we broke out for lunch at this point. We went to a place called 30 Tables and it was pretty good. I had some conversation with James Fogarty, Adam Fourney, and Ben Lafreniere about software patents / IP, monetizing FLOSS projects, open formats, bitrot, HTML5 vs Flash. I also had a really interesting conversation with Victor Kuechler, who works on Beaversource, a hub for open source projects at Oregon State. He has a background in literary theory and he posed that the FLOSS HCI community could learn a lot from Kenneth Burke, particularly by applying dramatism rhetorical analysis to communications in the FLOSS community to better understand what’s really going on during FLOSS discussions. There’s so much text communication that necessarily happens in a FLOSS community because of the distributed and even time-shifted nature of FLOSS projects; it seems rhetorical analysis could generate a lot of interesting theories on why some communities work one way and others another.

Breakout Groups – Mini-conference Invention Sessions

After we got back from lunch, we broke into five groups, one for each of our topic clusters. We spent some time in our break out groups coming up with fictional FLOSS HCI-focused conferences centered around each of our breakout groups’ designated topics. My group was the ‘Tools’ group: Carlos Jensen, Jinghua Zhang, Parmit Chilana, and myself. We came up with a fictional conference name (‘Open Tools 2014’), multiple tracks for the conference (Developer / designer communication, Engaging Users, Design Tools), and 3 sample papers with short abstracts for each. (You may know the reasons why I was so keen to be a part of the tools group. 🙂 )

Then, each of the five groups got up pitched their conference to everyone:

Where to go next?

Finally we finished up with a discussion on where to go next. My rough notes on this are here:

• Is anyone missing here? Who should have been here? How about the developers. We should have an event where we do something like this with FLOSS developers. GUADEC, Akadamy, FOSDEM were mentioned.
• Cost of CHI Conference prohibitively expensive – is there another (cheaper) conference we could work with? Perhaps OSS IFIT conference.
• Continuing the conversation moving forward – should we set up a FLOSS HCI planet? Or work with openusability planet?
• Blog the event!
• Interactions article? Paper for next year’s CHI?
• Sprint events? Set up a template / process and run one?
• Open up our FLOSS HCI wiki – parts are not public yet.
• Photos will be posted – use them!

What do you think?

Where should we go next? As a FLOSS contributor, how would you like to join the conversation / see it carried on? Should we do some kind of joint conference? If the FLOSS HCI community members were to join up with the FLOSS community, what would be the most appropriate venue to do so? Were there any points brought up here in the synopsis that you violently agree or disagree with? Are there topics you think we missed? Do you have ideas on solutions to some of the challenges we brought up? What do you think?