Jeff Shults – Eugene Eric Kim

Productivity, Working Big, and Spatial Awareness

Published November 23, 2007 by Eugene Eric Kim

My colleague, Jeff Shults, has a saying: “Work big.” Jeff is a space guru, as many of you who have participated in a Blue Oxen Associates workshop know, as most of my events have been at his different spaces. The most glaring feature of his space are the huge, movable work walls. (MQE)

Working big is important even when we’re working small — at our desks in front of our computers, for example. I’ve cited speculation and a study on the productivity gains from using larger screens. I recently ran across Clive Thompson‘s New York Times magazine article that cited a similar study by Mary Czerwinski at Microsoft. (MQF)

On the bigger screen, people completed the tasks at least 10 percent more quickly – and some as much as 44 percent more quickly. They were also more likely to remember the seven-digit number, which showed that the multitasking was clearly less taxing on their brains. Some of the volunteers were so enthralled with the huge screen that they begged to take it home. In two decades of research, Czerwinski had never seen a single tweak to a computer system so significantly improve a user’s productivity. (MQG)

Thompson makes a key point in his article: Productivity in an interrupt-driven world seems to be closely related to our ability to switch and remember different contexts. Bigger screens allow you to take advantage of spatial awareness to switch and remember different contexts. (MQH)

There’s a corollary to this regarding complex problems. I’m convinced that the primary value of graphical facilitation is not the Visual Language used to capture ideas, but the relationship created between ideas and space. In other words, you’ll remember the discussion around an idea better if you remember that it was the conversation that was captured on the lower right hand side of the screen or wall. This belief has greatly eased my stress when Dialogue Mapping, as ultimately, I see my task as building spatial memory. (MQI)

That’s not to say that Visual Language isn’t important. It is, and fortunately, there’s a fantastic community of folks who are exploring it. The better news is that many of these folks will be converging in San Francisco on January 27-29, 2008 for the VizThink conference. (MQJ)

Don Nielson on Societal Innovation

Published November 7, 2006 by Eugene Eric Kim

The HyperScope crew attended SRI’s 60th Anniversary celebration at the Computer History Museum last night. The main event was a panel discussion moderated by Paul Saffo. Participating were SRI luminaries Doug Engelbart, Phil Green, Don Nielson, and Paul Cook. (LHD)

Saffo closed the discussion with the question, “If you had a large sum of money to change the world, what would you do with it?” Don Nielson had a wonderful response. He said that he firmly believed that it was impossible to do top-down social innovation. Societal change occurs when good people do lots of interesting things, and some of those things just happen to meet certain societal needs. (LHE)

Jeff Shults and I made this same question the central exercise of our “Tools for Catalyzing Collaboration” workshop last April. Curiously enough, all four teams came up with proposals that were about catalyzing bottoms-up innovation. Several of our participants came from foundations. (LHF)

It’s good to see this philosophy starting to spread, but it’s much easier said than done. By definition, creating an emergent space implies uncertain outcomes. People have a very hard time grappling with that uncertainty. (LHG)

Tomorrow, I fly to Baltimore, then Raleigh for two projects that are very much about emergence. One of them is Imergence (formerly 1Society), which I still haven’t talked much about yet. Trust me, I’m not hiding anything, I’ve just been really busy, but I hope to write more about it soon. It’s been a very satisfying experience so far, not just because of the great people involved, but because of the opportunity to shape the proposal with ideas that I’ve been formulating and refining since founding Blue Oxen Associates almost four years ago. (LHH)

Something Special in St. Louis

Published October 20, 2006 by Eugene Eric Kim

There’s something special brewing in St. Louis, and it ain’t Budweiser. My side of the story begins in the Bay Area. We’ve got this special culture here in California. It’s a culture of openness, of collaboration, of entrepreneurship, and of tolerance. Combine that with a wonderfully diverse and intellectual community, and you get a tremendous amount of good vibes and innovation. The Bay Area is so wonderful, most of us don’t see any need to go anywhere else, and those who do often experience severe culture shock. Yes, Virginia, not everyone is like us Californians. (LBJ)

In some ways, that’s a good thing, but in many ways, it’s sad. True, California is beautiful. True, the people here are brilliant and wonderful. But, there are brilliant and wonderful people who live outside of California, and there’s no reason why those folks can’t enjoy the same community vibe that we do out here. The Internet allows us to transcend geographical boundaries and form a virtual community with a similar vibe, but it still pales in comparison to the experience of being physical immersed in this type of environment. The barrier to this sort of vibe emerging in a geographical community is usually culture. (LBK)

Is it possible to shift the culture of a community (or an organization) to be more collaborative, more tolerant, more innovative? Absolutely. It’s not easy, but it’s possible, and like all great things, it starts with great people, and it has to start small. (LBL)

St. Louis has these ingredients as well as a growing consciousness about what is possible. The right people are there, and they are starting to discover each other. If this growing community fosters these opportunities, a wonderful prairie will emerge. (LBM)

This past Wednesday, I did my part by co-facilitating the first gathering of the St. Louis Collaboratory, which was formed by Kellee Sikes and three of her colleagues (Mark Richman, Donna Mickens, and Valerie Hartman). (Pictures from the event.) The gathering was modeled after the “Tools for Catalyzing Collaboration” (TCC) workshops I co-organized with Jeff Shults earlier this year in San Francisco. Kellee attended our second workshop, and enjoyed it so much, she decided to try and bring a similar experience to her community in St. Louis. (LBN)

(LBO)

Kellee, Mark, Donna, and Valerie recruited a fantastic and diverse group of participants. We had folks from both non- and for-profits, from large and small companies, from technology, health care, and organized labor. These people were thoughtful and open-minded. They came into the workshop with a healthy dose of skepticism, but also a willingness to play. What surprised me the most was that several of them had thought as deeply about collaboration as anyone else I’ve ever met. (LBP)

I learned a tremendous amount listening to this group and watching them work. I could write 50 blog entries about the things I learned, stories I heard, and insights I gained. (I’ll be happy if I manage three.) (LBQ)

At dinner later in the evening, I told several people that it would be a travesty if they did not continue engage with each other. You can do amazing things in a day. My goals were to expand their consciousness, to make them aware of each other, to start seeding Shared Language, and to give them an opportunity to experience a different kind of collaboration. We met these goals, but they barely scratch the surface of what’s possible. (LBR)

The opportunity is there. Kellee and company are planning another workshop in January, and hopefully some of the participants from this week will play a more active role in designing the next event. Moreover, there are complementary events cropping up in St. Louis. (LBS)

Through a serendipitous conversation with Jay Cross last month, I discovered Dave Gray, the founder of St. Louis-based XPLANE, which does visual modeling and facilitation. Dave introduced me to Matt Homann, a lawyer by trade who recently formed a company, LexThink, to organize more collaborative gatherings. Matt has been experimenting with a different kind of networking event in St. Louis known as Idea Markets, and the second one just happened to be this past Tuesday. It was an excellent event, and I’d encourage people from the area to go. This style of event is a dime a dozen in the Bay Area, but we rarely see the mix of people that Matt managed to draw. (LBT)

(LBU)

What’s different about St. Louis Collaboratory and events like Idea Markets is that they’re not about Drive-By Networking. They’re not about, “What can you do for me?” They’re about, “What can we do with each other?” That, my friends, is what collaboration is about. I’ll be watching these developments closely to see what emerges. (LBV)

Wright on Professions

Published June 11, 2006 by Eugene Eric Kim

I often talk about the craft of collaboration, and how we need to treat collaboration as a discipline. There needs to be enough cognitive structure there so that we can get better at collaborating on collaboration. You have to be careful, though, because over-formalization creates its own set of problems, and the line between that and just-enough structure is a thin one. (KOO)

After Jeff Shults and I wrapped our April Tools for Catalyzing Collaboration workshop, Matt Taylor approached me and showed me a letter Frank Lloyd Wright had written to Talmadge Hughes, the head of the American Institute of Architects on January 22, 1945: (KOP)

My dear man:    (KOQ)

You put me up against the same old hard-spot! Forty years past I’ve had to seem uncooperative and ungracious by refusing to join the Institute. Perhaps I can make clear to you why I refuse again.    (KOR)

I do not join the A.I.A. because I am more interested in Architecture than in the Profession and I felt, as I still feel, able to serve not only Architecture but the Profession better outside the Institute than in it.    (KOS)

I crave good-will and the comradeship of my kind — every man does. But I’ve felt that I couldn’t do the work I wanted to do inside any “Profession.” I’ve had to be a free-lancer and become anathema to the good old guard: the A.I.A. As I then felt, I still believe that Architecture (my real objective) is more than ever Discipline in deciding this matter.    (KOT)

I believe no man can really cooperate except as he maintains the independence of his Spirit. If he becomes interdependent, he is gone, in the same way that (so it seems to me) our National Democracy is gone. But I have never refused anything the boys ever asked me when I could render it on decent terms.    (KOU)

The Profession is in reality more Personal than Principle. Besides this, I know my own limitations in the personal way. Principle makes bad fellows of us all when we come against the hard choice between good-fellowship and the interior discipline of Principle.    (KOV)

There is enough to struggle with when all is fine. Imagine then how much the strain is multiplied by intimate association with congenital opposition or inordinate comradeship.    (KOW)

Does this seem to you as though I consider myself superior to my fellows in the Profession? If so, you are wrong. I frequently envy some of them and wish it all were for me as it seems to be for them. Not that I would trade places — or, even now, regret the isolation that seems to have chosen me.    (KOX)

What I have, what I have done and what I am belongs to my fellows whether either I or they like it or not. But, my dear Talmadge, I want what I have given and what I still have to give to be unhampered by personal or professional considerations.    (KOY)

I hope you won’t misunderstand and resent.    (KOZ)

Faithfully yours,    (KP0)

“We have to be careful,” said Matt. “We may be reaching a similar point with Collaboration.” (KP1)

By “we,” Matt was talking about those of us who self-identify as folks in the field of collaboration, whatever the heck that is. And that was part of Matt’s point. We have to start talking more seriously about what it is, but at the same time, we can’t get so caught up with it that we become a Profession (in the worst way) and lose the essence of what we’re supposed to be about. (KP2)

Extreme Usability Redux

Published August 26, 2005 by Eugene Eric Kim

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)

Improve the usability of the participating projects. (JOU)
Build greater Shared Understanding between the usability and Open Source communities. (JOV)
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)