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)

Purple Numbers Are Ugly

Posted on Published by Eugene Eric Kim

Evan Henshaw-Plath thinks that Purple Numbers are ugly. He’s not the first.    (JW1)

A bit of history. The original Purple Numbers were a dark purple. Then Murray Altheim came up with a brilliant idea. Let’s make them lighter! So he did. That was better, but it wasn’t enough.    (JW2)

As Chris Dent and I started taking the identifier scheme to the next level, blogs started becoming popular. Permalinks, as rabble and others have pointed out, are granular addresses. Because our new identifier scheme was uglier by design (universally unique IDs can get quite large), we decided to jump on the blogging bandwagon and use hashes instead.    (JW3)

Then a funny thing happened. Peter Yim, a long-time Engelbart follower and an avid PurpleWiki user, complained. A lot. He said it was too hard to figure out what the links were. And as much as I tried to ignore him, I couldn’t. He was right. Or, more accurately, we were wrong. So we changed it back.    (JW4)

Our decision to go with hashes was wrong specifically in the context of PurpleWiki. Wikis are wonderful because you can Link As You Think. This is possible because page names are automatically linked, and it’s easy to remember page names. We added syntax for easily linking to Purple Numbers (for example, Purple Numbers). The problem was that when we replaced the addresses with hashes, we made it harder to Link As You Think.    (JW5)

With WikiSym coming up in a few days, I’ve had Wikis on my mind big-time, and I recently had an epiphany. It turns out I was wrong about being wrong.    (JW6)

The identifiers underlying Purple Numbers are designed to be stable, unique, and meaningless. In other words, not human-friendly. The notion of linking to Purple Numbers via our extended Wiki syntax isn’t tremendously useful, even if the identifiers are easily visible, because they’re impossible to remember. You’re rarely going to Link As You Think, because you’ll most likely have to go to the page to check what the number is. If you’re going to do that, you might as well just cut-and-paste the link, the status quo of the web.    (JW7)

Phil Jones almost stumbled onto something quite profound in his commentary last May, but he couldn’t quite put his finger on it, and Chris and I consequently jumped all over him. We were right, of course, but Phil was onto something.    (JW8)

In a Wiki context, here’s the right way to use Purple Numbers. By default, Purple Numbers should look pretty. So far, the best scheme I’ve seen for this is Simon Willison‘s nifty CSS hack. If folks want to link to a Purple Number in a Wiki, they can do it the way you do it anywhere else — get the link address by clicking on the number (or hash or paragraph symbol or whatever), and copy-and-paste it into your document.    (JW9)

However, the Wiki should add an additional feature: the ability to add a human-friendly label to any paragraph. Some Wikis implement this capability by using special WikiText tags, but you should be able to implement this using AJAX goodness.    (JWA)

In other words, suppose you’re reading a Wiki page, and you find one paragraph particularly compelling. All you do is click on the paragraph and add your human-friendly tag. Let’s say the page is DeepThoughts and you enter the label indeed. The label should appear next to the paragraph, and anytime somebody wants to link to that paragraph, they just type DeepThoughts#indeed.    (JWB)

Here’s where it gets cute. Doing this feels like tagging. You’re just tagging granular content instead of documents… which is what Purple Numbers are designed to enable in the first place. So, make the label a tag across the entire Wiki. In other words, if you click on the label indeed, you get a search page showing all paragraphs on the Wiki that have been tagged indeed. If you really want to be cute, you can make it a Technorati Tag so it gets crawled.    (JWC)

This makes cosmic sense. Both Wikis and tagging work when labels are not unique — the exact opposite requirement of Purple Numbers. You want namespace clash, and Wikis and tagging give you that. This way, you get the best of all worlds. You still have the immutable, unique Purple Numbers, but now they’re not so ugly. You also get Link As You Think granular addresses and granular tagging. Everyone wins.    (JWD)

(By the way, rabble, looking forward to seeing pretty Purple Numbers in typo!)    (JWE)

WikiMania Hackfest Day 4

Posted on Published by Eugene Eric Kim

Bits and tids:    (JM7)

  • I didn’t plan my Hacking Days schedule very well. I missed most of the first day, when the Mediawiki developers apparently made progress on a new metadata design. Days 2 and 3, from which I based most of my criticism, focused on servers and reliability, an area to which I really couldn’t contribute, not because I’m ignorant, but because I’m powerless. This morning, they discussed Single Sign-On and usability, two areas that I do know something about. Sadly, I missed these sessions, because I was too busy spouting on and on about how we really can save the world. Owen Davis, Fen Labalme, Kaliya Hamlin, and the rest of the gang will undoubtedly kick my butt when they read this. In my defense, I managed to talk a bit about Identity Commons later in the day. I also plugged the FLOSS Usability Sprint, and met Zeno Gantner, who’s done some usability studies on Mediawiki.    (JM8)
  • I was one of the featured participants for the afternoon “Wiki developers informal discussion,” along with Ward Cunningham, Sven Dowideit, Christophe Ducamp, and Brion Vibber. Domas Mituzas, Wikimedia Foundation‘s head of operations, asked Ward, “Why Camel Case?” I won’t go into the explanation here — I have a long interview with Ward, to be published eventually, that explains this in detail — but you should know that hating Camel Case is a running joke among this community. I laughed along with everyone else, but when Sven mentioned his desire to remove Camel Case from TWiki, I felt compelled to pipe up. I gave a balanced defense, describing Camel Case’s advantages over free links, but also acknowledging the appropriateness of free links in Wikipedia. Then I got a very amusing introduction to Erik Moeller, one of Mediawiki‘s core contributors and the Wikimedia Foundation‘s chief research officer. Erik had a strongly worded response. It got a bit heated, but never overly so, and I closed by saying that we were in violent agreement. We laughed about it over dinner, but then we got serious again. We also talked about Purple Numbers. I’ve explained many times why I may seem like a poor evangelist, but I think Erik was one of the few people who appreciated my perspective. He was clearly not a big fan of Purple Numbers — as it turns out, he was somewhat familiar with my work — but after hearing my explanation, he responded, “Only intelligent people are going to understand what you just said.” Fair enough. Fortunately, regular folks don’t need to get Granular Addressability for Granular Addressability to become ubiquitous.    (JM9)
  • A group of us broke out into a small group to discuss a Wiki Interchange Format, knowing full well that this is an issue that’s been discussed many times before (Wiki:WikiInterchangeFormat, MeatBall:WikiInterchangeFormat). Nevertheless, I think our discussion was not only constructive, it has a high chance of succeeding. See my summary.    (JMA)
  • Magnus Manske, the original creator of Mediawiki, participated in our Wiki Interchange Format discussion. He also mentioned a clever idea: a “shopping cart” where people could aggregate and possibly export Wiki pages they were interested in.    (JMB)
  • Sven Dowideit demonstrated the prototype WYSIWYG editor for TWiki, based on Kupu. He also showed a WikiText editor with real-time preview, which was pretty slick. Also, Ross Mayfield showed me a prototype editor for KWiki in response to my previous post. Very good to see these things.    (JMC)
  • So many people have come to this gathering to learn from others with different experiences. Granted, all of these experiences center around Wikipedia, but I’m still envious. My neverending quest is for folks interested in collaboration to look beyond their own narrow domains for deeper insights.    (JMD)

WikiMania Hackfest

Posted on Published by Eugene Eric Kim

I’m in Frankfurt am Main, Germany this week for Wikimania. The conference itself starts on Friday, and I’ll be speaking on the history of collaborative tools on Saturday. With the encouragement of fellow alumnus Samuel Klein, I decided to come a few days early to participate in Hacking Days. It’s been an excellent opportunity to immerse myself with the Mediawiki developers, as well as a way to get to know some of the more active members of the Wikipedia community before the throngs arrive later this week.    (JJD)

It’s been over 15 years since my last trip to Europe, and this is my first work trip here. Frankfurt is as good a place as any to cushion folks like me from culture shock. While I’m nowhere near fluency, English is a Germanic language, and I took two years of high school German, so I recognize vocabulary here and there. Plus, most people speak English, especially here in Frankfurt, which is a European travel hub.    (JJE)

The conference itself is at the Haus der Jugend, a large Youth Hostel in the center of the city. Most of the participants and speakers are staying here at the hostel, which makes things very collegial. I’m rooming with Kurt Jansson, the president of the German chapter of Wikimedia Foundation, and Juan David Ruiz (Chile) and Ascander Suarez (Venezuela), core members of the Spanish chapter. It’s given me both an international take on Wiki culture and a bird’s eye view on the inner workings of the Wikipedia community.    (JJF)

I love the international flavor of the community and the conference itself. I had a great conversation with Delphine Menard, a French woman who handled the event’s logistics. She’s lived all over the world and speaks three languages fluently. As I gushed about the importance of being around a diverse group and about experiencing the feeling of being an outsider, she observed that based on her experiences, in the end, people are more or less the same, regardless of background. True, true. Everybody is people. When you interact with others who are different from yourself, you realize that we all share some very human values. You can’t truly reach that conclusion without experiencing diversity first-hand.    (JJG)

Watching the developers work was interesting. It was very much like watching a face-to-face IRC discussion. Folks sat around a table with their laptops open and participated in multiple conversations — both face-to-face and over IRC — and activities simultaneously. I’ve been playing ethnographer and collecting observations, which I’ll bring to people’s attention more formally on Thursday.    (JJH)

Samuel and I talked a bit about Wikiness and the aversion that hard core Wiki developers seem to have over WYSIWYG editing. WikiText is not essential to the Wikiness of Wikis. Ward Cunningham himself has stated on record that GUI editing is the next big step in the evolution of Wikis.    (JJI)

I’m in Frankfurt through Monday and in Berlin after that, so if you’re in town, let me know.    (JJJ)