Worldview, Diversity, and the iRAN Project

From Kellan Elliott-McCrea: Check out the iRAN Project, a Flickr collection of photos that show another side to life in Iran.    (LT5)

I’m a child of immigrants, and like all children of immigrants, I have a deep, almost biological understanding of what it’s like to live in a world with multiple worldviews. On the surface — well, perhaps just underneath the surface — I’m as American as apple pie, but my ethnic heritage has had a significant impact on who I am. Perhaps my greatest skill is my ability to reconcile different worldviews. I attribute this ability to my ethnicity, to my upbringing, and strangely enough, to growing up in this great country.    (LT6)

Mark Cuban recently said:    (LT7)

When you do something that the whole world thinks is difficult and you stand up and just be who you are and take on that difficulty factor, you’re an American hero no matter what. That’s what the American spirit’s all about, going against the grain and standing up for who you are, even if it’s not a popular position.    (LT8)

Cuban was talking about gay athletes in professional sports, but his statement resonates strongly with how I feel about this country’s values in general. America isn’t about tolerance. It’s about embracing those who are different from us, embracing them because we know that we will be all the richer for it.    (LT9)

Forget about politics for a moment, and just think about people. When we speak from ignorance, when we act on simplistic assumptions about people who are different from us, we destroy the very value that makes this country strong. I don’t even want to start a conversation about politics unless I know that those of us who are talking truly understand who we are talking about.    (LTA)

Two years ago, at the first Wikimania in Frankfurt, I spent every evening breaking bread, talking, and laughing with folks who grew up in different countries, from Europe to Asia, from Latin America to the Middle East. Having been properly primed, I spent the following week in Berlin, visiting friends and colleagues and absorbing my surroundings.    (LTB)

On my last day there, Jan Muehlig told me that c-base was celebrating its 10th anniversary that evening, and he invited me to come celebrate with them. c-base is the German center of the underground artist and hacker universe. In addition to incubating a number of extraordinary collaborative projects, they regularly throw parties and host live music in their space, which looks like the remnants of a wrecked UFO.    (LTC)

I showed up at 9pm, and I didn’t know anyone there. (Jan, like most people, didn’t show up until after midnight.) I wandered out back, where people were eating and drinking in the cold, wet air on a river bank overlooking the city. Despite my lack of familiarity with the surroundings, I felt strangely at ease. People welcomed me, this complete stranger from America who had wandered into their space.    (LTD)

I had a long conversation with a tall, skinny fellow who had grown up in East Berlin. He was a teacher and a new father, and he was about to marry his life-long sweetheart and the mother of his child. We talked about our day-to-day lives, the trials and tribulations of turning 30, and the state of the world.    (LTE)

At one point, I noted that twenty years ago, we were enemies. Now, we were sitting on a river bank in the former East Berlin, drinking beers, laughing at each other’s jokes, and sharing stories about our lives. Twenty years ago, I couldn’t even imagine ever being where I ended up that drizzly evening. Now, when I think about Germany, I can’t help but remember that night, the people I met, and the conversations I had.    (LTF)

Every time I travel, whether it’s to the Midwest or halfway across the world, I am always moved by the experience. You can’t fully replace the experience of travel, but you can evoke similar emotions and learnings in other ways. Projects like iRAN are beautiful, because they help us remember what it means to be human.    (LTG)

Extreme Usability Redux

Another great FLOSS Usability Sprint is in the books. As usual, great people make for great gatherings, and this event was no exception. But we did have a new goal for this event, and it resulted in some different outcomes, many of which were related to this new notion of Extreme Usability.    (JOS)

I have three overarching goals with all of these sprints:    (JOT)

  1. Improve the usability of the participating projects.    (JOU)
  2. Build greater Shared Understanding between the usability and Open Source communities.    (JOV)
  3. Catalyze community collaboration.    (JOW)

Additionally, as an organizer, you also want to “hit a home run,” as Jeff Shults likes to say. You want people to walk away feeling wonderful about themselves and about the group at large. As with baseball, you’re not going to hit a home run with every event, but you’re constantly hoping for it.    (JOX)

I think we hit a triple with our first sprint. We had great camaraderie and positive energy, everyone learned tons, and all of the participating projects made tangible progress. In fact, in the past few weeks, I learned that we made even greater progress with “catalyzing community collaboration” than even I had realized. Kieran Lal, Jan Muehlig, and Rashmi Sinha have all been developing tools for remote usability testing, a critical prerequisite for Open Source usability, where projects are usually distributed. (Our next sprint will most likely be a Remote Usability Sprint, tentatively scheduled for late Fall.) Mimi Yin‘s experiences at the first sprint helped form the seed for her most recent thinking for Chandler. Mimi’s informal discussions with Dave Greenberg at the first sprint influenced the most recent release of CiviCRM, and they worked together more closely this week. Most importantly, the many report-backs generated buzz in the community and helped bring in new talent, like Tony Chang and Jing Wu. There was also room to improve, though, and we incorporated some of that learning into this past sprint. All in all, people walked away feeling good.    (JOY)

This week’s sprint felt like a double. Once again, our projects made progress, people were buzzing and learning, and I think people had fun overall. Nevertheless, there was a cloud hanging over everybody’s head, one that made folks a bit more uncomfortable and the process as a whole more challenging. The cloud was the result of a special goal for this particular event — defining Extreme Usability.    (JOZ)

An Aside on Event Design    (JP0)

We did not define Extreme Usability prior to the event, largely because none of us knew exactly what it was. I had opinions, based on feedback from the first sprint and my own personal experiences, but I didn’t want to dictate the design of the event based on my own biases. One reason for this stemmed from my growing faith in the power of collective wisdom. Another reason was that I didn’t want people worrying too much about whether they were “doing it right.” My main concern was for the projects to get better.    (JP1)

Gathering a large group of folks with diverse backgrounds isn’t the most efficient way to develop a methodology. The vast majority of developers knew very little about usability, and only a handful had ever practiced Extreme Programming. We had 25 people attend, including users. In contrast, two people — Kent Beck and Ward Cunningham — co-conceived Extreme Programming, and they had many years of software development experience between them.    (JP2)

The other complication, which we downplayed, was that this was not simply an experiment in software development methodology. It was an experiment in Open Source software development methodology, which introduced its own constraints. Extreme Programming isn’t rampant in the Open Source community, primarily because its tenets are difficult to practice in this environment. Who is the customer? How do you pair program? What does a 40-hour work week mean, when you’re writing code on the side?    (JP3)

Given all of these factors, it seems unrealistic to have expected our participants to have contributed consciously to the creation of a new methodology. Why, then, did we try? Why this format?    (JP4)

My framing of Extreme Usability to the participants provides some insight as to why we chose this event format:    (JP5)

  • Agile Programming is an acknowledgement that software development is a collaborative process, and collaboration is hard. Agile methodologies offer a framework for alleviating these difficulties. Iteration and validation, for example, is a way to build Shared Understanding.    (JP6)
  • Methodologies like Extreme Programming lack an explicit role for usability practitioners. Extreme Programming provides rudimentary methods for developers to collaborate directly with customers, emphasizing “soft” forms of communication rather than requiring rigorous structure. User-Centered Design, on the other hand, incorporates into the process a usability specialist who has a range of methods for understanding user behavior.    (JP7)
  • The theory behind Extreme Usability is that usability practitioners should be co-collaborators with programmers for the entire lifecycle of the development process.    (JP8)
  • The biggest roadblocks for developers in this process would be to open up their minds, willingly and sincerely embracing the usability practitioners as codesigners, and accepting the possibility that their assumptions about the users and the design might be wrong.    (JP9)

The challenge is developing the framework in which usability practitioners and developers collaborate. This sprint was a laboratory in which we could experiment with this framework.    (JPA)

Rather than impose a more rigid process up-front, I wanted to test a general premise about collaboration: Eliminating barriers is generally more empowering than problematic. Pair Programming is a perfect example of this. A lot of programmers (and managers) react negatively to Pair Programming the first time they hear about it, because they assume that programmers need to be isolated to work effectively, and that they will be unable to collaborate effectively without this separate space. Experience has raised serious doubts about that assumption. We see a similar phenomenon with Wikis. Most people still assume that we have to impose structure and authority or our information spaces will devolve into chaos. Wikis obviously challenge this premise.    (JPB)

I wanted to watch how developers would work with usability practitioners with no preimposed constraints, hoping that our collective observations and experiences would result in a more useful framework than I could have come up with on my own.    (JPC)

The event was successful in this regard, but it came at a cost. We placed a heavy burden on our participants by making this goal collective and explicit. It’s hard, even debilitating, to be self-reflexive about process while you’re working. This was most evident on our second day. Frustration was palpable among our participants, as they struggled to both work on their projects and think about process. That everybody stayed positive and productive was a testament to everybody’s great attitudes, and for that I am grateful.    (JPD)

What Is Extreme Usability?    (JPE)

The conclusion among most of our participants, in the end, was that what most of us practiced was not Extreme Usability. I concur. Nevertheless, it offered some clues as to what Extreme Usability might be.    (JPF)

It may be a misnomer, for one. Rashmi Sinha suggested that what we were aiming for was actually “Collaborative Usability.” I would go further and say that it was “Extreme Design,” centering attention on the design rather than the overall development methodology.    (JPG)

Other thoughts:    (JPH)

  • “Customers” are not “users.” Once a customer becomes a codesigner, he or she loses value as a user, because he or she becomes subject to major bias from the design process itself. We attempted to include “users” as codesigners, which was wrong. You’re either one or the other (and it’s okay for a “customer” to be a codesigner), but you can’t be both.    (JPI)
  • Pairing is good. We required each project to bring two developers, and we assigned two usability specialists to each projects. However, we did not mandate pairing, and there were also other people working with each project. By the middle of the second day, each of the projects had figured this out on their own. If we do a second Extreme Usability sprint, pairing will play a central role in the process.    (JPJ)
  • Extreme Usability is not about taking shortcuts. Sprints are. The two should not be conflated. Many participants from our first sprint said that their biggest takeaway was that informal usability was valuable. You don’t need to have a high-overhead (i.e. expensive) usability process to develop usable software. I think this week’s sprint reinforced that. At the same time, I think it’s important not to conflate the sprint format with Extreme Usability.    (JPK)

Usability-Driven Projects    (JPL)

We intentionally chose early stage Open Source projects to participate in this sprint, but in doing so, we were still propagating what seems to be a given with all Open Source projects: they are started by developers. That naturally tips the power balance towards developers. I would love to do a sprint where the roles were reversed. Usability practitioners could bring project ideas — perhaps with wireframes or workflows — and developers would come to help with the design and implementation.    (JPM)

In a similar vein, Mimi Yin had a great idea. There should be an “inverted Sourceforge,” a place where usability practitioners — not developers — could start Open Source projects.    (JPN)