Share Your Slides!

Posted on Published by Eugene Eric Kim

Congratulations to Rashmi Sinha and her partner-in-crime, Jonathan Boutelle, for the beta release of SlideShare. SlideShare allows you to publish your slides in You Tube-like fashion. It can read PowerPoint and OpenOffice (sorry Mac users, no Keynote yet).    (LA5)

Here are my long-promised-but-never-published slides from WikiSym 2006 this past August and the Internet Identity Workshop last May:    (LA6)

I’ve got a love-hate relationship with slides, and I try to avoid them when possible, but as Ross Mayfield noted, sometimes they’re useful. And when they are, SlideShare is a fantastic way to share them. I will most certainly be using this service.    (LA9)

This is a beta, and I suspect we’ll see Flickr-like Social Networking capabilities eventually. My only gripe: There should be Permalinks for each slide, not just for the entire deck.    (LAA)

I’ve got a few more invitations left, so if you’d like to play, drop me a line.    (LAB)

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)

Yogi, Lewis and Clark

Posted on Published by Eugene Eric Kim

Had to put out a few fires this morning. Thank goodness for high-speed wireless and my trusty new iBook. As a sidenote, Apple Works is an absolute travesty. It is twelve steps backwards in the evolution of office applications. Can’t wait for OpenOffice to run natively on Panther.    (1YT)

Afterwards, I drove to The Hill for lunch at Amighetti’s, then walked down Elizabeth Street to see the stretch of road where Yogi Berra and Joe Garagiola grew up. I love The Hill. Red brick houses line the streets, and there’s an Italian restaurant and bakery on every block. I could spend weeks here, just wandering the streets and eating.    (1YU)

My next stop was the Arch. Took the crazy tram to the top. Remember the egg from Mork and Mindy? The tram consists of eight of those, with five people crammed in each of them. There’s a tram on each side of the Arch, and they meet at the center. Takes about five minutes to the top.    (1YV)

The highlight of the Arch was the IMAX movie and exhibits on Lewis & Clark. I had to add a book on the two explorers to my always growing reading list.    (1YW)

Scott Foehner and I had dinner at Blueberry Hill, which Scott claims is the most well known restaurant in town. Near Washington University, it sports plenty of seating, good burgers, a wide beer selection, live music, kitschy trinkets, and the occasional St. Louis celebrity. Its longtime owner, Joe Edwards, has invested a lot in the area recently. Afterwards, we had a few beers and played some darts and pool at the Black Derby, an excellent little dive with good music in the south side of St. Louis.    (1YX)