purple-include: Granular Transclusions for the Common Man

Many thanks to Jonathan Cheyer, Craig Latta, and Kaliya Hamlin for coming to the HyperScope sprint this past weekend, and special thanks to Christina Engelbart for hosting. Also thanks to Thom Cherryhomes and others who hung out with us on IRC. The notes from the day are up on the Wiki, and I put up some pictures as well.    (MEL)

https://i2.wp.com/farm2.static.flickr.com/1134/681861752_857ef74d28_m.jpg?w=700    (MEM)

The big news, though, is that Brad, Jonathan, and I wrote a cool hack called purple-include, based on Mark Nottingham‘s most excellent hinclude. It lets you transclude granular chunks of content from any web site by using an img-like tag. Check out the examples. I think this will go a long way in making Transclusions more common on the Web.    (MEN)

You address granular content either by using a fragment identifier that the document author provides (such as a Purple Number) or by using an XPath expression. Thanks to Tony Chang for his cool interactive XPath tester.    (MEO)

The planned next step is to create a Firefox plugin that adds a “Transclude” option when you right click inside of a browser text widget. This will allow you to transclude copied content, rather than paste it. Don’t know whether any of us will get to this soon, so we encourage the lazy web and all you Firefox hackers to beat us to the punch.    (MEP)

This was my first non-trivial foray into JavaScript, and I was disturbed by what I saw. The language itself is not horrible, although its object system makes Perl 5 look like Smalltalk. What’s shameful is its API support. We had to use a very ugly, although apparently common hack to get a DOM of external web pages. This is pure silliness. The browser is already doing the hard work of parsing broken HTML and XML and turning it into a DOM. Why not easily expose that functionality to the developer?    (MEQ)

As Brad dryly noted, “Welcome to my world.”    (MER)

Usability and Encouraging Expert Usage

I was at SuperHappyDevHouse last Saturday with the rest of the Hyperscope crew. At around 2am, a group of us started having this great conversation about usability. Late night serendipity — you’ve got to love it.    (KCT)

Tony Chang asked us what we thought the most frequently pressed button was in Microsoft Office. We all guessed wrong. The correct answer is “Paste.” It turns out that practically no one uses Ctl-V to paste in Office. This, of course, was stunning news to all of us developer types, because we all use Ctl-V regularly.    (KCU)

Tony’s point was that real-world data trumps so-called expertise, a point that was hammered into all of us over and over again at the FLOSS Usability Sprints.    (KCV)

Microsoft’s response to this data was to enlarge the Paste button. (See Jensen Harris‘s Bay CH I talk for more on Office usability.) This response troubles me. On the one hand, it enhances the usability of the application for novices, which is a good thing. On the other hand, it does nothing to encourage users to learn the keyboard shortcuts.    (KCW)

Doug Engelbart often decries the misguided notion of “user friendliness everywhere” by saying that we would not want a world where everyone rode tricycles. Tricycles serve their purpose, but eventually, most people upgrade to bikes.    (KCX)

How can we design our apps that are usable for novice usage, but that also encourage expert usage? In other words, How do we design bikes with training wheels rather than bicycles? In the Office example, I would argue that there’s value in encouraging expert behavior and that emphasizing the Paste button is counter-productive in this regard.    (KCY)

Pie Menus are an excellent example of usable design that encourages expert usage. They address a novice need, but they also encourage expert behavior, because calling commands is associated with a physical gesture that becomes part of a user’s muscle memory.    (KCZ)

At RecentChangesCamp, Ward Cunningham talked about one of his challenges at Eclipse Foundation. He observed that the core Eclipse developers used the tool much differently than most users, an experience that was far more powerful and hence, far more gratifying. In typical Ward fashion, he’s trying to create a social space in which the core developers share their “aha” experiences with Eclipse as a means to encourage expert usage.    (KD0)

There are definitely cultural aspects of encouraging expert usage, but I also wonder if there are affordances that we should be encouraging in the design of the technology itself.    (KD1)

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)

More Usability Sprint Fallout

More fallout from the FLOSS Usability Sprint. A number of participants, spearheaded by Joel Aufrecht, have launched the Open Web GUI project. The idea is simple: Create highly usable web pages for common administrative CMS tasks and distribute them under an Open Source license. The motivation is simple. The administrative function of most Open Source CMSes are largely the same. One way they could help each other is to collaborate on developing a highly usable UI (including menu layout, workflow, etc.) for common tasks that any project can use. They’re looking for visual designers and usability folks to help out; check out the web site for more information.    (IG9)

I spoke at Bay CH I on March 8. We had a great turnout, including many of the participants from the sprint. It was great to see those familiar faces. (Has it really been only a month?) Richard Anderson blogged about my talk and contributed some anecdotes of his own. Tony Chang also blogged the talk, and reiterated a problem that Rashmi Sinha had made:    (IGA)

What are the incentives for usability analysts to help open source projects? Eugene mentioned having public work that one can cite in a resume, but there must be more than that…    (IGB)

Marketing isn’t the only incentive. There are folks who pay for Open Source work, but most of these folks aren’t hiring usability practitioners. One reason for doing this sprint was to make these people realize that they should. The money is there; it’s a matter of making the case that the money would be well spent by investing it in usability.    (IGC)

Finally, Mary Hodder has been taking the notion of Extreme Usability, which emerged from the sprint, and has been running like crazy with it. Her anecdotes are great, and I have a feeling that where she’s taking the notion will be even better.    (IGD)