FLOSS Usability Sprint Seeking Great Usability Practitioners

Posted on Published by Eugene Eric Kim

FLOSS Usability Sprint V is happening November 2-4, 2007 at Google in Mountain View. This one is special for a number of reasons. First, it’s the fifth one. Second, our project list is once again superb, including Firefox, Chandler, Socialtext, and WiserEarth. Third, it’s the first sprint being primarily organized by members of this burgeoning community: Daniel Schwartz and Jon Slenk.    (MO7)

The goal of these sprints is simple: Make Open Source software more usable, focusing especially on software for social benefit. Our approach is to bring catalyze collaboration between the usability and open source communities. The sprint takes place over three full days (November 2-4). It’s fun, it’s intense, and it’s gratifying. It’s a fantastic way to meet and work with an amazing group of people.    (MO8)

This sprint is shaping up to be really outstanding. We’re still looking for a few great usability practitioners to participate, so if you’d like to help some socially-oriented Open Source projects in a concrete way, please sign up. And please spread the word!    (MO9)

Ph-Off and i-name Promotion

Posted on Published by Eugene Eric Kim

I’m at the Identity Open Space in Santa Clara right now. Lots of good stuff scheduled today, including a session I’m co-leading on Identity Commons, the next generation. Two things worth mentioning now. First, i-names have officially launched. A lot of folks purchased i-names through the Identity Commons fundraiser way back when, and those will finally become useful. If you didn’t have a chance to buy one at the special rate a few years ago, you can buy them at a special rate over the next three days: $5 for the first year of registration. Go to:    (L5U)

and register before 7pm PT, this Thursday, September 14.    (L5W)

Second, Andy Dale has whipped up a cool, anti-phishing Firefox plugin for OpenID users appropriately named, Ph-Off. OpenID and similar technologies rely on the notion of an Identity Broker — a third-party site that handles authentication. Because these Identity Brokers will become increasingly important, we need good ways to be sure that things that look like our i-brokers actually are our i-brokers. When you configure Ph-Off, the toolbar turns green and you get a green thumbs up indicator when you visit your actual i-broker. It’s simple and useful.    (L5X)

URI Syntax for the HyperScope

Posted on Published by Eugene Eric Kim

At last Tuesday’s HyperScope meeting, Jonathan Cheyer and I spent an inordinate amount of time debating the syntax for HyperScope URIs, much to the amusement and chagrin of our peers. Although the topic may seem insignificant, it is actually quite layered with no easy answers. I’m going to summarize the issues here. Most of you will probably not care about the intricacies of the argument itself, but at minimum, it should reveal a bit more about the project itself.    (KI2)

HyperScope is meant to be a transitional tool that will enable people to play with Augment‘s more sophisticated capabilities within their existing environments. In the immediate future, that means the Firefox web browser (and probably Internet Explorer as well). In the not-to-distant future, that could extend to a range of applications, from Eclipse to OpenOffice and beyond.    (KI3)

This intent strongly informs our requirements. In particular, we need to make sure we are bootstrapping the system on top of existing technologies (such as URIs) effectively and correctly, and we need to make sure the system is evolvable. Both of these requirements play a big role in our debate.    (KI4)

So what’s all the fuss about? One of Augment‘s coolest (and most fundamental) features is its sophisticated addressability. The example most folks know about manifests itself as Purple Numbers, namely the ability to reference a specific node in a document in a standard way. But Augment can do much, much more. It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. (See my notes on transcluding a subset of nodes via Purple Numbers).    (KI5)

You can also embed View Specs in an address. For example, suppose you decided that the best way to view a page was the first level of nodes only. You could specify that as a View Spec in the link itself, so that when someone followed that link, they would see only the first level of nodes rather than the entire document.    (KI6)

With the HyperScope, we’re bringing these capabilities to the plain ol’ World Wide Web — that is, assuming your client knows how to interpret these addresses properly. With our initial release (due September 2006), this will require loading a JavaScript library. All document addressability will happen entirely on the client-side. This is a good thing for a lot of reasons, the most important being adoptability. It will be easy for people to play with the HyperScope. All they’ll have to do is click on a link in Firefox (and probably Internet Explorer).    (KI7)

However, the fact that we’re doing a client-side only version of the HyperScope does not preclude the creation of a joint client/server version or even a mostly server-side version where the client is essentially a dumb web browser. In fact, we’d encourage the creation of both. We don’t care some much about implementation as we do capabilities and interoperability.    (KI8)

Here’s the question: How should we include these extended addressing capabilities in real-life URIs?    (KI9)

There are three possible solutions:    (KIA)

  • Embed them as a fragment address (i.e. following a hash mark at the end of the URI).    (KIB)
  • Embed them either as part of the path or query string parameters (i.e. following a question mark at the end of the URI).    (KIC)
  • All of the above and more.    (KID)

I side with the first and third solutions. Jonathan thinks it should be the second.    (KIE)

Fragment Address    (KIF)

Pros:    (KIG)

  • These extended capabilities seem to belong here semantically. Purple Numbers are an obvious example of this. XPointer is another.    (KIH)
  • The URIs will be bookmarkable as the user manipulates the document from the HyperScope. We can do this, because we can change the fragment identifier from within JavaScript. We can’t do the same with any other part of the URI.    (KII)

Cons:    (KIJ)

  • These URIs cannot be used for a server-side only solution, because HTTP does not pass the fragment identifier to web servers.    (KIK)

Path or Query String    (KIL)

Pros:    (KIM)

  • Can be used for client-only or server-only solutions, or anywhere in between.    (KIN)

Cons:    (KIO)

  • You’re still left with the problem of a standard addressing syntax that doesn’t interfere with any other kind of addressing. For example, if you’re going to use a query parameter, what do you call it? Granted, if you namespace it correctly, the likelihood of namespace clash is tiny, but it’s still there.    (KIP)
  • No one’s building a server-side only solution right now.    (KIQ)

Why Limit Yourself?    (KIR)

This is ultimately my argument: Go with the first syntax for now, because it best suits our current needs, and don’t worry about the fact that it won’t satisfy all potential future needs, because nothing will. What’s important is that we standardize the conceptual semantics, and then standardize the syntax to the extent possible. In all likelihood, most people will be passing these links around by copying and pasting them anyway, so the actual link syntax isn’t completely critical.    (KIS)

Announcing the Hyperscope Project

Posted on Published by Eugene Eric Kim

One of the new projects I have the joy of being involved with this year is Doug Engelbart‘s Hyperscope. Doug recently got a bit of NSF funding to build an Open Source prototype of his vision for a Hyperscope, and Doug asked me to lead the project.    (KAT)

You can read more about the project on the project blog. In short, we’re replicating the original hypertext system’s (Augment) browsing (jumping) and viewing capabilities in Firefox.    (KAU)

Why is this significant? Because even though most of the world knows that Doug Engelbart built the first hypertext system in the 1960s, very few people have ever seen and experienced the system first-hand. And boy, is it a doozy. Doug continues to use the system every day, and it has capabilities that no other system has today.    (KAV)

We want the world to see these features, and we want the world to have the opportunity to learn from them and to integrate them into their own systems. We also want the world to realize that these are not features for features’ sake, but are part of a much larger vision of how society can (and must) get collectively smarter.    (KAW)

This project — and Doug’s larger vision — is about improving society’s ability to collaborate. And that’s why I’m involved. We’re not building code for code’s sake (although the code will kick ass). We are kicking off a larger community conversation about how we can improve collaboration, and how we can and should improve our tools to augment our capabilities.    (KAX)

Join The Community    (KAY)

We’ve got a fantastic core team in place. Brad Neuberg is our lead developer. I’ve written about Brad’s coworking efforts, but I haven’t written about how he’s a kick-butt developer who’s doing wild things with AJAX. More importantly, he’s also a deep thinker, which is an absolute requirement to be successful in this position, a leader in the Open Source community, and a lifetime Engelbart fan (not a requirement, but it didn’t hurt).    (KAZ)

Also joining us is Jonathan Cheyer. Jon’s a long-time member of the Collaboration Collaboratory, and he’s also the tech lead for the Computer History Museum‘s NLS/Augment Restoration Project. I’m pretty sure he’s the most proficient Augment user under 40, and I’m quite certain he knows more about Augment’s internals than anyone else under 40.    (KB0)

What makes the project even more fun is that we’ve been working with folks from Doug’s original lab. His daughter, Christina Engelbart, is program manager and is also sharing her insights into how the system was used as well as her knowledge of Doug’s larger vision. Jeff Rulifson and Charles Irby, the first software leads in Doug’s lab, have shared a lot of their knowledge with us, as have Harvey Lehtman and Raylene Pak. These gatherings have not only been extremely educational — stories galore — they have been tons of fun, and we want to encourage other ex-ARC folks to touch base with us and be part of this new community.    (KB1)

Some additional acknowledgements: Mark Finnern is one of Doug’s biggest supporters, and he has given Doug a valuable forum at Future Salon. He also hooked us up with Blake Ross and Joe Hewitt of Firefox fame, two very cool guys who spent some time with Doug and whom we hope will continually engage with this community. A big shout out also to Philip Gust, also of the NLS/Augment Restoration Project, Dorai Thodla, who experimented with an early prototype of the Hyperscope in Java, and Dave Thomas and his OpenAugment team.    (KB2)

Please join us! Subscribe to our mailing lists and blog (and weekly podcasts), and participate on our Wiki. I’ll mostly blog about the project on the project blog, but I’ll also occasionally discuss stuff here. Brad is also blogging about the project. We’ll also be at SuperHappyDevHouse this Saturday doing an Augment jam session.    (KB3)

Blue Oxen Associates    (KB4)

I’m involved with this project for personal and professional reasons. As I said earlier, this is not just about building a piece of code. It’s about engaging with the community at large and building a movement that falls squarely within the mission of my company. The Hyperscope project will help ground larger conversations about how we can and should improve tool interoperability and usability. More importantly, it will ground larger conversations about process and the bigger picture.    (KB5)

At a very concrete level, the Hyperscope falls well within our goal to bring these deeper ideas into existing tools. Not surprisingly, the Hyperscope should integrate very easily with PurpleWiki (as well as other Wikis), providing a new, slick and useful browsing capability. As the project progresses, I’m looking forward to evolving our tools, as well as seeing other folks evolve theirs.    (KB6)

On a personal level, Doug is why I’m in this business. I’ve never been happier with my work than I’ve been in the past three and a half years at Blue Oxen Associates. I bring people doing meaningful work together, I help them collaborate better, and I do it in an open way that hopefully has a much larger societal impact. It’s intellectually satisfying and emotionally fulfilling. And I wouldn’t be doing any of this had it not been for Doug, who’s been a mentor, a friend, and a cheerleader.    (KB7)

In a way, starting Blue Oxen Associates was my gift to him — a commitment on my part to carry out his larger vision. But working on the Hyperscope is a much more concrete way of returning the favor, and I look forward to doing this for him and for the community at large.    (KB8)

Purple Numbers and WIKIWYG

Posted on Published by Eugene Eric Kim

For a while, it was looking like I was going to break another personal blogging record last month, then things got so busy I had zero time to blog whatsoever. That means I’m in catch up mode again, so as usual, I’ll post in reverse chronological order (which in the blogosphere is really reverse reverse chronological order).    (JYN)

Yesterday, I spent the afternoon at Socialtext, where they were having an all-hands meeting. They graciously invited me to participate in the Open Space segment of their gathering, which meant quality time with Chris Dent and a rare opportunity to evangelize the Church Of Purple together. Of course, Chris has been spreading the Purple religion at Socialtext for a while now, so it wasn’t as much about evangelism as it was about next steps.    (JYO)

As I’ve mentioned many times before, browser-based WYSIWYG editors are an exciting development because they allow us to make Purple Numbers transparent in the authoring process. Right now, when you edit a PurpleWiki page, you see the node ID tags (e.g. {nid 123}). This is impossible to get around with the default browser text-editing widget. However, with a WYSIWYG editor, you can hide the Purple Numbers while still maintaining their associations with a node behind the scenes.    (JYP)

That’s the theory, anyway. In particular, I’ve been excited about WIKIWYG ever since Ross Mayfield showed me an early prototype last August. I had a personal bias, since Chris Dent and Matt Liggett helped write it, as did Casey West and the inimitable Brian Ingerson, whom I finally met last weekend at Tag Camp.    (JYQ)

Yesterday afternoon, we discussed Purple Numbers and WIKIWYG, and it was good. Then in the evening, Ingy and I spent a few hours trying to get WIKIWYG integrated into PurpleWiki.    (JYR)

We didn’t quite make it. Our biggest roadblock was a bug we discovered in Mozilla’s design mode that we can’t do much about. (My days of statically typed languages are well behind me.) But, we got something somewhat working, and I learned a heckuvalot. You can play with our semi-working demo.    (JYS)

WIKIWYG seems well-architected and is easy to customize. For folks with relatively standard Wiki editing requirements, I highly encourage you to play with it. PurpleWiki has some special formatting funkiness (mainly due to the Purple Numbers), but we were able to get around this fairly easily. (This was also true thanks to PurpleWiki‘s model of parsing to an intermediate data structure, then using view drivers to serialize. I wish more Wiki engines did this. I know Magnus Manske is thinking about doing this for Mediawiki, and I think Janne Jalkanen is already doing it with JSPWiki.)    (JYT)

The Mozilla bug annoyed me, because it’s a show-stopper in some ways, and there’s not much I can do about it. I didn’t realize it, but all of the JavaScript WYSIWYG widgets actually switch to the browser’s “design mode” in order to handle WYSIWYG editing. As with many HTML editors, design mode does not handle structure cleanly, and you end up getting weird artifacts such as spurious break tags. Our problem was that we serialize node ID information as id attributes in the HTML tags. However, Firefox does not maintain those attributes correctly when you move content around.    (JYU)

I’ll report the bug (if folks have suggestions as to the best way to bring this to the right people’s attention, let me know), but it also puts the kibosh on my hopes for WIKIWYG and Purple Numbers. Even if the bug is fixed in the next version of Firefox, we’re still prey to all the folks using older versions as well as Internet Explorer or Safari, which have their own problems with design mode.    (JYV)

Chris and I discussed one workaround that I’m still pondering: render the Purple Number and have users be responsible for maintaining the association with the nodes. That’s the status quo, except users are doing it in WikiText rather than in WYSIWYG. Doing it in WYSIWYG certainly lowers the bar, and it’s probably the next best thing for us to do.    (JYW)